What's in a software development estimate besides the code?

Your app is live, you ask for one change, and the number that comes back looks far too big for it. We hear it from founders all the time, experienced ones too.

Why so much more than the time it takes to write the code? Because the code is often the smaller part. A software development estimate for a live product also covers the work that makes a change safe to ship, and finding out how far it reaches.

Why a small change can reach a long way

A change that looks small can reach deep into the system. Say you want customers to have more than one delivery address. On screen, that's one more field. But the checkout and whatever sends orders on for packing were built for one address, and each now has to know which address goes with which order.

Before we can estimate that, we have to find everything that uses an address. And testing can't stop at whether a second one can be saved.

The size of a change is set by what depends on it, not by how much of it you can see.

What happens after the code is written

A feature isn't finished when its code is written. I usually compare it to fitting a window: you don't just buy one and shove it into the wall. There's the frame, the insulation, flashing to keep the rain out, painting and finishing. A feature has the same kind of work around it:

• Automated tests, written alongside the code, catch a later change that quietly breaks this one. All the more when AI wrote part of it.
• Code review by another developer, because a second pair of eyes often catches what the first missed. A freelancer working alone has nobody to do that, so I'd ask for more testing.
• Testing by someone else, because ‘it works on my machine’ doesn't mean it works on anyone else's.
• Your approval, where it's agreed, so you can check it's what you pictured.
• The release, where the backend, the part on the server, may go out at a different stage from the frontend, the part people see. Rushed, it can break what worked.
• Checking the release, so a broken one doesn't sit there unnoticed.
• Documentation, which I update while building so it doesn't drift from the code.
• Tracking. Each piece of work gets a ticket, a record that moves from ‘to do’ through review and test to ‘done’, so you see what's stuck and hear when it's out.
• Clean-up. I usually tidy the code comments as I close a ticket, so stale ones don't mislead the next person.

Several of these overlap. Fixing what review and testing turn up is part of the job, so our estimates leave some headroom for it. If that isn't enough, you decide how to go on.

An iOS and Android app also goes through two app stores' reviews, which aren't working time but hold up the release.

Why the state of the existing code moves the number

The same feature takes more or less work depending on the code it lands in. Before we estimate a change in someone else's code, we want access to everything it touches, frontend and backend. A mobile app that hasn't been maintained may first need the tools it's built with, and the ready-made parts it uses, updated for current iOS and Android versions, sometimes before it can be estimated reliably.

A new supplier has to learn the system first, which is work too. Alongside the estimate, we often give a first assessment of the code: where it's weak and what may need refactoring, meaning restructuring without changing what it does. A rewrite isn't the default. Most systems can still be extended.

If the estimate is too big, cut features, not checks

When the number is too big, the tempting cut is the work nobody sees. Yes, you can shrink it by dropping the tests and the review. But what happens when something breaks? The hours you saved go on fixing it. The first invoice gets smaller and the later ones bigger. That's penny-wise and pound-foolish.

Cut from the product instead: secondary features, optional links to other systems, decoration and nice-to-haves. Build the core, and build it well.

A prototype is for learning, so placeholder data and throwaway code are fine. A minimum viable product (MVP) has real users, so it should be minimal in features, not in quality. There will always be bugs. The aim is fewer, not none.

A founder building their own product may have more time than money, and can choose to carry the risk and fix what breaks at three in the morning. An agency works on different terms, and getting one out of bed at three costs more than getting it in at nine.

And the app someone built over a weekend with AI? Its builder may well have had years of experience, templates and groundwork behind them. The weekend is only the part you saw.

An estimate is not a fixed price

An estimate is the work the supplier expects, based on assumptions: that the code is in decent shape, say, or that other systems behave as they should. If one doesn't hold, the number moves.

What happens then depends on how you pay. By the hour, the overrun is yours. At a fixed price it's the supplier's, so the price has to include room for setbacks. That cuts both ways: if the work goes quicker, you've paid for hours nobody spent.

We work both ways. Which suits you depends on what matters more: the price or the result. A fixed price needs the hard decisions made up front, and scope changes or new features are billed separately.

Either way, I wouldn't judge an estimate by its total. I'd look at the scope, the assumptions, what gets delivered and who carries the risk. A supplier who can't explain how the time will be spent is a warning sign.

What to send and what to ask about any software estimate

Both lists work on any supplier's estimate, ours included. You don't need everything in the first; a supplier can help you put it together.

Send this before you ask for an estimate

Ask this when the number comes back

Through our software development work, we help turn an idea or an existing app into what an estimate needs: requirements and technical planning. A good estimate should show you the frame, the insulation and the flashing, not just the window.