Technology

May 29, 20269 min readTechnologyBy Argo Shipping

Why your 3PL should write its own software

Almost every third-party logistics provider runs software somebody else wrote. That sounds like a detail of procurement and it is actually the thing that decides whether your operation can be shaped around your business or has to be squeezed into a template. Here is what changes when the company packing your orders also owns the code, and how to evaluate the claim when a provider makes it.

What buying software actually commits you to

An off-the-shelf warehouse management system encodes thousands of decisions somebody made about how a warehouse should work: what a SKU is, how a kit is represented, what happens when a count disagrees, which fields are mandatory, how a return is dispositioned. Those decisions are usually reasonable and they are always somebody else's.

When your business does not match those assumptions, you get one of three outcomes. The provider tells you the system cannot do it. The provider does it manually outside the system, which works until the person doing it is on holiday. Or the provider files a feature request with a vendor who has thousands of other customers and no particular reason to prioritize yours.

None of those is a scandal. It is the ordinary consequence of renting your operating assumptions. But it does set a ceiling on how far a provider can adapt to you, and the ceiling is invisible until you hit it.

What we built, concretely

We would rather be specific than say "proprietary technology," which is a phrase that means nothing. Three examples of things that exist because we own the code.

Routing rules written per partner

Rate tables across UPS, USPS, and FedEx get compared per package on weight, zone, and promise date, so each order rides the lane that wins. Beyond that, the rules are yours: route by zone to cut transit, batch subscription renewals against a cutoff, flag a shipment for review when carrier scans suggest it is heading for trouble. These are written, tested, and deployed by our engineers rather than configured within somebody's dropdown menus.

This matters more than it did three years ago, because the carrier landscape is fragmenting. When a carrier changes a dimensional threshold, the response is a rule change that week, not a support ticket.

Controls placed where the failure actually happens

Here is the example we keep coming back to, because it cost a partner a deadline. A SKU came into our system without a weight. An order for an item with no weight cannot be rated, so it routed into an exceptions queue instead of shipping. The partner had a hard date, expedited freight was authorized and paid for, and the books arrived after the event anyway.

Two changes came out of it. Weight became a mandatory field before anything is received into stock, enforced by the system rather than by diligence. And data readiness became its own gate in our transition plan. That second half is only possible if you can change the system: a rented platform lets you write a policy document about weights, and a system you own lets you make the weight impossible to omit.

The principle generalizes, and it is the most useful thing in this article. A control that depends on somebody remembering is not a control.

Estimating that does arithmetic no human should do by hand

On the print side of our business, our systems automatically work out how many copies of a job fit on a press sheet, then group compatible jobs so they share a single press run. Jobs match on the things that have to match physically: paper stock, printed sides, finish, and whether the piece bleeds off the edge.

The result shows up on a quote as a savings line rather than as a lecture about sheet geometry. We think that is the correct division of labour: the system does the combinatorics, and you see the dollars. Our note on how print pricing actually works covers the mechanics for anyone who wants them.

The failure mode of writing your own

Honesty requires the other side of this. Building software is a real commitment and it goes wrong in predictable ways: half-finished features, a system only its authors understand, and engineering effort spent on things a vendor already solved well.

Two habits keep us on the right side of that, and they are worth asking any provider about.

Ship, then measure. Ideas are worth nothing until they ship. We test them, implement the changes that drive a positive impact, and reward intelligent risk-taking. The guardrail is that a project we start is a project we finish, because a warehouse running half-built software is worse off than one running somebody else's finished software.

Fail loud rather than quietly. This is a design philosophy with real operational consequences. When our estimating system cannot price something, it routes the job to a person for review instead of producing a confident wrong number. When an inventory record cannot be matched, it surfaces for repair instead of being silently dropped. Systems that guess when they are uncertain are how small errors become invoices nobody can explain.

How to evaluate the claim

"We build our own technology" is easy to say. Five questions that separate the real thing from the brochure:

• Who wrote the last change you shipped, and when? A date within the last month is a working engineering team. A date in a previous quarter is a platform.
• Can you show me a rule built for one customer? Custom logic for a single partner is the specific capability that off-the-shelf systems struggle with.
• Where do your engineers sit? Ours sit next to the warehouse floor, which is not a culture point. It is why a problem observed at a pack bench becomes a change rather than a complaint.
• What does your system do when it is uncertain? The right answer involves a human and an exception queue. The wrong answer is a default value.
• What can I see myself, without asking? Every shipment, delivery time, and charge itemized and live in a portal you can export from is a different posture than a monthly report.

Why we do it this way

Argo is a technology company that lives in logistics and print, not a warehouse that bought some software. That ordering is deliberate, and it has a commercial consequence: we do not compete by being the lowest bid. We compete on systems that improve shipping and reduce waste, then pass the savings along.

Underneath it is the value we call Evolution, which in practice is unglamorous. Every Argo employee, every one, submits weekly recommendations for organizational improvement. Most are small. A few become system rules that make a class of error impossible. Standing still is losing ground, and small ideas compound in the same direction as the savings.

The bottom line

The question is not whether your 3PL has software. Everyone has software. The question is whether the people running your operation can change it when your business needs something different, and how long that takes.

Ask what happens when you need something the system does not do. Then ask when the last change shipped.

Related reading