Why Dont Executives Understand How Long Apps Take?

An executive hears "we need an app" and pictures a timeline. Something like six weeks, maybe eight. They have seen apps built before, or they think they have, and the mental model they carry is mostly made of the parts that are visible: screens, buttons, a login page, a feed. What they are not picturing is the three weeks of discovery before anyone opens a design tool, the alignment sessions that have to happen before a single user story gets written, the iteration cycles after sign-off that nobody budgeted for, and the rework that follows when two of the five decisions made in week one turn out to have been the wrong ones.

The parts of a project that cost the most time are almost entirely invisible from the outside.

This gap between what an executive imagines and what an app actually requires is a failure of visibility. The parts of a project that cost the most time are almost entirely invisible from the outside. Nobody sees a discovery phase. Nobody sees a refinement session that was meant to cut scope and instead added four new features. Nobody sees the two months of extra work that follows a decision to skip a step.

We have watched this play out across multiple projects, and the pattern is consistent. The timeline conversations that go wrong almost always go wrong for the same reasons, and almost all of them could have been avoided if everyone involved had understood what an app actually contains before the first estimate was written.

What Executives Actually Price When They Estimate an App

Ask an executive to estimate how long an app will take and they will usually price the build. Screens, features, the list of things the product needs to do. That is the mental model: a fixed set of requirements, a team that writes code, a timeline that reflects the size of the list. The assumption is that if the list is small, the timeline is short, and if the list is large, the timeline is long.

The problem is that the list is almost never fixed at the start. Requirements change. Stakeholders remember things they forgot to mention. A feature that seemed simple in conversation turns out to require three other features before it will work. And the work that happens before and around the build, the discovery, the design, the testing, the alignment, none of that appears anywhere in the original estimate because it was never part of the original mental model.

This is not a new problem. Geneca's research found that up to 77% of software project respondents do not know how to tell when their project is "done", and fewer than 20% believe their requirements are aligned with the business before work begins. The estimate that an executive produces is, in most cases, an estimate of a product that does not yet fully exist, built on requirements that have not yet been properly defined, which is one of the core reasons app development cost so frequently exceeds what was originally anticipated.

What gets priced is the optimistic version. What gets built is the real one.

The Work Before the Build: Discovery, Alignment, and Design Thinking

Discovery is the phase that executives most often want to remove. It does not produce anything they can see, it costs money before a line of code is written, and it feels like a delay to the thing they actually want. The argument for skipping it usually sounds like this: "We already know what we want. Let's just get started."

The trouble is that knowing what you want and knowing what you need are different things, and the gap between them is where most project budgets disappear. Discovery is how you find out whether those two things are the same. It is where you surface the assumptions that would otherwise become expensive surprises mid-build. It is also where you get an estimate you can actually rely on. Without it, an estimate has roughly ±50% accuracy. A paid discovery phase can bring that down to ±10-20%, according to Devtimate.

Clients who arrive with a fixed budget often try to reshape our process to fit that number rather than letting the process define the actual scope and cost. We push back on this consistently, and we work to bring those clients through a proper discovery phase first. The reason is simple: the discovery almost always surfaces a more appropriate, more cost-effective solution than the one the client arrived with. Skipping it does not save time. It borrows time from later in the project, with interest.

Before any build begins, set aside dedicated time for discovery. Even a short, structured discovery phase produces a more accurate scope and a more reliable estimate than any amount of upfront assumption.

When Skipping Decisions Costs More Than Making Them

The most expensive decisions in a project are the ones that do not get made early. A gap in the thinking at the start becomes a structural problem in the build, and fixing it later costs significantly more than resolving it during discovery.

We worked on a dating app focused on verified profiles, where the core premise was preventing bots and fake interactions. The client chose to skip discovery for the messaging component, wanting to focus all the discovery effort on the onboarding process instead. The logic made sense to them: onboarding was the harder problem. Messaging, they assumed, was standard.

The result was a generic messaging feature that directly contradicted the product's founding principle. It allowed automated messages. It allowed fake messages. Everything the onboarding had been built to prevent, the messaging made possible. The mismatch was not a design error. It was a decision error, one that happened before any design or build work began, in the moment the team agreed to skip a step.

