App projects almost never run over because the engineering was slow. They run over because a decision made before development started quietly guaranteed rework, and the rework surfaced halfway through the build when it was most expensive to absorb. We have rescued 15+ platforms in the past 3 years, and the post-mortems are remarkably consistent - by the time a project is visibly late, the cause is usually eight to twelve weeks behind it.
Below are the five decisions that produce most overruns, in the order they typically get made. None of them look like mistakes at the time. That is precisely the problem.
1. Starting the build before scoping is actually finished
The most expensive sentence in software is "we will work out the details during development". It sounds pragmatic and it is often said by people who have been burned by over-planning elsewhere. But an unresolved detail does not stay small - it becomes a decision someone makes under time pressure, usually a developer who does not have the commercial context to make it well.
The tell is a scope document that describes screens rather than behaviour. "User profile screen" is not a specification. What happens when two users claim the same handle, what a deleted account leaves behind, and who can see what - those are the decisions that determine the data model, and the data model is the thing you cannot cheaply change later.
This is why our scoping and design phase is a paid, standalone engagement rather than a free pre-sales exercise. A free discovery phase is priced as a sales cost, so it is scoped to win the work rather than to de-risk it. That is a structural conflict, and the client pays for it later.
2. Treating design as decoration
When design is understood as the visual layer applied to an agreed system, it gets compressed whenever the schedule tightens. The result is that interaction decisions - the ones that determine how many states a screen has, and therefore how much there is to build and test - get made in the build, one screen at a time, by whoever is on that ticket.
The cost does not show up as a design overrun. It shows up as a test cycle that keeps finding cases nobody specified, and a stakeholder review that reopens settled questions because it is the first time anyone has seen the whole flow.
Design done properly reduces build scope. It is the cheapest place in the project to discover that a feature is unnecessary, and the most expensive place to discover it is production.
3. Choosing an MVP architecture that cannot carry version two
An MVP is a commercial instrument, not a technical one. It is supposed to answer a question cheaply. The failure mode is not building an MVP - it is building an MVP whose architecture assumes the answer will be no.
We refactored the Move With Us user program engine from duplicated per-user data to templates, and the numbers show what the original shortcut had cost - the core workout table shrank from 42GB to 0.9GB, a 98 percent reduction, and database CPU peaks fell from 40 percent to under 5 percent. Nothing about that original decision was unreasonable when the platform was small. It simply did not survive 200,000 users, and by then it was load-bearing.
The question worth asking at architecture time is not "is this the best design" but "which parts of this are cheap to replace, and which are structural". Get the structural ones right and the rest can be deliberately rough.
4. No single decision-maker on the client side
This is the one nobody puts in a risk register, and it is the most reliable predictor of a late project. When three stakeholders each hold a veto and none holds the decision, every question takes a week and some questions never resolve at all. The build does not stop, it just proceeds on assumptions, and the assumptions get corrected after they are built.
The fix is unglamorous and it is a client-side decision rather than a vendor-side one: name one person who can settle a scope question inside 48 hours, and give them the authority to do it. Projects with that person land on time far more often than projects with a better specification and no such person.
It is also why we take on 5 to 10 clients per year rather than running high volume. A partnership that averages 7+ years does not survive on ticket throughput, and the relationships that work are the ones where decisions get made rather than escalated.
5. Deferring quality assurance to the end
QA scheduled as a phase after development is not quality assurance, it is a defect discovery event with no time left to act on it. Everything it finds arrives at the point in the schedule where the only available responses are to ship it or to slip.
Run as its own discipline alongside the build, on real devices in real conditions, it does the opposite - it converts unknowns into known work while there is still room to absorb them. Products built under our Smart Engineering model launch with 40 percent fewer bugs, and we reach 95 percent test coverage, subject to agreed scope and engagement, with senior engineer review on every release.
The practical version of this is simple: if the first full end-to-end test happens in the last fortnight, the project is already late and nobody knows yet.
What a project that does not run over looks like
It is not the one with the most detailed Gantt chart. It is the one where the expensive decisions were made early, deliberately, by people with enough context to make them - and where the schedule had somewhere to put the surprises.
For Pilates Obsession we built and launched a full-featured platform live within 12 weeks and on budget. Revia reached number 3 in Apple's Health and Fitness category within 48 hours of launch, after a 4-month build. Neither of those was a faster team. They were projects where the five decisions above were made once, properly, at the front.
If you are scoping a build and want the overrun risk taken out at the start rather than discovered in the middle, talk to us. If you already have a project that is running over, that is a different conversation and we have had it many times - start with app rescue and modernisation.