What Actually Goes Wrong in App Projects (And What It Costs in Hours)

Ask what went wrong on a project that overran and you rarely hear about bad code. You hear that something turned out to be bigger than anyone thought, and that it turned out that way in month three rather than in week one.

Below are the five failures we actually see, and what each one costs in the model we use for every estimate. The hour ranges are the same ones our cost calculator runs on. They are not a market average and not a warning label: they are the size of the work that gets left out.

1. The system you already run turns out to be undocumented

This is the most expensive surprise in commercial software, and the easiest one to talk yourself out of before the build starts. Someone says the CRM has an API. It does. The API is not the problem.

The problem is everything the API does not describe: which fields are actually populated, which of them mean something different from their name, what happens at the rate limit, what the system does at month end when someone runs a batch job nobody documented. You do not integrate with an API. You integrate with a decade of other people's decisions.

In our model, third-party and internal integrations are a module of their own, priced at 70 to 180 hours. The spread between those two numbers is almost entirely the difference between a documented system and a system that someone will have to reverse engineer.

What to do about it: before the estimate is signed, ask for one real export of the data and one sandbox credential. A vendor who has seen the actual system estimates differently from one who has seen a description of it.

2. Compliance shows up in month three

Compliance work does not look like work in a feature list. Nobody writes a ticket called GDPR. So it gets discovered when someone from legal, procurement or a customer's security team reads the plan and asks a question that has no answer yet.

Then it becomes engineering: audit trails, consent flows, data retention and deletion, access controls that other features have to respect, and a review of all of it by someone who did not build it. In our model that is 80 to 200 hours, and it is the one module where the high end is common rather than rare.

It also has a shape the other modules do not: parts of it are waiting. You answer questions, you wait for a review, you answer more questions. A team can be finished with the build and still not be shipping.

What to do about it: name the regimes you are subject to before scoping, not after. Health data, card payments and public sector procurement each change the plan, and they change it least expensively at the start.

3. Migration is treated as a script

Moving data out of a system you already run sounds like a one-time task, and the first ninety percent of it usually is. Then you meet the records that do not fit: the customer with two accounts, the order with a currency that no longer exists, the field that three different teams filled in three different ways over six years.

Every one of those needs a decision, and the decision is a business decision, not a technical one. That is why in our model migration is 70 to 170 hours and why the range is so wide. The script is cheap. The exceptions are the work.

What to do about it: pull a real sample of the oldest data you have, not the newest. The newest data is clean because your current process made it clean. The oldest data is what the migration has to survive.

4. The calendar was divided, not planned

This one is invisible in the estimate and obvious in month two.

If a plan quietly assumes people work forty productive hours a week on features, the date it produces is arithmetic rather than a forecast. Code review, design handover, clarifications, releases, a broken pipeline and an interview are all real work that is not feature work.

We count about 18 focused hours per person per week. That number comes from checking the plan against what we delivered: our largest recent platform ran 3,086 hours over 31 weeks with a team of five to six, and 31 weeks x 5.5 people x 18 hours is 3,069 hours. Plan and outcome are 0.55 percent apart.

The failure this causes is not lateness on its own. It is the response to lateness: adding people to recover a date. That works, but not the way it looks on paper. The work does not shrink, it runs in parallel, which means more interfaces, more coordination and more rework. Parallel effort buys calendar and pays for it in hours.

What to do about it: ask any vendor, including us, what weekly hours per person their timeline assumes. There is a fuller version of this question set in how to read a development estimate.

5. Scope keeps moving because nobody owns the decision

The other four failures are things nobody knew. This one is a thing nobody decided.

If every design choice needs the founder, and the founder is travelling, the project runs at the speed of one calendar. If two stakeholders want different things and neither has to be the one who concedes, the disagreement does not stay in a meeting. It turns into a screen that gets built, reviewed, rejected and rebuilt, which is how a week of ambiguity becomes three weeks of work.

We do not publish a percentage for this, because we have not measured it in a way we would be willing to defend. What we can say is that in our experience unclear requirements move a timeline more than any technical decision on the project, including the platform choice.

What to do about it: before development starts, write down who decides what, and give the team explicit permission to decide the rest. It costs an afternoon.

The two that get retrofitted

Two more items belong here, not because they are dramatic but because they are almost always postponed and almost always come back.

Performance is 50 to 110 hours in our model when it is planned. Retrofitted after launch, it is the same work plus everything that was built on top of the slow version.

Accessibility is 60 to 130 hours when it is designed in. Added afterwards it touches every screen that already exists, and if you sell to the public sector or to large enterprises it is not optional, it is a procurement requirement you will meet either before or after losing a deal.

Why these are hours and not a warning

None of the five is a reason not to build. Every one of them is a number that exists whether or not it is in the plan. The only real choice is when it appears.

That is the case for discovery, and it is the whole case. Discovery does not make the work smaller. It moves the discovery of the work to the point where changing course is still free. A screen redesigned in a document costs an afternoon. The same screen redesigned in month three costs the build, the review, the rebuild and the testing of both versions.

Run it against your own scope

If you want to see what these modules do to a specific project, our cost calculator takes the product type and the modules you need and returns hours, a realistic timeline and the team size, using exactly the ranges above. It takes about a minute and does not require a call.

The reasoning behind the timeline is in how long it takes to build a mobile app, and the full module-by-module breakdown is in what an app actually costs. If you would rather just describe the project, tell us what you are building and we will come back with a scoped estimate and the assumptions written down.

Questions people ask

What is the single most common reason a project overruns?

Requirements that keep changing after the build has started. It outranks every technical factor we deal with, and unlike most of them it is fixable before a line of code exists.

Can a fixed price protect us from this?

Only where the scope is genuinely fixed and written down. Where it is not, the price still moves, it just moves through change requests instead of through the estimate. A fixed price is a scope decision before it is a commercial one.

How do we tell whether a vendor has thought about our existing systems?

Their estimate mentions them by name and states what it assumed about each: whether it is documented, whether there is a sandbox, what happens to the number if there is not. An estimate that does not mention your stack has not priced it.

Is it worth paying for discovery if we already know what we want?

If you can already answer who decides what, which systems you must integrate with and which compliance regimes apply, then you have effectively done it and you should say so and skip it. Most teams find that writing down the answers is where they discover which ones they do not have.