The Discovery Phase Explained: What US Ecommerce Shipping and Fulfillment Leaders Get Before a Line of a Custom Rate Shopping Engine Is Written

This article is part of our series on Custom Parcel Rate Shopping Engine Development for US Ecommerce Shippers: Building a Multi-Carrier Rating, Surcharge Modeling And Label Production System

Introduction: What You Should Have Before Anyone Writes Code

A rate shopping engine is built on facts about the shipper: how parcels actually move, what contracts actually say, what invoices actually charge, and what the catalog actually contains. Most of those facts are scattered across systems and spreadsheets, and some are wrong.

A shipping software discovery phase gathers them before anyone writes code. Done well, it ends with evidence rather than opinions: how much better prediction is worth, which rules the engine must enforce, which data must be fixed first, and whether building makes sense at all.

This article explains what a shipping software discovery phase is and is not, what gets examined, the deliverables you should receive, the timeline and cost to expect, how to read the outcome, and the red flags in a discovery offer.

It is written to help evaluate any discovery engagement, not to sell one. Discovery is the decision layer of the full custom software development guide to parcel rate shopping engine development, whose working surfaces include shipping console development (web app development).

What Discovery Is, and What It Is Not

A discovery is a short, bounded engagement that examines a shipper’s data, contracts, systems and rules and produces a written basis for a decision, with a fixed scope and a fixed end date.

It is not a sales presentation, a generic requirements questionnaire, or the first sprint of a build that has already been decided. A discovery that can only end in build is not a discovery, whatever the statement of work calls it.

It is also not a carrier contract negotiation, a hazmat classification exercise or customs advice. Those belong to the shipper’s own specialists, brokers and counsel, though discovery should identify precisely where they are needed and on which items.

The useful test: at the end, could you take the deliverables to any development partner, or to a platform vendor, and use them? If yes, the discovery was done for you. If they only make sense to the firm that produced them, it was done for them.

What Gets Examined

Shipment History

Several months of shipments by carrier, service, origin, destination, weight, dimensions and promise, including peak season if possible, since peak behaves differently from the rest of the year in both cost and reliability.

Contracts and Invoices

Carrier agreements and the invoices that followed, matched label by label, to measure how far quotes drift from bills and which causes account for most of the gap.

The Product Catalog

Item dimensions and weights, hazmat and lithium battery classifications, restricted product flags, and customs data for international items, assessed for completeness and accuracy rather than taken at face value.

Systems and Accounts

Order management, warehouse and checkout systems, current shipping software, carrier accounts and API access, and any integrations broken or patched when carriers retired their legacy APIs between 2024 and 2026.

Promises and Customers

What checkout tells customers, how often that promise is actually met, and how delays are communicated when it is not.

The Deliverables You Should Receive

A parcel spend analysis showing where quotes and invoices diverge, by cause, with the value of better prediction estimated from your own data and every assumption behind that estimate stated plainly.

A data quality report on dimensions, classifications and customs data, with a plan to fix the gaps that matter and an order to fix them in.

A rule inventory: the eligibility, promise, contract and business rules the engine must enforce, with the carrier, hazmat and customs sources behind each, and the ones needing specialist review flagged rather than assumed settled.

An integration map of carriers, systems and data services, including API readiness after the recent retirements and the agreement terms to verify before designing around them.

A recommendation: use a platform, extend one, or build, with reasons.

And if building, a staged specification and estimate the shipper owns outright, usable with any partner including the one who wrote it. The rule inventory draws on Carrier Tariff and Service Guide Terms, Hazmat and Limited Quantity Shipping Rules, Lithium Battery Transport Requirements, Customs Declarations and Service Guarantee Claim Handling.

Timeline, Cost and Who Should Be in the Room

A focused discovery for a rate shopping engine typically runs four to eight weeks and, as a 2026 planning range, roughly $25K to $60K, depending on carriers, nodes, catalog complexity and international scope.

The shipper’s side needs the shipping or fulfillment lead, someone from finance who knows the carrier invoices well enough to explain a line, whoever owns the item master, the people responsible for hazmat and customs, and a technology lead for the order and warehouse systems.

Data access is usually the schedule risk rather than analysis time. Invoice files and shipment history should be requested on the first day rather than the second week, since carrier portals and finance archives both take time to open up. Discovery turns the general ranges into your own estimate, as described in Custom Parcel Rate Shopping Engine Budget Guide for US Ecommerce Shippers.

Reading the Outcome: Use, Extend or Build

Use a platform when the analysis shows modest savings from better prediction, a simple catalog and one or two nodes. The deliverables still earn their cost: cleaner data and a rule inventory make any platform work better than it would have.

Extend when a platform or existing system handles labels and carriers well but lacks the decision logic, node selection or reconciliation the shipper needs. Building those layers around it is often the best value, and where the existing system is aging rather than inadequate, legacy software application modernization is the cheaper half of that work.

Build when volume, nodes, contracts or a regulated catalog make the savings large and the rules complex, and the shipper is ready to maintain carrier integrations as they keep changing, which the last two years showed is not a small commitment.

Whichever outcome, the data quality plan applies. Most of the savings in any engine come from accurate dimensions and classifications rather than from clever rating logic.

Red Flags in a Discovery Offer

A discovery that does not ask for invoices. A savings figure promised before any data is seen. Deliverables that only the offering firm can use. No mention of data quality anywhere in the scope. No use-a-platform outcome on the table.

And the ones that should end the conversation: savings that depend on declaring smaller dimensions or commercial addresses than reality, customs values or descriptions optimized to reduce duty, hazmat handled by guesswork or by software alone, and checkout promises tied to guarantees that carriers have suspended.

Each of those trades compliance or customer trust for a number on a slide, and each tends to surface later as a correction, a penalty or a refund.

The strongest positive signal is a team that asks for last quarter’s invoices before anything else.

Conclusion

Shipping leaders who start with discovery get evidence before code: how far their quotes drift from invoices, which data needs fixing, which rules the engine must enforce, and whether a platform, an extension or a build fits.

That evidence is worth having whatever the decision, and it is the best protection against building the wrong thing well. A shipping software discovery phase that ends in buy has still paid for itself. It is also a fair thing to ask of any of the software companies in the United States who would like the work.

If you are considering a custom rate shopping engine, a short discovery that starts with your own labels and invoices is what turns a good idea into a decision you can defend.

FAQ