This is the most common question we are asked and the hardest one to answer responsibly. Any firm figure quoted before anyone has understood your requirement is a guess — and guesses in this industry are reliably optimistic.

What we can do is explain exactly what moves the number, so you can judge quotes you receive and recognise the ones that have not been thought through.

Why nobody can price it from a one-line brief

"Courier software" describes systems that differ by an order of magnitude in effort. A single-branch operation booking consignments and printing dockets, and a multi-hub network with partner integrations, a rider app, COD reconciliation and client portals, are both accurately described by that phrase.

A firm answering with a price before asking about your volumes, branches, integrations and existing systems is either quoting for something much smaller than you need, or intends to renegotiate later. Neither ends well.

The seven things that actually drive cost

1. Number of modules

Booking and tracking alone is a contained system. Add rate cards and billing, then COD reconciliation, then hub and sorting operations, then partner management, then client portals — each is genuine additional scope, not a checkbox.

2. Integrations

Usually the most underestimated item. One well-documented courier API is contained work. Five partners with different authentication, label formats and status vocabularies is a much larger project, and the status normalisation alone can rival the cost of a module.

Integrations with payment gateways, SMS or WhatsApp providers, accounting systems and e-commerce platforms each add their own work — and their own ongoing maintenance.

3. Mobile applications

A rider application is effectively a second product, with its own design, offline behaviour, sync logic, testing and store releases. A customer app is a third. Deciding honestly whether you need one, two or none has a larger effect on cost than most feature decisions.

4. User roles and permissions

Three roles is straightforward. Fifteen roles across branches, with data visibility rules — this branch sees only its own consignments, this client sees only their own shipments — is substantial work that rarely appears in a feature list.

5. Scale

Volume affects architecture. A system handling a few hundred consignments a day and one handling tens of thousands need different decisions about data, queuing and reporting. Retro-fitting scale is more expensive than designing for it, so being realistic about growth matters.

6. Data migration

Moving from an existing system means extracting, cleaning and importing historical data — and legacy data is rarely as clean as anyone expects. This is regularly discovered mid-project rather than scoped at the start.

7. Hosting, support and change

Software has running costs: servers, backups, monitoring, support, and the changes your business will inevitably want. A quote covering build only is not covering the cost of ownership, and the difference is not small over three years.

How to get an estimate worth having

A meaningful estimate follows a requirement analysis. Before that conversation, it helps to have answers to:

• How many consignments do you handle daily, and what is realistic growth?
• How many branches, hubs and staff, in which roles?
• Do you deliver yourself, use partners, or both?
• Which existing systems must it connect to?
• Do you need a rider app? A customer app?
• How complex are your rate cards, honestly?
• What data has to come across from your current system?

The rate card question catches people out. Pricing that "varies a bit by client" frequently turns out to be dozens of negotiated structures with client-specific surcharges — and that is a pricing engine, not a settings screen.

Should you build at all?

Sometimes not. Off-the-shelf courier products exist, and if your operation is close to standard, one may serve you better and cheaper than a custom build. Custom software earns its cost when your process is genuinely different, or when that process is how you compete. We set out the trade-off in off-the-shelf or custom software.

A phased build is often the sensible middle path: start with the modules that address your actual bottleneck, run them in production, and extend from there. It gets value earlier and means later decisions are made with real usage data rather than assumptions.

Questions worth asking any development company

• What is explicitly out of scope in this quote?
• Who owns the source code and the data?
• What are the ongoing costs after launch?
• How are change requests priced during the build?
• What happens if an integration turns out not to be possible?
• What does support cover, and what is the response commitment?

The ownership question is worth asking early and getting in writing. So is the one about what happens to your data if you part ways.

Where we come in

We scope courier software development after understanding the operation, and we will tell you when a phased build or an off-the-shelf product is the better answer. Describe how your operation runs and what it needs to do, and we will come back with what it would take — including what we would not recommend building.