How a custom software quote is actually calculated

When you ask "what would this software cost", the only honest answer is "it depends, and here is what it depends on". This article lays out those variables so you can estimate before calling anyone.

Software is not priced by screens

The most common misconception. Clients often say "it is only about ten screens", and that number barely correlates with price.

An eight-screen system with four user roles and a two-level approval chain costs more than a thirty-screen system where everybody sees everything.

The reason: price tracks the number of states the software must handle, not the number of pages to draw. An order with six states and four people who can change them creates twenty-four situations to test. That is where the time goes.

The four variables that set the price

1. Number of user roles

Count the kinds of people who will log in with different permissions. Owner, branch manager, salesperson, accountant, customer — that is five.

Each added role needs its own screens, its own permission set, and its own testing of everything that role must not be able to do. That last part is the time sink, and the part cheap quotes omit.

Rule of thumb: each additional role adds roughly 15–25% to the work.

2. Number of stateful workflows

A workflow is something that moves from state A to state B through human hands. An order: new → confirmed → shipping → complete. A leave request: submitted → pending → approved/rejected.

Count the workflows, and for each one count the states. The total state count is the best price predictor you can compute yourself.

3. Number of external integrations

The variable with the widest error bars. Connecting to a well-documented API takes three to five days. Connecting to a local accounting package with no public API can take three weeks, or turn out to be impossible.

Budget 1–3 weeks per integration, and ask one question first: does the other system have an API, and is it documented? If the answer is "probably", that is an unpriced risk.

4. Legacy data requirements

Moving 5,000 customers from Excel into new software sounds simple and usually is not. Real data always contains duplicates, missing required fields, dates in three formats, and inconsistent capitalisation.

Budget 1–2 weeks for data migration if you have history to carry over, and do not be surprised when the builder asks you to clean some of it yourself.

The quick estimate

You can run this in five minutes:

1. Count user roles → multiply by 2 weeks
2. Count total states across workflows → divide by 4, giving weeks
3. Count external integrations → multiply by 2 weeks
4. Legacy data to migrate? → add 1.5 weeks
5. Add it up, then multiply by 1.3 for testing and fixes

A real example: an order system for a furniture workshop — 4 roles, 2 workflows totalling 11 states, 1 integration (Zalo OA), 1,200 customers in Excel.

(4 × 2) + (11 ÷ 4) + (1 × 2) + 1.5 = 8 + 2.75 + 2 + 1.5 = 14.25 weeks → × 1.3 = about 18 weeks.

That is not a quote, but if somebody offers you "three weeks" for that system you know something does not add up — and if somebody offers twelve months, you know that too.

Three ways to genuinely reduce the price

Cut roles, not features. Removing a role from version one saves 15–25%. Removing a feature usually saves a few days. Giving everyone the same permissions in phase one and splitting roles later is the most effective saving available.

Drop integrations from version one. Exporting to Excel and keying it in for the first three months costs you a few hours a week and saves two weeks of build. After three months you will also know better whether the integration was needed at all.

Do not migrate legacy data. Start empty and keep the old system read-only for lookups. Emotionally hard to accept, and usually the right call.

More on this in build an MVP or build it all if you are weighing scope cuts.

Why we do not quote over the phone

Because the number would be wrong and both of us would know it. We fix scope first — usually three to seven days — and only then give a price and a handover date, both written into the contract.

If you need a range for budgeting before investing time in scoping, message us on Zalo with the four numbers above: roles, states, integrations, and whether there is legacy data. You get a range back, described plainly as a range and not a price.