What a custom system costs, and why estimates differ

Three companies quote on the same request — an inventory and invoicing system for a retail business with six branches — and the numbers come back three to four times apart. Not fifteen per cent apart; the highest is three to four times the lowest. The owner's first assumption is that one supplier is padding and another is cutting corners. Usually neither is true. The three read the same two-page brief and priced three different systems.

A number means very little until the thing being priced is described closely enough that two different teams would build roughly the same system from the description. Before that point, every quote is a priced guess about what you meant.

The same request produces three different systems

The cheapest of the three quotes almost always assumes the narrowest reading. One workflow, generalised from the way head office happens to work. Two user roles. No connection to anything you already run. Opening data entered by hand. Hosting arranged by you, later. The most expensive assumes the widest reading: the exceptions each branch has accumulated over the years, four roles with different screens and different permissions, a link to the accounting package already in use, electronic invoicing, two years of history migrated, and a year of support after launch. Both documents can be written in good faith.

Five things separate them, and none of them is margin.

• Scope read differently. The brief said "manage stock". One supplier heard a stock ledger. Another heard purchase orders, transfers between branches, stocktakes, damage and shrinkage, and a reconciliation report at month end.
• Integrations counted or not counted. A quote that does not name the systems it will connect to has not priced them. The connection you assumed was included is the single most common source of a mid-project increase.
• Operating cost included or left out. One supplier priced the servers, backups, monitoring and the third-party services for the first year. The other quoted the build alone and will send you a hosting bill you did not plan for.
• Who will actually do the work. A team of two people learning on your project and a team that has migrated stock data before will produce the same demo and very different behaviour in the second month of live use.
• Support after launch, inside or outside the price. A year of fixes, updates and someone answering the phone is a real cost. It is either in the number or it is coming later.

A quote is a description of a system with a number at the end. Compare the descriptions first.

What actually moves the number

Most of the cost of a custom system sits in a handful of decisions, and most of them are yours rather than the supplier's.

• User roles. Each distinct role is a set of screens, a set of permissions, and a path that has to be tested separately. Going from two roles to five is not a small change; it is close to a second system in miniature.
• Integrations with systems you do not control. A bank, a payment gateway, a courier, a marketplace, a government portal, an ERP a group company already runs. The expensive part is never the call itself. It is the credentials, the test environment that behaves differently from production, the failures that must be retried without duplicating an order, and the fact that the other side can change without telling you.
• Payments and compliance. Card payments, wallets, cash on delivery and its reconciliation, refunds, and electronic invoicing to the tax authority each carry rules that are not negotiable and have to be handled exactly.
• Offline behaviour. A point of sale (POS) that must keep selling when the connection drops, and reconcile afterwards without double-counting, is a materially different system from one that assumes the network is there.
• Arabic, right-to-left, and bilingual use. This is not a translation file. Layout mirrors, numerals and dates have to be decided, sorting and search behave differently, and every printed document — invoice, delivery note, statement — has to be correct in both directions. Priced from the start it is ordinary work. Retrofitted, it is expensive.
• Data migration. Moving from spreadsheets, an ageing system, or more often a mixture of both. The cost is proportional to the mess, not to the volume, and nobody can see the mess from outside.
• The reporting you will ask for later. The reports requested three months after launch are frequently the reason the data model has to change. Ask for them now, while they are cheap.

The costs that never appear in the quote

The build price is one line in a longer bill. Five items sit outside almost every proposal you will receive.

Hosting and infrastructure run every month for as long as the system lives: servers, storage, backups, certificates, monitoring, and a staging environment if anyone is serious about testing. Third-party services are billed by use — SMS and OTP messages, the payment gateway's percentage of every transaction, maps, email delivery. Maintenance is not the same as support; libraries age, operating systems are retired, and a system left untouched for two years becomes expensive to touch at all. Training and the change itself take real time, and a system nobody was taught is a system half used. Finally, your own staff's hours: decisions, data cleaning, acceptance testing. Expect the person who owns the project internally to spend something like a day a week on it, more during migration and testing.

Over three years, running costs plus maintenance commonly add up to a sum comparable with the original build. That is not a warning against building. It is the number you should be planning against, rather than the build price alone.

Three shapes of system

No honest article attaches a firm price to a category, because two projects of the same shape can differ threefold on migration or a single integration. What can be described is the shape you are in — usually clear from the first conversation — and the order of magnitude that shape tends to sit at.

The ranges below are illustrative. They are here to show how far scope moves a number, not to price your project: they are not a quotation, and a system at the top of one row can cost more than one at the bottom of the row beneath it.

What decides where in a range you land is not the number of screens:

• In the first row, whether any existing data has to come across with the system.
• In the second, the integrations, and how clean the data in the old system is.
• In the third, money movement, reconciliation, and what has to happen when one party misbehaves.

A useful test for which row you are in: count the parties who have conflicting interests, and count the systems you do not control. Those two counts predict cost better than the size of the brief does. And none of these figures include what it costs to run the thing once it is live, which is the next section.

A fixed price before scoping is either padded or provisional

A supplier who commits to a fixed price on a two-page brief has three options later. Pad the number enough to survive whatever the brief turns out to mean. Hold the number and recover the difference through change requests. Or hold the number, absorb the difference, and quietly reduce quality where you cannot see it — testing, error handling, the parts that only matter in the second year. The first is the one you want, and you are paying for the padding.

The alternative is a short, paid, time-boxed scoping phase that ends in documents rather than promises: an inventory of screens and roles, each integration named with its documentation actually read, an assessment of the data to be migrated, the non-functional requirements written down, and a build plan with a price attached to it. It costs a fraction of the build, it produces a number you can put in a budget, and you should own the output whether or not the same company builds the system. If you are still choosing between suppliers, how to choose a software company covers what else to look at besides the number.

Comparing two quotes fairly

Normalise the scope before you compare the totals. Send both suppliers the same seven questions and require written answers.

1. The list of screens and the list of roles, with which roles reach which screens.
2. Every integration named, plus who supplies credentials and test accounts, and what happens when the other side is down.
3. Data migration: which data, how many years, who cleans it, and what happens to records that will not map.
4. Where it runs, who pays for it, and the estimated monthly running cost in the first year.
5. What happens after launch: warranty period, response times, the rate for changes, and whether there is a monthly retainer.
6. Who does the work — how many people, at what seniority, and how much is subcontracted.
7. Acceptance: what has to be true for the project to be considered finished.

Once both have answered the same seven questions, one of two things happens. The numbers move towards each other, or the gap acquires a name — an integration one of them never counted, a year of support one of them included. Either outcome is better than choosing on a total. And if a supplier will not answer question seven, that is worth more than the discount; the early signs a project is going wrong usually start with an undefined finish line. It is also worth understanding how suppliers build their numbers, because it tells you which parts of a proposal are estimate and which are policy.

Getting a number you can plan around

The way to replace a range with a figure is to scope the work before committing to build it, which is the cheapest part of the project to get right and the most expensive to skip. Softwiro runs scoping as a fixed, time-boxed phase whose written output is yours to keep — contact us if you want the scope of your system on paper before you commit to a build.