Most shortlists are assembled from the wrong evidence. A scoring sheet weighted for company size, hourly rate, certifications and number of delivered projects will produce a clean ranking, and that ranking will say very little about which vendor can ship a yard scheduling module that survives its first week at a live dock.

The divergence shows up in the first integration sprint, not in the proposal. A shortlist with Wezom on it alongside three other names carries no information until each has answered the same operational questions, because what separates a transportation and logistics software development agency from a capable general software firm is rarely headcount. It is whether their engineers already know why a delivery appointment and a delivery window are different records, and what breaks downstream when the two are collapsed into one.

That knowledge is testable before a contract is signed. Most buyers never test it, which is why so many supply chain technology projects arrive at the same failure point: a system that works in demonstration and cannot absorb the way the business actually runs.

What Procurement Measures and What It Misses

Standard vendor evaluation was designed for purchasing predictable things. Applied to software development for supply chain operations, it optimizes for the wrong variables.

Hourly rate is the clearest example. A rate comparison is only meaningful against equal productivity, and productivity here is dominated by domain knowledge rather than coding speed. An engineer who has built customs documentation flows before will deliver a working implementation in a fraction of the time it takes an equally skilled engineer learning what a commercial invoice must contain while writing the code. The second engineer will also produce a design that needs revisiting, because the real requirements surface halfway through.

Team size measures capacity, not the ability to deploy it usefully. Two hundred engineers of whom eight are assigned is the same offer as thirty of whom eight are assigned, unless those two hundred include people who have shipped warehouse execution systems.

Case studies are the weakest evidence, written after the fact and describing outcomes rather than method. Every vendor's case studies describe successful projects. None describe the project that went badly, which is the one that would show how the vendor behaves under pressure.

What procurement rarely evaluates is what determines project outcomes: how the vendor handles the discovery that a stated requirement was incomplete. That happens on every logistics project, usually in the first two months, and the response separates vendors more reliably than any scored criterion.

Domain Knowledge Is Testable in Forty Minutes

A technical conversation with the people who would do the work, not the sales engineer, reveals more than any document exchange.

Ask what happens when a shipment status update arrives out of sequence: a delivery confirmation before the pickup. A team that has built status processing will describe idempotent handling, event ordering by timestamp rather than arrival, and a reconciliation path, because carrier feeds deliver exactly this. A team that has not will describe validation that rejects the message, which sounds correct and loses data.

Ask how they would model a shipment that splits across two trailers mid-route, or consolidates with another at a cross-dock. The answer reveals whether their mental model of a shipment is a single record with a status, which is the naive design, or a structure separating the order, the cargo and the movement.

Ask about EDI specifically. Which transaction sets have they implemented, and what was hard. Real experience surfaces as trading partner variation rather than the standard itself: that a 214 status update from one shipper expects different reference qualifiers than another, that a 990 tender response must return inside a window enforced with chargebacks, that a 945 must reconcile against the 940 that preceded it. Teams without experience describe EDI as a format problem, which is the easy part.

Ask what they would do about appointment scheduling at a receiving facility. The naive answer is a calendar. The experienced answer asks about dock door capacity, whether appointments are by dock or by facility, how long the unload actually takes versus what was booked, what happens when a truck arrives outside its window, and who holds authority to reschedule. Those questions are the requirements.

Ask about units of measure. It sounds trivial and is the source of an enormous number of production defects, because cases, pallets, layers, eaches and weight coexist, conversion factors vary by product and change over time, and any system picking one canonical unit without recording the conversion used will eventually produce quantities nobody can explain.

Forty minutes of this separates candidates more effectively than a three-week RFP cycle.

The Integration Surface Is the Project

In most supply chain builds, integration work exceeds application work, and vendors who scope from screens rather than interfaces produce estimates wrong by a factor rather than a margin.

A typical build touches an ERP holding master data and financials, a WMS or several, a TMS or a set of carrier connections, customer systems through EDI or API, customs and trade compliance tools, telematics feeds and a data platform. Each has an owner, a change window, an availability profile and behaviours not in its documentation.

Legacy systems in this sector are frequently older than the people maintaining them, and their interfaces reflect that: scheduled flat file drops, database views exposed directly, middleware that transforms without logging. Getting data out is often possible; getting data in, transactionally, with error handling, requires negotiation with a system owner who is protective for good reasons.

Master data is the second reality. Locations, products, customers, carriers and units exist in multiple systems with different identifiers and different definitions of a record. A facility might be one location in the ERP and three in the WMS. A customer might be a sold-to, ship-to and bill-to that the new system treats as one entity. Reconciling this appears in no proposal and consumes real weeks.

Third, availability differs. A warehouse system may have a nightly maintenance window during which it is simply gone. A carrier API may rate-limit in ways that constrain status refresh frequency. A customs system may be available only during certain hours in certain jurisdictions. Any design assuming all dependencies are always reachable will fail in its first month; correct architecture queues, retries and degrades explicitly.

A vendor asking for integration inventory, interface documentation and system ownership during evaluation is behaving correctly. One producing a fixed-price estimate without seeing any of it is producing a number that will be renegotiated.

Delivery Models and What Each One Actually Buys

Staff augmentation places the vendor's engineers under the client's direction. It works when the client has strong internal technical leadership and a clear architecture. It fails when the client expects augmented engineers to make architectural decisions they have no mandate or continuity to support.

A managed team model gives the vendor delivery responsibility with the client setting priorities, which suits ongoing product development where scope evolves. It requires a product owner who can decide at the pace the team works; projects stalling in this model usually stall because the client cannot answer questions fast enough.

Fixed-price delivery transfers scope risk to the vendor in theory and back through change requests in practice, because logistics requirements are rarely fully known at contract time. A fixed price built on thin discovery is a mechanism for adversarial change control. It works for well-bounded pieces such as a defined integration against documented interfaces.

