How to check a development estimate: what belongs in it and what is usually missing

In short. An estimate for custom development can be checked without technical knowledge, by looking at how it is built rather than at the total. A sound estimate contains five kinds of work: process analysis, development, integrations, data migration, launch with stabilisation. The development part is broken into lines you can name in your own words. Everything the vendor did not estimate is stated openly. Where a kind of work is absent, or hidden behind the words “to be agreed”, you will pay for it later and at a higher price.

What follows is the order we use when somebody brings us another vendor’s estimate and asks for a second opinion.

Start with the parts it is made of

Skip the number at the bottom and open the structure. Work on a custom system comes in five kinds, and each of them belongs in the estimate:

Kind of work	Usual share	If it is missing
Process analysis and design	10–15%	The vendor is estimating from your three-paragraph description
Development	40–50%	Does not happen
Integrations with the accounting system and external services	15–25%	The exchange will appear as a change order
Data migration	5–15%	You will be moving reference data and history yourself
Launch and stabilisation	10–15%	The errors of the first weeks become a separate invoice

The shares are approximate and vary a lot by project. Where there are no integrations at all, there will be no line for them. The point is different: every absent line means either a deliberate decision somebody will tell you about, or work nobody thought of. The second is more common.

Look separately for testing and project management. Sometimes they sit inside the development lines, sometimes they stand on their own. If they appear nowhere, ask who checks the result before you see it.

Check how finely the development is broken down

The line “Client portal, 320 hours” tells you nothing, and most likely tells the vendor nothing either. That number was produced by sizing the whole thing at once, and it can be wrong by a factor of two in either direction.

A working benchmark: a development line is no larger than 16 to 40 hours, and it reads without a programmer. “The client sees a list of their orders with a filter by status and date, 12 hours” can be checked: you understand what it refers to and you can say whether you need it. “Orders module, 200 hours” cannot be checked at all.

If more than half the lines are large, the estimate was written before the process was examined. That is not dishonesty: from a description of the task there is no way to be more precise. It does mean the total should not be signed as final.

Find everything marked “to be agreed”

The phrases “to be agreed”, “estimated separately”, “if required” and “within technical feasibility” all mean the same thing: this part was not estimated. Most often it covers:

• integration with the accounting system;
• migration of data from the old system and from spreadsheets;
• changes after the first weeks of real use;
• hosting, licences and paid services (SMS, email, maps, document recognition).

Ask the vendor for at least a range on each such line. If they cannot give a range, ask what they would need in order to give one. Usually it is a data export or access to a test environment, and that answer is a good sign: the vendor knows what the price depends on.

Check whose time is needed on your side

No system gets built without somebody on the client side who explains how the process actually works and checks finished parts against real data. Across our projects that is 20 to 30% of one employee’s working time for the whole development period.

This belongs in the estimate or in the work plan. Where it is not written down, the vendor is assuming acceptance will happen by itself. In practice two-week gaps open up between a finished part and anyone looking at it, and the schedule grows without a single technical problem. On time and materials the money grows with the schedule.

Fixed price or time and materials

A fixed price works when the scope is understood and written down: after the process analysis, with mock-ups of the key screens and a list of integrations. The vendor then carries the risk of having estimated badly, and you know the number.

A fixed price named before that analysis works worse. The vendor builds in a margin you pay for, and if the margin runs out, starts economising on what is not visible from outside: tests, error handling, documentation. That surfaces six months into live operation.

Time and materials is more honest while the scope is unclear, and it needs control: an hours report every two weeks tied to the lines of the estimate, and the right to stop after any stage. For most projects the working arrangement is this: process analysis at a fixed price, then an estimate for the development based on its results.

The year after launch

An estimate usually ends at the launch date. The spending does not. Support and development of a working system run at roughly 15 to 20% of the development cost per year: hosting, updates, fixes, small changes. That line is worth writing down before signing, because it is the part that gets discovered a year later.

Ask what the warranty covers and how long it lasts, what support costs after it, and who owns the source code and the server credentials. The last question is asked least often, and without it changing vendors later is very hard.

Questions to ask before signing

The answers are not visible in the estimate, so they are asked out loud and recorded in the minutes:

1. How many user roles are budgeted, and which ones.
2. Which integrations are included in the price, and what did you see in order to estimate them.
3. Did you look at our data before estimating the migration.
4. How much time do you need from our employee, and at which stages.
5. What happens if the scope grows: how is that estimated and who decides.
6. What does the warranty cover, and what does support cost afterwards.
7. Do you hand over the source code and the credentials, and at what point.

Two estimates from different vendors with the same answers to these questions can be compared on the total. With different answers there is nothing to compare: they were costed for different projects.

Common questions

Why do estimates for one task differ by a factor of three? Usually because different work has been costed. One has no data migration and no integrations, the other has both. Differences in the hourly rate rarely explain more than a factor of one and a half. The rest sits in the scope.

Is it normal for a vendor to charge for the estimate? Yes, where the estimate includes interviews with your staff and a look at your data. That is two or three weeks of work, and its output stays with you: you can take it to another vendor.

Can an estimate be checked with no programmer on the team? Everything described above can: the kinds of work, the size of the lines, the hidden items, your own time, the support. Judging the hours themselves needs somebody who has built similar systems. That can be a second vendor.

What do systems like this cost overall? Benchmarks by project type are collected separately: a B2B platform, SaaS, accounting integration.

The rule

An estimate with no data migration, no time from your side and no year after launch is too early to check on the total. Ask the vendor to add those three things first, then compare.

How we work and what we build is on the custom B2B platforms page. If you already have an estimate from somebody else, send it over and we will say what is missing from it.