Anyone who gives you a number in weeks before seeing a written scope is guessing. The industry mostly stopped estimating in weeks and months for exactly that reason, and uses sizes instead.

That is not developers being evasive. It is that the honest answer to "how long will this take" is a range, and a range expressed in weeks gets remembered as a date.

Why estimates are wrong so reliably

Nobody knows until they get in there. An engineer cannot tell you how long something takes until they have done the feasibility work. Before that, what you get is a feeling.

The gap in expectations is enormous. People think adding a feature should take 10 or 20 minutes, when writing it properly might take two days. The expectations end up wildly out of proportion, because it is hard to see how much time it takes to write code and write it well.

Scope moves. Every change after work has started costs time, and often rework.

Work expands to fit. Any task will fill the time you give it. Give yourself two days for something and it takes two days; give yourself two hours and you finish it in two hours, though you may not love it.

Ask for a t-shirt size, not a date

This is what I teach non-technical founders to do, and it works with a freelancer or an agency:

Go through your feature list with the engineer and ask them to size each item: small, medium, large, extra large. Say it out loud like this: I know you don't know yet, because you need to get in and do the feasibility work, but give me an idea of how big you think this would be to build.

Sizes work because they are honestly a range. Weeks and months pretend to be precise, which is why software teams do not usually put dates on a roadmap.

Sizes are also useful the other way. If there is a feature you suspect is not worth it, getting the engineer to say out loud that it is huge is often enough to settle the question.

Remember that huge does not only mean long. It can mean complex. Something may take three weeks to build and then leave you dealing with the fallout of bugs for months.

What AI changed, and what it didn't

When I size my own work I estimate it as though AI is not in the picture: one person, by hand, as an engineer. Nobody has a dependable way to estimate AI-assisted work yet, and an estimate built on a speed-up you cannot predict is worse than a slow honest one.

Two things I do see. AI is speeding up junior developers, and it tends to be slowing down senior ones, because they have far more checking to do. And if you want a sanity check on a plan, a useful question to ask an AI is whether the thing could be built entirely with AI, and how long it would take if an experienced engineer directed it without writing the code.

Also worth knowing: more people does not mean faster. You can go faster with 10 people than with 45, because of the coordination.

The part you actually control

You cannot control how fast someone writes code. You control how much they have to build, and how clear it is.

• Decide what is in the first release and write it down, including what is deliberately out.
• Release in pieces rather than scoping the whole thing and launching fully built. That gives you room to course correct before you have paid for all of it.
• Get your beta testing in against the important features rather than building everything first and then testing.

A clear written scope removes most of the mid-build interruptions, and those interruptions are where the overruns live.

What to do with an estimate you are given

Ask what is included and what is not. Ask what would have to be true for it to take twice as long. Ask which items they sized as large, and why. Then decide what to cut, rather than hoping.

Keep reading

How Much Does It Actually Cost to Build an App in 2026?

What Do I Need to Know Before Hiring a Developer?

What Is a Minimum Viable Product and Do I Actually Need One?

Learn this with me

Breaking your product into themes, feature sets and individual features is class 7 of From Passion to Product, my free six-week live course, and the build timeline sits in class 8. You finish with a written scope and a prioritised feature list, which is the thing an estimate can actually be made against.

Most estimates are wrong because there is nothing specific to estimate. The course fixes the input rather than the estimate.

Join the waitlist for the next free cohort, or get the App Strategy Workbook and scope it yourself now.