The mismatch between verified onboarding and the permissive messaging system meant the entire section had to be rewritten.

Correcting it required a full rewrite of the messaging section: approximately £15,000 in additional budget and two months of extra work. The decision to skip discovery on one component did not save time. It cost more time, more money, and a significant amount of trust between the team and the client. Making the decision properly at the start would have cost a fraction of that.

How Scope Creep Starts Before a Line of Code Is Written

Scope creep has a reputation for being a build-phase problem, something that happens when developers are halfway through a feature and a stakeholder asks for something new. But the most damaging scope creep usually begins before the build starts, in the conversations where requirements are being shaped.

The pattern works like this. A stakeholder describes a feature in general terms. The team writes it up and moves on. Three weeks later, in a refinement session, the same stakeholder sees the feature described in more detail and says, "Yes, but obviously it also needs to do this." The "obviously" is doing a lot of work there. What they are describing was never discussed. But in their mind, it was always implied.

We saw this on a sports club app designed to manage finances, games, schedules, and players across multiple sports. From the outset, the client rejected any incremental release strategy. They did not want to launch with a single sport. They did not want to launch on a single platform. They did not want to start with an MVP. They wanted everything, and they wanted it all at once. That position, established before any code was written, created the conditions for a project that could only ever expand.

The features that emerged in those early conversations were always broader than they first appeared. Each one contained several other features that nobody had mentioned, each of which contained further requirements. The scope was already growing before the first sprint began.

When Refinement Sessions Make the Product Bigger

A refinement session is supposed to clarify. The team sits down with a feature, looks at it closely, and works out the detail. Ambiguities get resolved. Edge cases get handled. The feature becomes smaller, more precise, and easier to build. That is what refinement is for.

On the sports club app project, refinement sessions worked in the opposite direction. Every session intended to narrow a feature down ended with a larger scope than it started with. As the team examined each element in detail, the co-founders would identify requirements they had never previously raised: "Well, of course it needs to do this." Each addition was presented as obvious, as something that had always been assumed. None of them had been discussed before. All of them were adamant about fitting into the product specifications.

This happened consistently across the project. The refinement process, which should have been a cost-control mechanism, became an expansion mechanism. The more carefully the team looked at the product, the bigger it got.

Before a refinement session, send stakeholders a written summary of what the feature currently covers. Ask them to confirm the scope in writing before the session, not during it. This separates "refinement" from "addition".

The dynamic was driven partly by how close the two co-founders were to the product. Both lived and worked in the environment the app was designed for. Both had strong, independent views about what the product needed. And because the app was the business itself rather than a tool sitting alongside one, both founders treated every omission as a flaw. The refinement sessions became the place where those convictions surfaced, one feature at a time.

The All-or-Nothing Trap: Why Phased Releases Get Refused

The argument for a phased release is straightforward. Launch with a limited feature set, get real users, learn from them, and build the next version on evidence rather than assumption. The product that reaches the market is smaller, but it reaches the market. And the product that gets built next is better because it is shaped by what actually happened rather than what was predicted.

Executives and founders often refuse this. The reasons vary. Sometimes it is pride: a partial product feels like an admission that the full vision is not ready. Sometimes it is fear: a minimal launch might not impress enough people to justify the investment. Sometimes it is logic that sounds reasonable in a boardroom but does not survive contact with the market: "If we are going to launch, we should launch properly."

We watched this trap close on the sports club app. The team recommended launching with a single sport on a single platform, testing the market, and growing from there. The client pushed back at every stage. They wanted everything launched at once and refused to go to market until the full product was complete. That position held firm throughout the project. The consequence was a product that kept expanding, a budget that nearly doubled, and a timeline that stretched from a projected three to four months to twelve to fourteen months before the project ended without anything reaching the app store.

The Standish Group's CHAOS Report found that 31.1% of software projects are cancelled before completion. The all-or-nothing stance is one of the cleaner routes to that outcome.

When Sign-Off Isn't Really Sign-Off

Sign-off is supposed to mean a decision has been made. The design has been reviewed, questions have been answered, and the team has permission to build. Everyone moves forward. But sign-off that is given to be polite rather than as a genuine decision does not mean any of that. It means the conversation is being postponed, not concluded.

