Send the same three-paragraph description to four development companies and the quotes will not be close. It is normal for the highest to be four or five times the lowest. The usual explanation, that some companies are expensive and some are cheap, is almost never the main cause.
The main cause is that they are not quoting the same thing. Your description had gaps, each supplier filled them differently, and each priced their own reading. The expensive quote may include data migration, two integrations and a proper permissions model. The cheap one may assume a single user type, no migration, and that "reporting" means one screen with a table on it.
You cannot judge those numbers without knowing what makes software expensive. This article is that list. It contains no figures, deliberately: rates differ by country, by year, and by the kind of company doing the work, and a cost article with numbers in it is wrong somewhere in the world on the day it is published and wrong everywhere within two years. The structure, though, holds.
The one idea that explains most of it
Software cost tracks the number of distinct situations the system must handle correctly, not the number of features on a list.
A feature is a headline. "Order management" is one line in a brief and anywhere between two weeks and two years of work, depending on how many situations sit underneath it. Can an order be edited after payment? Partially refunded? Split across two deliveries? Cancelled by a customer, or only by staff? Does a cancelled order that was already invoiced need a credit note? Each answer is a rule, a screen or a state, and each one is a thing that must be built, tested, and kept working when the next thing changes.
This is why estimates given before anyone has examined the process are guesses. The person quoting is estimating how many situations they think are hiding behind your paragraph, and their optimism about that is the largest single variable in the number they send you.
The seven real cost drivers
One — states and rules
The dominant driver, and the one described above. Count the things in your business that have a lifecycle: an order, a booking, an application, a case, a claim, a shipment. Then write down every state each can be in and every transition between them, including the ones that go backwards. That list is a better predictor of cost than any feature list you could write.
A useful diagnostic: if a process has more than about six states, or if any state can be reached from three or more others, the logic is where your money is going, and it is worth spending time simplifying it before anyone builds it.
Two — users, roles and permissions
Software for one kind of user is dramatically cheaper than software for four. Each additional role brings its own screens, its own rules about what it can see and change, and its own combination with every state in driver one.
Permissions in particular are underestimated because they sound like a setting. In practice, "the regional manager can see their own branches but not others, except for the group report, which they can see for all branches but without customer names" is a sentence that costs real money. Ask early whether a simpler model would be acceptable. It usually would.
Three — integrations
Every connection to another system is a small project with its own risks, and the cost is rarely proportionate to how simple it sounds.
What makes them expensive is not the connection but the disagreements. Two systems will have different ideas about what a customer is, different rules about required fields, and different behaviour when something fails halfway. Someone has to decide which system is the authority on each piece of information, and what happens when they diverge. That reconciliation logic is the actual work.
Watch for these specifically: systems with no documented interface, systems where the vendor charges for interface access, and any integration where data flows both ways. Two-way is more than twice one-way.
Four — data migration
Moving years of existing records is a project, not a task, and it is the item most often left out of a cheap quote.
Existing data is never as clean as anyone believes. There are duplicates, records with the phone number in the name field, three spellings of the same customer, and a period in 2019 when someone used a different convention. Nobody knows this until it is examined. The work is not the transfer — it is deciding what to do about each category of mess, and getting a sign-off that the result is correct.
Five — the requirements nobody writes down
The ones that never appear in a brief and can double a build: how many users at once, how fast it must respond, what uptime is expected, what happens when it is offline, who can access what data, what must be logged for audit, what regulation applies, how long records are kept, and what a backup and restore actually needs to guarantee.
An internal tool for eight people, where an hour of downtime is an inconvenience, is a different engineering proposition from a system that customers use at three in the morning. The features can be identical. The costs are not.
Six — the design surface
Roughly, cost tracks the number of distinct screens and the number of states each screen must display: empty, loading, one item, thousands of items, an error, a long name that breaks the layout, no permission to view. A screen designed only in its ideal state is a screen half built, and the difference shows up either in the quote or in the bug list.
Mobile is a real multiplier here. Building for a browser that works well on a phone is included. Building a separate native application for two platforms is a different project, and treating it as a variation of the same one is a frequent cause of overrun.
Seven — change during the build
Some change is healthy, because things learned in month two are genuinely worth acting on. What costs money is change that invalidates a decision the build already stands on.
Adding a field is cheap. Adding a second organisation type that sees a different version of everything, in month four, is not — it touches the data model, the permissions, most screens and all of the tests. This is why an afternoon spent on the shape of the thing before the build is worth more than any negotiation over rates.
What costs less than people expect
Worth stating, because these are where clients often try to economise and give up value for very little saving.
| Commonly assumed expensive | Reality |
|---|---|
| The number of pages | Cheap when they are similar. Ten screens that behave alike cost far less than three that all behave differently |
| The technology choice | Rates vary by stack, but the difference is small next to scope. Choosing an unusual technology to save on rates usually costs more later in maintenance |
| Visual design quality | Producing a considered interface costs little more than a careless one at the same scope. What costs money is redesigning after the build has started |
| Making it fast | Cheap if it is a requirement from the start, because it shapes the structure. Expensive as a fix, because by then it is a rebuild of the parts that matter |
| Accessibility | Inexpensive when built in, since it is mostly correct markup and adequate contrast. Retrofitting is a project |
The pattern is consistent. Things that shape the structure are cheap to decide early and expensive to add late, which is the reverse of how most budgets are staged.
Five ways to spend less without building worse
Cut states before you cut features. Look for the states that exist because of a rare case: the manual override used twice a year, the special approval for one customer. Handling that case outside the software, by a person, is often the largest available saving.
Reduce the number of roles. Three roles instead of six removes far more work than three screens instead of six.
Stage the integrations. A daily export is not as good as a live connection, and it is a fraction of the cost. Live it later, once the system has proved it is worth the investment.
Migrate less. You rarely need every record from the last nine years in the new system. Two years live, the rest in an archive you can search, is a common and much cheaper answer.
Launch to one group first. One branch, one product line, one region. It reduces the states that must work on day one, and it turns the riskiest week of the project into a small one.
Note what is not on the list: reducing testing, skipping documentation, or asking for a smaller number by having the same scope quoted by someone cheaper. Those move money rather than saving it, and they tend to move it into the following year.
Why nobody can give you a number over the phone
Not evasion, in most cases. A supplier who names a figure before understanding the process is doing one of three things: quoting the smallest reading of your description in order to win, adding a large contingency and hoping you do not notice, or making an error you will both live with.
What a good supplier can tell you early is which of the seven drivers your project is heavy in. That is a genuinely useful answer, it is available after one conversation, and it is enough to tell you whether you are in the right order of magnitude before either side spends real time.
If you need a firm figure before committing to a build, a paid discovery stage is the honest mechanism: a fixed fee, a defined output, and the resulting document usable by any supplier — including one you have not chosen yet. That last condition is the one worth insisting on.
Common questions
Why do offshore quotes look so different? Hourly rates differ across markets, so some of it is real. The rest is often scope: a lower quote frequently assumes tighter requirements and less iteration. Compare what each includes for migration, integration, testing and post-launch support before comparing the totals. Also consider the cost of your own time. Working across a large time difference adds days to every question, and questions are what a project is made of.
Is a fixed price safer? It moves risk rather than removing it, and the price includes the supplier's cover for that risk. On work whose shape is genuinely known, a fixed price is reasonable and often sensible. On work that has not been examined yet, the number carries contingency for the worst plausible reading, and you pay that whether or not the risk arrives.
How much should we hold back for after launch? Plan for ongoing cost rather than a one-off purchase. Something will need attention in the first month, dependencies need updating through the year, and the business will change. Budgeting for a build with nothing behind it is how a system becomes untouchable.
Can we start small and see how it goes? Yes, and it is usually the right approach, with one condition. The first piece must be genuinely useful on its own rather than a foundation that does nothing until the rest arrives. A first stage that delivers no value is not a smaller project; it is the same project with the payment spread out.
The short version
- Cost tracks the number of distinct situations the software must handle, not the number of features.
- The seven drivers: states and rules, users and permissions, integrations, data migration, the unwritten requirements, the design surface, and change during the build.
- Quotes vary by multiples mostly because suppliers filled the gaps in your description differently. Ask each what they assumed; the assumptions explain the gap.
- Page count, technology choice and design quality matter less than people think. Speed and accessibility are cheap early and expensive late.
- To spend less: cut states before features, reduce roles, stage integrations, migrate less, launch to one group first.
- Nobody can give you an accurate number without examining the process. They can tell you which drivers your project is heavy in, and that is worth having.
Where to take this next
If you are still working out what to send suppliers, how to write a project brief a developer can actually price is the practical version, and it is the document that turns the drivers above into comparable quotes.
If the decision is still open in the other direction, build or buy is worth settling first, because the cheapest custom software is the part you did not need to build.
When you want an estimate against your actual process rather than a general one, that starts with a conversation. Discuss your idea, or say hi on WhatsApp.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass. Cornerstone article — the visuals here will be reused as reference in later cost articles, so they should be drawn to stand alone.
Hero visual — one feature, many situations
Concept. A single line at the top labelled "Order management", with a fan of lines descending from it into a field of small labelled boxes: created, paid, part-shipped, back-ordered, returned, refunded, cancelled before payment, cancelled after payment, disputed, closed. Below the field, a caption band reading one line in a brief. The visual should feel top-heavy in a way that makes the point.
Purpose. Carries the article's central idea, and works as the reference image for the whole cost cluster.
Composition. Roughly 4:3 to give the fan room. Brass on the single top line only.
Alt text. One line in a brief reading "order management" fans out into ten distinct order states, each of which must be built, tested and maintained.
Supporting visual 1 — the seven drivers
Concept. Seven horizontal bands, each labelled with a driver, with a small marker on each showing whether it is typically underestimated, correctly estimated, or overestimated. Not a chart with values; a legend-driven diagram. Data migration and integrations carry the underestimated marker; page count and technology choice carry the overestimated one.
Purpose. Gives the reader a scannable summary they can hold a quote against.
Placement. At the head of "The seven real cost drivers".
Alt text. Seven cost drivers marked according to whether they are usually underestimated, estimated correctly, or overestimated, with data migration and integrations most often underestimated.
Supporting visual 2 — cheap early, expensive late
Concept. A horizontal timeline of project stages, with five decisions plotted as dots: speed, permissions model, accessibility, data structure, number of roles. Each dot has a small cost bracket beside it that is thin on the left of the timeline and thick on the right, showing the same decision growing more expensive the later it is taken.
Purpose. Supports the conclusion of the "what costs less than people expect" section, which is the most actionable paragraph in the article.
Placement. After that section.
Alt text. Five structural decisions shown across a project timeline, each cheap to take at the start and progressively more expensive the later it is made.