"How long will this take?" is one of the first questions every client asks, and the honest answer is always "it depends on scope," which sounds like a dodge even though it's true. The more useful thing to explain is what scope actually changes, and why most delays don't come from the part people worry about most.
The rough shape of different projects
A focused internal tool, replacing one manual process with one shared system for one team, is often measured in weeks. The scope is narrow enough that most of the decisions are already made before work starts: who uses it, what it needs to do, what data it touches.
A platform with multiple user roles, several core workflows, and integrations with other systems usually runs several months, not because any single piece is hard, but because there are more decisions to make and more places for those decisions to interact with each other. Authentication touches permissions, permissions touch the data model, the data model touches every screen built on top of it.
An MVP sits somewhere in between, and its timeline depends entirely on how disciplined the scoping was. A tightly scoped MVP that tests one specific assumption can move fast. An MVP that quietly grew to include half the features of the "real" product is not really an MVP anymore, and it will take about as long as building the real product would have.
Where the time actually goes
Coding is rarely the bottleneck. The two things that reliably blow up a timeline are scope creep (new requirements arriving mid-project without anything else coming off the list) and unclear requirements (discovering, partway through, that "the client portal" meant something different to the client than it did to the team building it).
Both of these are avoidable, and neither is fixed by writing code faster. They're fixed earlier: by scoping tightly before work starts, and by defining what "done" looks like for each piece before it's built, not after.
How to protect a deadline
Milestone-based delivery helps because it forces the vague parts of a project to become concrete on a schedule, instead of all at once at the end. If a requirement is still fuzzy when its milestone arrives, that's visible early, while there's still time to make a decision about it.
The other lever is deciding early what's deferrable. Most projects have a handful of features that feel essential but aren't required for the software to be genuinely useful on day one. Naming those explicitly, and agreeing they can wait, is usually what separates a project that hits its deadline from one that doesn't.
If you're scoping a project and the timeline still feels uncertain, that uncertainty is almost always about scope, not about how fast anyone can write code. Getting the scope right, whether that's a full custom software build or a first MVP, is the part of the schedule worth spending real time on before anything else starts.