A paid discovery phase before the main engagement resolves most of this. Four to eight weeks of architecture work, integration inventory, data assessment and prototyping produces an estimate grounded in the actual system landscape, and gives both sides a low-cost trial of the working relationship. Buyers who resist paying for discovery are choosing a worse estimate in exchange for a small saving.

Evaluating a transportation and logistics software development agency on its willingness to structure the engagement this way is informative in itself. Vendors confident in their domain knowledge tend to propose discovery because it protects them from underestimating. Vendors selling capacity accept whatever structure closes the deal.

Evidence Worth Asking For

Ask for an architecture walkthrough of a comparable system, conducted by an engineer who worked on it. Confidentiality limits what can be shown, but the shape of the design, the reasoning behind the boundaries and what they would do differently are discussable. Listen for whether the engineer describes trade-offs or features. Someone who built the system remembers what they gave up.

Ask what went wrong on their most difficult logistics project and how it was resolved. Every vendor has one. The answer distinguishes organizations that conduct retrospectives from those that move on. A vendor who cannot name a difficult project either has thin experience or is not being candid.

Ask about production support history. Systems here run continuously, and vendor behaviour during a two a.m. incident matters more than behaviour at a sprint review. What is the escalation path, who is on call, and what does support cost separately from development.

Reference calls need better questions than satisfaction. Ask what the vendor got wrong, how scope changes were handled, who from the vendor's team is still involved, and whether the reference's internal team can maintain the system now. The last one reveals whether knowledge transfer happened.

Continuity, or Who Actually Shows Up

The gap between the team presented during sales and the team assigned after signature remains one of the most common sources of disappointment. Senior people are scarce and deployed where they generate new business; once a contract is signed, the account is staffed from availability.

Buyers can address this by naming key personnel, specifying minimum allocation and requiring approval for replacement. Whether a vendor accepts those terms is itself a signal. More useful is insisting that the people who will do the work participate in evaluation, which removes the substitution opportunity entirely.

Attrition is the related risk over longer engagements. In a domain where knowledge accumulates slowly, losing the engineer who understands the carrier integration layer costs months. Vendors who handle this well have documentation practices, pair work and internal knowledge sharing that make individuals less load-bearing. Asking how they onboard a new engineer onto an existing logistics project reveals whether those practices exist or are aspirational.

Time zone arrangements matter operationally. Supply chain systems have incidents during the client's operating hours, which for a distribution network may be most hours. A delivery team with four hours of overlap can develop effectively but cannot support incidents, so the support model needs separate design.

Handover Is a Deliverable, Not an Event

The end state buyers should design toward is a system that can be operated and modified without the original vendor, whether or not they intend to leave. That requires specific artefacts, and the time to require them is at contract stage.

Architecture documentation explaining why the system is structured as it is, not just what the modules are. Runbooks for operational procedures: reprocessing a failed EDI batch, responding when a carrier feed stops, recovering a partially completed transaction. Integration specifications covering trading partner variations and the reasons behind them. Environment setup a new engineer can follow to a working local build.

Observability belongs here too. A system that logs adequately, exposes health metrics and raises alerts corresponding to business impact can be operated by people who did not build it. One requiring familiarity to diagnose cannot, regardless of documentation quality.

Source code ownership and repository access should be settled explicitly, along with the status of any vendor-owned frameworks embedded in the delivery. A system built on proprietary platform components is not fully transferable, and that constraint should be visible before it becomes apparent during a transition.

The test worth applying is whether a competent engineer who has never seen the system could take over a defined piece of maintenance work within two weeks. Vendors who build toward that standard produce systems that outlive the relationship.

Signals That Should Stop a Process

A proposal arriving quickly with a confident fixed price and no questions about the existing landscape indicates either a template or a plan to renegotiate.

A vendor whose technical conversation moves immediately to their preferred stack, before understanding the operational problem, is selling what they already have.

A demonstration built on clean data with no exception cases is a demonstration of the easy path. Asking to see a shipment cancelled after departure, or a partial delivery recorded, usually ends it.

Reluctance to let the buyer speak with engineers rather than account management suggests the engineers would not hold up to the conversation.

Estimates allocating a small percentage of effort to integration and data migration indicate inexperience with a domain where those items routinely dominate.

A vendor agreeing with every requirement without pushing back on any is not engaging with the problem. Logistics requirements as written by business stakeholders frequently contain contradictions, and a partner worth having identifies them during evaluation rather than implementing both.

A Selection Approach That Reflects the Risk

The structure producing better outcomes inverts the usual sequence: a short commercial filter followed by substantial technical engagement, rather than a long paper RFP and a brief technical conversation.

Start by removing candidates on non-negotiables: security posture, contractual terms, jurisdiction, insurance, ability to support required operating hours. This is fast and mechanical.

Then run structured technical sessions with the remaining two or three, using the same scenario for each. Give them a real problem from the operation with its real messiness: the appointment system that cannot change, the WMS exporting nightly, the customer whose EDI deviates from the standard. Ask each to describe an approach. The differences will be about reasoning rather than presentation.

Follow with a paid discovery with the leading candidate, structured so its output belongs to the buyer regardless of whether the main engagement proceeds. A few weeks and a modest fee purchases an architecture, a grounded estimate and direct experience of how the vendor works. If it goes badly, the loss is contained.

Weight the commercial comparison against the discovery output rather than the original proposals, which were priced against different assumptions.

A transportation and logistics software development agency selected this way has been evaluated on the things that determine whether the system works: whether its engineers understand the operation, whether its estimate reflects the real integration surface, and whether it behaves well when requirements turn out to be incomplete. The rate card is a rounding error next to any of them.

© qolumnist