A software quotation answers one question: what it costs to have the system. The more important questions are what it costs to get the system actually used, and what it costs to keep it alive for the next five years. Below are the cost lines most often left out, and how to estimate them from the start.
1. Your own people's time
This is the largest item and almost never appears in a quotation. A serious management project needs internal staff to describe the business, reconcile data, test and sign off. Those people are usually the best in their department, and they still have their day jobs.
A realistic way to estimate: for each module, plan for one business owner to spend a significant share of their time throughout the rollout. If the company cannot free them up, the schedule will slip — not because the developers are slow, but because nobody can answer the business questions.
2. Cleaning and migrating old data
Legacy data is rarely clean: the same customer spelled three ways, product codes invented per person, opening balances that do not reconcile. The cost here covers:
- Standardising master data before loading.
- Writing and re-running the migration script several times — the first run is almost always wrong.
- Reconciliation after loading: counts, balances and totals must match the old system.
A general rule: the cleanup effort grows with the number of years the company has run on loose files.
3. Integrating with what already runs
Few companies have only one system. E-invoicing, digital signatures, banks, the accounting package, time clocks, the online shop — each connection is its own cost, and the cost sits not in calling an API but in handling the mismatches: a call failing halfway, the two sides disagreeing, the partner changing versions.
When budgeting, list every connection explicitly instead of folding them into one "integration" line.
4. Training and the productivity dip
In the first week on a new system, productivity always drops. People work more slowly, ask more questions, and some days they will do the job both ways. That is a real cost and should be planned for rather than treated as a sign of failure.
How to reduce it: train each group on their own process rather than touring the whole system, and keep someone on hand to help during the first two weeks.
5. Infrastructure and operations
Servers, backups, certificates, monitoring — and most importantly, the person responsible when something breaks at eight in the morning. If you self-host, count that time. If you use a cloud service, read the backup and restore terms carefully: not every plan includes point-in-time recovery.
6. Changes after go-live
Companies do not stand still. Every year brings new regulations, new pricing policies, a new org chart. This cost is certain, so put it in the annual budget from the beginning instead of treating it as an unplanned extra.
A system that has not been updated in two years is usually not a stable system — it is a system whose users have quietly gone back to spreadsheets.
How to budget without surprises
- Split the budget in three: build, go-live, and annual maintenance. Merging them is the source of every unpleasant surprise.
- Define scope in business terms, not feature names. "Payment requests with three approval levels and limits by job title" is far clearer than "approval screen".
- Tie acceptance milestones to usage outcomes, not to the number of screens delivered.
- Reserve budget for exceptions. Every company has a few rules unlike anyone else's; they always surface late, usually during testing.
The question to answer before signing
If the project ends exactly as quoted, how many hours per month does the company save, or where does it decide faster? If you cannot answer with a concrete number, the problem is not the quotation — it is the goal of the project.
