--- title: Why Dont Executives Understand How Long Apps Take? description: Executives routinely underestimate how long apps take to build, this article explains why. From skipped discovery to premature budget sign-off. image: https://weareaffective.com/hubfs/learning-centre-images/why-dont-executives-understand-how-long-apps-take.webp --- [Skip to content](https://weareaffective.com/learning-centre/why-dont-executives-understand-how-long-apps-take-1#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Why Dont Executives Understand How Long Apps Take? Table of Contents A senior stakeholder signs off a budget in a single meeting. A product team spends the next six months trying to build something that was never properly defined. The budget runs out before anything reaches the app store, and the stakeholder is genuinely baffled about why. the gap between executive expectations and delivery reality is structural, built into the way decisions get made before the work even starts. > The gap between executive expectations and delivery reality is structural, not accidental. The assumption that drives most of these situations is that building an app is roughly like commissioning a piece of marketing. You describe what you want, you agree a price, you wait for delivery. What actually happens is more like building a house while the architectural drawings are still being argued over, the client keeps adding rooms, and nobody has agreed whether the foundations need to go deeper. The analogy sounds extreme. The sports club app we worked on, which ended with the entire budget spent and nothing published to the app store, proves it is not. Understanding why executives consistently underestimate app complexity, and what product leads can do about it before the budget is locked, is one of the most practical things a product team can work on. The problem is solvable. But only if the right conversation happens early enough. ## The Gap Is Real, and It Starts Before the First Meeting Executives tend to arrive at project kick-offs with a number already in their head. That number came from somewhere, a competitor's product they admire, a conversation at an industry event, or a figure someone mentioned over lunch. It bears no relationship to the actual scope of what they are asking for, because the scope has not been defined yet. The number got set before anyone understood the problem. This is not carelessness. Executives operate under genuine time pressure, and they are used to working with rough estimates that get refined later. The trouble is that app development does not work on that model. A rough estimate for a construction project is anchored to physical constraints, materials, labour, site conditions, that can be measured. A rough estimate for a digital product is anchored to assumptions, and assumptions are the one thing that discovery is supposed to interrogate. We worked with a travel company targeting a younger demographic whose previous app build had been a poor experience. They arrived with considerable scepticism and a fairly fixed view of what they wanted. The expectation was that we would confirm their thinking and begin building. What they got instead was a [structured discovery process](https://weareaffective.com/learning-centre/the-meeting-notes-that-should-exist-before-a-development-quote-lands), and by the end of it, the product they were planning looked substantially different from the one they had described. The final product was significantly better than anything they had previously launched, but only because the initial assumption was challenged before a single line of code was written. ## How Budgets Get Signed Off Before Anyone Knows What They're Building The budget approval process in most organisations is designed around predictable, recurring costs, headcount, licences, office space. Approving a software build requires attaching a number to something that does not yet exist, and the people asking for approval are rarely in a position to give an honest range because they have not done the work to produce one. What happens instead is that someone in the product or technology team gets asked to produce an estimate. They produce something, often with very little information, and that number travels upward through the organisation, losing its caveats at every stage. By the time it reaches the approval meeting, it is no longer a rough estimate with a list of assumptions attached. It is a budget. It gets signed off as though it were a fixed price for a defined piece of work. A ballpark estimate produced without a discovery phase carries roughly plus or minus 50% accuracy, according to [Devtimate](https://devtimate.com/glossary/discovery-phase/). A figure produced after proper discovery narrows to plus or minus 10 to 20%. The difference between those two ranges, on a £200,000 project, is the difference between a product that launches and one that does not. When clients come to us having already asked around for quotes and [arrived with a suggested budget](https://weareaffective.com/app-development-cost), what they are actually arriving with is a number built on the wider range, and they are treating it as though it came from the narrower one. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Why Executives Underestimate App Complexity The most consistent driver of underestimation is the consumer experience of apps. Executives use apps every day. They are [smooth, fast, and feel simple](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). That experience creates a strong and entirely misleading intuition about how apps are built. What feels simple to use is often extraordinarily complex to build, and the parts of an app that feel most invisible to the user are frequently the most time-consuming to construct. A single sign-in screen, for example, might involve authentication logic, password recovery flows, token management, session handling, and a series of error states the user will hopefully never see. None of that is visible when you tap "log in". The same principle applies across every feature. Notifications, search, user-generated content, real-time updates, each one carries a weight of back-end work that the front-end experience deliberately conceals. > What feels simple to use is often the most complex thing to build. There is also an API complexity problem that rarely gets explained clearly. Not distinguishing between building an API from scratch and integrating an existing one can cause a budget to be underestimated by a factor of three to five times, according to [Planeks](https://www.planeks.net/api-cost-calculator/). Executives are not expected to know this distinction. But if no one explains it before the budget is set, the number that gets approved is built on a misunderstanding of the work. Before any budget conversation, give the approving executive a two-page summary of the hidden complexity behind one feature they consider obvious. Walk them through what sign-in actually involves. This resets expectations more effectively than any project plan. ## Scope Creep in Reverse: When Refinement Sessions Make Things Bigger Most people understand scope creep as a gradual accumulation of new requests that arrives after a project has started. What we observed on the sports club app was something different and, in some ways, more damaging. The refinement sessions designed to reduce scope consistently produced a larger product. The two co-founders on that project were deeply embedded in the world the app was designed for. They were not occasional users imagining a product, they lived and worked inside the problem the product was meant to solve. Every refinement session gave them a new opportunity to notice something they felt was obviously missing. "Of course it needs to do this. Of course it needs to do that." Each addition seemed self-evident to them. None of them had been part of the original scope. As Simon put it: "We ended up with a bigger product at the end, which is the complete opposite of what you should have." The refinement process had become an expansion mechanism. Every session intended to bring the product into focus instead added surface area to it. This is a structural risk when stakeholders are close to the product and the product touches their professional identity. In refinement sessions, document every new item raised as a separate list labelled "future consideration". This separates the act of noting an idea from the decision to include it, and prevents additions from being absorbed into the current scope by default. ## What Happens When Discovery Gets Skipped Discovery does not feel productive when you are under pressure to start building. It produces documents rather than screens, questions rather than answers, and it costs time that executives often see as delay. So it gets cut, compressed, or skipped entirely. The assumption is that the team knows enough to begin. On the communications product we worked on, the client repeatedly chose not to allocate time to addressing accumulating technical debt during the build. Each time it came up, there was always something more pressing. The debt was left to accumulate until the product became fragile at a structural level, which was a serious problem, because the product's entire value proposition was built on trust and security. A fragile product and a trust-based promise are incompatible. We eventually reworked core mechanisms and flows to make the product consistent again, but only after the fragility had already become an issue. Skipping or compressing discovery produces similar results. The work still has to be done, it just happens later, under pressure, and at a higher cost. According to [Devtimate](https://devtimate.com/glossary/discovery-phase/), projects that skip discovery are three to five times more likely to fail or exceed budget. The discovery phase does not slow projects down. It prevents the much more expensive work of rebuilding things that were designed without enough information. 1. Assumptions that were never surfaced become design decisions 2. Design decisions get built into the product before anyone tests them 3. Testing reveals the mismatch, and the rework begins 4. Rework costs more than the discovery phase would have ## The Cost of a Skipped Decision: A £15,000 Lesson We worked on a dating app whose core premise was verified profiles, a product built specifically to eliminate bots and fake accounts. The onboarding process was carefully designed to enforce that verification, with every step thought through in detail. The messaging component was treated differently. The client wanted to skip discovery for that section and focus the available time on onboarding. The assumption was that messaging was straightforward enough not to need the same level of scrutiny. What got built was a generic messaging feature. It allowed automated messages. It allowed fake messages. It contradicted everything the onboarding process had been designed to prevent. The mismatch between a rigorously verified onboarding flow and an open, permissive messaging system was fundamental, and it was not visible until the two parts of the product were seen together. Rewriting the messaging section cost approximately £15,000 in additional budget and two months of additional work. The original discovery session for that component would have cost a fraction of that. The client's decision to skip it was understandable under time pressure. The consequences were entirely predictable. When a client proposes skipping discovery on one part of a product, map out explicitly how that component connects to the rest of the product. The dating app situation became visible only when messaging and onboarding were seen side by side, that connection should be drawn before the decision is made, not after. ## When the Client Already Has the Answer and Hires Research to Confirm It There is a version of discovery that looks right from the outside but produces nothing useful. The client has strong pre-existing views about how the product should work. They commission research. But the research is, in practice, a formality, a box to tick before they proceed with what they had already decided. The findings are reviewed, noted, and set aside. We reached this point with a founder who had deep industry experience and convictions to match. The research process was engaged genuinely on our side. When the findings came back, they showed compelling evidence that a significant portion of the [target user base did not want](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) particular features and actively preferred alternatives. The founder did not move. We walked away from the engagement. The product launched about a year later, largely in line with what the founder had always intended, and by our understanding it did not go anywhere. The research had flagged the same problems that ultimately surfaced in the market. The cost of not acting on it was not the research fee, it was the year of development and the [product's failure to gain traction](https://weareaffective.com/learning-centre/why-does-our-competitor-feel-more-trusted-even-when-our-product-is-better). This pattern is distinct from genuine disagreement about research methodology or findings. It is about [commissioning a process with no real intention](https://weareaffective.com/learning-centre/how-to-run-a-concept-test-that-doesnt-just-confirm-what-the-team-already-believe) of letting it change anything. Discovery only changes outcomes if the organisation is genuinely prepared to act on what it finds. ## What Proper Discovery Actually Changes Discovery is frequently described as a phase that produces certainty, a way of getting everyone aligned before the build begins. That is accurate, but it undersells what discovery actually does. The more useful way to think about it is that discovery surfaces the decisions that would otherwise get made under pressure, mid-build, when changing course is expensive. We worked with a property developer building a concierge app for high-rise residential properties. They arrived with a budget already in mind and a fairly detailed idea of what the product should do. The intention was to replace several existing building systems and add a set of features they believed residents would want. They came to us looking for validation, and we convinced them to undertake a full discovery phase instead, including [focus groups and user workshops](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure). What the process revealed was that the product residents actually wanted was far simpler than what had been planned. A substantial number of the intended features were dropped. The focus shifted to creating a human connection with the product rather than replicating or replacing systems that already functioned. The result was a better product, built faster, at a lower cost than the original plan would have produced. The discovery did not just reduce scope, it redirected the entire product away from a set of assumptions that the target users did not share. - Features planned for inclusion: high complexity, high cost - Features users actually wanted: simpler, relational, lower cost - Outcome: a [product that fit the user](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you), not the founder's intuition ## How Product Leads Can Close the Gap Before It Becomes a Crisis The executive misunderstanding problem is not something product leads can solve by producing better project plans. A Gantt chart does not communicate complexity to someone who is not already familiar with what the tasks on it mean. The gap needs to be closed through conversation, and the conversation needs to happen before the budget is set, not as a post-approval negotiation. The most effective approach is to translate complexity into consequences rather than process. An executive who does not know what API integration involves can understand what happens when it is underestimated. Walk through a specific example of what a missed decision costs, the £15,000 rewrite on the dating app is exactly the kind of figure that lands in a boardroom, because it is concrete and it is avoidable. Product leads also need to be explicit about [what a budget number actually buys](https://weareaffective.com/app-development-cost) at different levels of scope. A table like this can replace a long conversation: | Budget range | What it typically covers | What it excludes | | --- | --- | --- | | £50k, £80k | Core MVP, one platform, basic integrations | Complex back-end, real-time features, custom APIs | | £100k, £150k | Two platforms, moderate complexity, discovery phase | Significant third-party systems, advanced user roles | | £200k+ | Full product with discovery, iterated releases, QA | Scope that keeps expanding without governance | The table is illustrative, not a quote, but the principle holds. Making the trade-offs visible before approval is the product lead's best protection against a budget that was never realistic. ## The Conversation That Needs to Happen Before the Budget Is Signed The conversation most product teams avoid is the one that challenges the number before it becomes official. Once a budget is signed off, it acquires a kind of institutional weight. Questioning it feels like a failure of planning. The honest version of that conversation, "this number was not built on a defined scope and the real figure is likely different", is much easier to have before approval than after. executives are usually trying to make a decision with the information available, and the information available is almost always incomplete. The product lead's job is to make the incompleteness visible before it gets papered over with a number. The grassroots football club app we worked on is a precise illustration of what happens when that conversation does not take place. The founders kept adding features, combining what should have been several separate products into one, and the scope kept growing. We advised a limited release first, an MVP, testing the market and iterating. The advice was not acted on. The budget kept rising, development eventually had to stop, and more than a year later there was still no publicly visible product, just a series of "coming soon" announcements. The conversation about scope and reality needed to happen much earlier, and it needed to carry more weight than it did. Getting the discovery phase commissioned before the budget is fixed is the most direct way to force that conversation. A discovery phase produces an estimate with real foundations rather than assumptions, and it gives executives the information they need to approve a number that actually reflects the work. ## Conclusion The gap between what executives expect and what app development actually costs is not a mystery. It has a structure, and that structure is predictable. Budgets get set before scope is defined. Discovery gets skipped to save time. Features accumulate because stakeholders who are close to the product cannot see why anything should be left out. And the warnings that get raised early, about budget, about complexity, about the risk of never launching, get noted and then ignored until the money runs out. The Standish Group's CHAOS Report found that 31.1% of software projects are cancelled before completion, and that more than half run significantly over budget. These are not random failures. They follow from specific, identifiable decisions made before the build starts. The sports club app we worked on, the grassroots football product, the dating app messaging rewrite, all of them trace back to a decision that seemed reasonable at the time and turned out to be expensive. The fix is an earlier, more honest conversation about what the budget is actually built on, and what discovery would reveal if it were given the space to do so. That conversation is uncomfortable to initiate. It is considerably less uncomfortable than explaining to a board why the product never launched. If your organisation is about to commission an app and the scope is still being defined, [let's talk about your product before the budget gets locked](https://weareaffective.com/get-started). ## Frequently Asked Questions Why do executives so often underestimate how long an app takes to build? Executives frequently arrive at project discussions with a budget figure already in mind, one drawn from competitor products, industry conversations, or informal estimates, rather than any defined scope. Because app development relies on assumptions rather than measurable physical constraints, those early figures rarely survive contact with the actual work. What is discovery, and why does it matter before any budget is agreed? Discovery is a structured process that interrogates the assumptions behind a product idea before any code is written. It exists to surface what the product actually needs to do, which is often quite different from what stakeholders initially describe, and it prevents teams from building the wrong thing with the right budget. How do budget estimates lose accuracy before they even reach approval? A product or technology team is typically asked to produce an estimate with very little information, and that figure then travels upward through the organisation, shedding its caveats at each stage. By the time the number reaches an approval meeting, it reads as a commitment rather than a rough guess built on incomplete knowledge. Is this problem unique to large organisations, or does it affect smaller teams too? The structural gap between executive expectations and delivery reality exists across organisations of most sizes, because the underlying cause is the approval process itself rather than company scale. Smaller teams may have fewer layers of sign-off, but the same dynamic of fixing a budget before defining the scope can still occur. What can product leads do to close the gap before a budget is locked? The most practical step is to ensure a proper scoping or discovery conversation happens before any number is formally agreed, giving stakeholders a realistic picture of what their budget can and cannot deliver. Framing that conversation around risk and business outcomes, rather than technical detail, tends to land better with executive audiences. Why is building an app different from commissioning a piece of marketing or design work? Marketing briefs can be acted on relatively quickly because the variables are well understood and the deliverables are defined early. An app build involves ongoing decisions about functionality, user behaviour, technical architecture, and integration, many of which only become clear once the work is under way. What does a real-world example of this problem actually look like? One example described in the article involved a sports club app where the entire budget was spent without anything being published to the app store. The project reached that point because scope and assumptions were never properly defined before the budget was signed off, leaving the team building against a moving target throughout. Can this problem be solved, and what does that realistically require? The article is clear that the problem is solvable, but only if the right conversation happens early enough, before budgets are fixed and expectations have hardened. That requires product leads to push for structured discovery as a prerequisite to approval, rather than treating it as something that happens after the money is already committed. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.