Insights · 9 min read
Most software estimates are wrong, and that is not the problem. The problem is not knowing why they're wrong, or which number to trust. Here is how to estimate a custom project so the number means something.
By GGP Editorial
Most software estimates are wrong, and that is not the problem. The problem is when you cannot tell why they are wrong, or which wrong number to trust. I run a software development company and spend a lot of my time turning vague ideas into numbers people can plan a budget around. This is how I think about that process, from both sides of the table.
The first thing to get straight is what you are actually asking for. An estimate is a forecast built on incomplete information. A quote is a price for a defined scope. Most founders ask for a quote but describe something that can only support an estimate, then feel cheated when the real cost lands somewhere else.
This is not splitting hairs. It changes how you read every number you are given. If the scope is still moving, a single number is a guess wearing a suit. What you want at that stage is a range and a list of assumptions, so you can see what the number depends on.
We have written about why custom software quotes vary by a factor of three. The short version is that vendors price your clarity as much as your scope. The clearer you are, the tighter the range.
Before any method, you need to know what you are estimating. A custom software project is sized by a handful of inputs, and almost none of them is the number of screens.
The real drivers are scope and outcomes, complexity, integrations, team composition, timeline, and the environment the software runs in.
| Driver | What it changes | Why it surprises people |
|---|---|---|
| Scope | how much gets built | features added quietly inflate the cost |
| Complexity | effort per feature | simple-sounding features hide hard logic |
| Integrations | uncertainty and risk | third-party APIs never behave like the docs |
| Team | cost and quality | junior hours are cheap until the rework |
| Timeline | headcount and pressure | faster means more people, not longer days |
| Compliance | data and audit requirements | regulation reshapes the data model |
If you want the fuller picture of where money goes across these drivers, our custom software development cost breakdown walks through them one by one.
There is a whole field of estimation, and most of it is overkill for a founder trying to plan a budget. The methods worth knowing are the ones that fit how little information you have at the start.
Break the work into pieces and label each one small, medium, or large, then attach a rough cost to each size. It is coarse and fast, and it forces you to list the work, which is half the value. Use it when you have a feature list and no design yet.
For each piece of work, write down an optimistic number, a likely number, and a pessimistic number. The spread tells you how much you actually know. If the optimistic and pessimistic numbers are close, that piece is well understood. If they are far apart, that piece is where your risk lives, and it is worth narrowing it before you commit.
Take a project you or the vendor has already shipped and compare your new project to it. This is more reliable than any formula because it is grounded in something real. Ask a vendor for a comparable past project and what it cost. A good one can name one.
A top-down estimate says projects like this cost somewhere in this range, based on similar work. A bottom-up estimate adds up the individual pieces. Do both. When they disagree, the gap is the part of the project you do not understand yet, and that is exactly where you should ask more questions before signing anything.
A single number at the start of a project is usually a fiction everyone will be embarrassed by later. A range with assumptions is honest and useful, because it lets you plan for the middle and prepare for the top.
A good vendor gives you a range and tells you what would push you toward the top of it: an integration that turns out to be messy, a compliance requirement you had not named, a design change mid-build. A bad vendor gives you one confident number and hopes you sign before you think about it.
For the mechanics of how a price can flex during the build, fixed price vs time and materials is worth reading before you commit to a pricing model.
You do not need to know how to code to check an estimate. You need to ask a few pointed questions.
Ask what the number assumes about scope. If two vendors give you wildly different prices, one of them is almost certainly pricing a different project. Ask each to restate the scope in their own words and see if it matches yours.
Ask what they did not include. Maintenance, hosting, third-party licenses, and quality assurance are the usual omissions. A cheaper estimate that leaves these out is not cheaper. It is hiding cost in a later invoice.
Ask how the team is composed. Ten senior engineers cost a lot more than two senior and eight junior, and the difference shows up in the build. A low number backed by an all-junior team is a warning sign, not a bargain.
Ask for a comparable project. A vendor who has shipped something like yours can ground the estimate in reality. One who cannot is estimating from imagination.
These are the same instincts behind our guide to choosing a software development company, and they apply whether you are reading a proposal or sitting in a first call.
The single biggest improvement you can make to any estimate is the quality of what you hand over. A clear scope written as outcomes, a list of the systems you need to integrate with, and an honest budget range will get you a better number than any amount of clever estimation on the vendor's side.
If you are starting from nothing, our guide to writing a software requirements document covers how to capture the scope in a form a team can build from. An RFP is the formal version of the same handoff, and our RFP guide covers when that overhead is worth it.
One way to judge a vendor before you hire them is how they handle the estimate itself. A careful estimate, with assumptions listed and risks named, tells you how they will run the project. A rushed one-liner tells you how they will run the project too, just less flatteringly.
Treat the estimation conversation as an interview. The vendor's questions during it are more revealing than their answers. A vendor who asks about scale, integrations, and who will use the system is thinking about what actually drives your cost. A vendor who only asks about your deadline is thinking about theirs.
The mistakes I see repeat, so they are easy to list.
Each of these is cheap to fix before the project starts and expensive after.
GlobeSoft is a China-based software development company with 40-plus engineers and more than 300 delivered projects across markets like Brazil, South Africa, Singapore, and the US. When you come to us with a project, we estimate it the way we would want it estimated for us: we read the scope, ask the clarifying questions, and come back with a range, the assumptions behind it, and the risks that would move it toward the top.
Our stack runs on Java, Spring Boot, Spring Cloud, Go, Node, Python, Vue, and React, with MySQL, Redis, and Nginx underneath. We have built trading systems, payment platforms, property systems, and financial management tools, which means the comparable-project question is one we can usually answer with a real example.
If you have a project in mind and want a number you can actually plan around, send us what you have. We will tell you what we can estimate from it, what we need clarified, and what it would take to build.
How accurate is a software estimate?
Early estimates are ranges, not points. A good one lands within a range whose width reflects how much of the scope is still unknown. The range tightens as requirements firm up, and you should expect the number to move as the project gets defined.
Why do two vendors quote such different prices?
Usually because they priced different scopes, made different assumptions, or composed the team differently. Check what each quote assumes and excludes before you compare the numbers.
Should I ask for a fixed price or an estimate?
It depends on how firm your scope is. A fixed price makes sense when the scope is well defined and unlikely to change. If the scope is still moving, a range with assumptions, or a time-and-materials model, will serve you better.
How long does estimating take?
A rough range can come back in days once the scope is clear. A formal estimate with a full team plan takes longer, and the difference usually reflects how carefully the vendor is thinking about your project.
What is the best thing I can do to get a better estimate?
Write the scope as outcomes, list the systems you need to integrate with, and share your budget range. Clarity is the cheapest input you can add.
A good estimate does not end the uncertainty. It puts it where you can see it. Describe the outcomes, name the assumptions, and ask the questions that reveal what the number depends on, and you will walk into the build with your eyes open instead of your fingers crossed.
Tell us what you are building and where you are today. We typically reply within 24 hours.