We worked on a fitness and wellness product with two co-founders who were new to the app development process. The cycle repeated itself across multiple stages: we would reach design sign-off, begin the build, and then the clients would walk back their approval. The reason given was that they had not understood it was what would actually be built. The design had been agreed. The build had started. But the agreement had not been real.

The two founders had not reached consensus with each other. Sign-off was being given by one or both of them to keep the project moving, not because the decision had genuinely been made. We flagged this repeatedly and warned that budget was being spent on design iterations that would not materially improve the product. That did not change the pattern. The project eventually exhausted its budget in the design and research stage, before the build had meaningfully progressed.

Require both stakeholders to sign off in writing on the same document, at the same time, before build begins on any feature. A sign-off that cannot be confirmed in a single written approval from all decision-makers is not a sign-off.

What Ignored Advice Actually Costs in Time and Money

Professional advice on a project has a cost attached to it when it is ignored. That cost is usually invisible at the moment the advice is dismissed, and very visible several months later.

The sports club app is the clearest example we have. The team warned early in the project that the budget would spiral out of control and that the client risked running out of funding before launching anything. Those warnings were noted and set aside. The client continued adding features through every stage of the project. What should have reached the market in three to four months never launched after twelve to fourteen months of development. The budget almost doubled. The project ended with the entire budget exhausted, nothing published to the app store, and the agency and client parting ways.

Every one of those outcomes was forecast. The team could see where the decisions were leading and said so. The forecasts were accurate. The advice was not followed.

A parallel outcome unfolded on a grassroots football app where the founders built from their own conviction about what the product should do, treating competitor features as a checklist rather than a context. The team advised against cramming too many features into a single product. The advice was not taken. The product became too complex to continue, development stopped, and more than a year later there is still no publicly visible marketable release, only a series of "coming soon" announcements.

Ignored advice does not disappear. It accumulates, and it charges compound interest.

How to Have an Honest Timeline Conversation with Your Team

The timeline conversation that needs to happen at the start of a project is not the one that usually does happen. The one that usually happens is a negotiation: the executive names a date, the team pushes back a little, and a compromise is reached that neither side fully believes. The honest version looks different.

An honest timeline conversation starts with the work, not the date. It runs through each phase in sequence and accounts for the time each one actually takes.

1. Discovery and research, including user interviews, competitor review, and requirements alignment.
2. Design, including wireframes, prototyping, and the iteration cycles that follow each round of review.
3. Build, broken into the features that are genuinely MVP and the ones that belong in a later phase.
4. Testing, including the time required to fix what testing finds.
5. Launch preparation and the contingency buffer that every project needs and almost none include.

Running through that list with stakeholders before any estimate is agreed changes the conversation. It makes the invisible work visible. It gives everyone the same picture of what is being built and what it actually contains. And it creates a shared reference point when scope starts to grow, because it will.

The most useful thing an executive can do at the start of a project is resist the pull toward a committed date before the discovery phase has produced a real scope. A date agreed before the work is understood is a guess dressed as a plan, and it will cost more to defend than it would have cost to get right.

Conclusion

The gap between an executive's timeline estimate and the actual time a project takes is, almost always, a gap in visibility. The parts of a project that are hardest to estimate are the parts that cannot be seen from the outside: the decisions that were deferred, the sign-offs that were not real, the refinement sessions that expanded the scope, the features that turned out to contain five other features.

Every project we have described in this article had clear warning signs early on. The dating app had a messaging component that had never been properly thought through. The sports club app had stakeholders who would not accept a phased approach, and refinement sessions that consistently made the product larger. The fitness and wellness product had a sign-off process that was not genuinely working. In each case, the team could see what was coming. In each case, the warnings were not enough on their own to change course.

What changes course is a shared understanding of what an app actually involves, built before the first estimate is agreed, and maintained through every stage of the project. That understanding has to include the work before the build, the cost of skipping decisions, and the real consequences of ignoring professional advice. When it does, the timeline conversation becomes honest. And an honest timeline conversation, early enough, is far cheaper than an expensive surprise at month ten.

If your team is about to start an app project and the timeline conversation has not felt quite right, let's talk about your project before the build begins.

Frequently Asked Questions