--- title: "What Scope Creep Actually Costs: A Sports Club App That Spent Twelve Months Growing and Never Launched" description: Scope creep killed a sports club app before it ever launched. See the warning signs, budget impact, and how iterative releases help. image: https://weareaffective.com/hubfs/learning-centre-images/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growing-and-never-launched.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi#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 # What Scope Creep Actually Costs: A Sports Club App That Spent Twelve Months Growing and Never Launched Table of Contents The sports club app should have launched in four months. It had a clear purpose, a funded team, and a development process that had worked on comparable products before. Twelve months later, the budget was gone, nothing had reached the app store, and the agency relationship had ended. The product that never launched was not the result of bad design or poor engineering. It was the result of a client who refused, at every stage, to release anything less than everything. > The refinement sessions that were supposed to narrow the product down became expansion sessions dressed up as progress. Scope creep is often described as a gradual drift, a slow accumulation of small changes that quietly doubles the work. This project was different. The expansion was active, consistent, and driven by two co-founders who were so close to the product that every refinement session became an opportunity to add rather than reduce. The team saw it coming. They flagged it, documented it, and advised against it repeatedly. None of it changed the outcome. What follows is an account of how that happened, what it cost, and what the warning signs looked like from the inside. The story matters because the pattern is not unusual, and the cost is far higher than most clients expect before they are living it. ## The Project That Should Have Launched in Four Months The brief was genuinely well-scoped at the start. The product was a sports club management app designed to handle finances, games, schedules, and player management across a range of sports. The client was well-funded, the market need was real, and the team's recommendation was clear: launch with a single sport, on a single platform, with a focused MVP. Get something to market, gather [real user behaviour, and build from there](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one). The client pushed back on all of it. They did not want to launch with a single sport. They did not want to start on one platform. They did not want an MVP. As Simon put it directly: "They wanted everything." The team's advice, which was grounded in what they had seen across comparable builds, was set aside in favour of a launch-everything position that the founders held from the very first brief. Three to four months was a realistic timeline for the scoped MVP. What followed was twelve to fourteen months of development, an almost doubled budget, and a product that never reached the app store. The gap between those two outcomes is entirely explained by what happened between sessions, not by any technical failure or resource problem. The project had the ingredients to succeed. The decision-making structure around it did not. ## Why the Client Rejected an Incremental Release Understanding why the client said no to an incremental release matters, because the reasons were not unreasonable on the surface. Both co-founders worked and lived inside the environment the app was designed for. They knew grassroots sports club management from direct experience, and that knowledge made them confident in their view of what the product needed to be. Launching a partial product felt, to them, like launching a broken one. That instinct is understandable. It is also, in practice, the thing that kills more app projects than poor engineering does. Because [the product was the business, not a marketing asset](https://weareaffective.com/learning-centre/how-to-spot-a-product-vision-that-wont-survive-first-contact-with-users) sitting alongside an existing revenue stream, the founders were emotionally and professionally tied to getting it right before releasing anything. The idea of a user downloading version one and finding it limited felt worse than delaying the launch. What that position does not account for is the cost of never launching at all. A limited product in market generates feedback, [user data, and early revenue](https://weareaffective.com/learning-centre/how-do-i-use-data-to-predict-which-users-will-stop-using-my-app). A complete product that never ships generates none of those things, regardless of how thoroughly it was designed. The team made this argument clearly and more than once. The client's response, each time, was to keep building rather than to ship what they had. ## Design built to *grow* your product We give your app the strategic and design foundations it needs to launch well and keep growing. Research, UX/UI design and technical specs ready for your development team. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## How Refinement Sessions Became Expansion Sessions Refinement sessions exist to reduce. You take a feature, look at what it actually needs to do for the user, strip out what is unnecessary, and leave a cleaner, more buildable version of the requirement. That is the function. On this project, every refinement session produced the opposite result. The pattern was consistent. The team would open a session to narrow a feature down, and one or both founders would introduce requirements that had never been mentioned before. Each addition was framed as obvious: "of course it needs to do this" or "of course it needs to do that." Because both founders held that view confidently, and because neither was willing to defer, the new requirements went into the spec. As Simon described it: "We ended up with a bigger product at the end, which is the complete opposite of what you should have." > The team would start a session to narrow a feature down, and leave with a spec that was larger than before. This is not a failure of process in isolation. The refinement process worked as designed. The problem was that the stakeholders who held decision-making authority were not using those sessions to reduce, because they did not believe reduction was the goal. Both founders were independently and consistently pushing to add, and the refinement framework had no mechanism to override that if the client simply refused to accept it. The process expanded because the people running it wanted a bigger product, and they had the authority to get one. Before each refinement session, agree in writing on the exit criteria: what is the session for, and what does a successful outcome look like? If both stakeholders cannot state the goal as "remove or simplify", the session will expand the product rather than focus it. ## The Specific Moments the Team Flagged Risk The warnings were not vague or general. They were specific, documented, and delivered more than once. The team told the client directly that the [budget would spiral out of control](https://weareaffective.com/app-development-cost) and that they risked exhausting their funding before anything reached the app store. This was not a late-stage concern raised once the damage was done. It was raised early, while there was still time to change course. The client acknowledged the warnings and continued adding features anyway. That is the part that is hardest to understand from the outside, but it follows a logic that is common in founder-led projects: the founders believed their product knowledge outweighed the team's process knowledge. They were right about the domain. They were wrong about the consequence. There is a broader pattern here that the data reflects. According to [The Standish Group's CHAOS Report](https://www.projectsmart.co.uk/white-papers/chaos-report.pdf), 31.1% of software projects are cancelled before they are completed. This project was not cancelled mid-flight. It ran to the end of its budget, with the full team engaged throughout, and produced nothing publishable. That is a different kind of failure, and in some ways a more expensive one, because the cost was total before the outcome was known. ## What the Budget Trajectory Actually Looked Like The budget nearly doubled over the course of the project. That figure is what happened, and it is what the team had forecast it would be if the client continued adding scope. The original budget was sized for a focused MVP across one sport and one platform. The final spend reflected a product that tried to cover multiple sports, multiple platform considerations, and a feature set that had expanded through every refinement session. | Stage | Scope | Budget Position | Outcome | | --- | --- | --- | --- | | Original brief | Single sport, single platform, MVP | Agreed and funded | Rejected by client | | Mid-project | Multiple sports, expanded features | Rising, warnings issued | Client continued adding | | End of project | Full multi-sport product | Nearly doubled | Nothing on the app store | This trajectory is broadly consistent with what [McKinsey research](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value) describes across large-scale IT projects: 45% run over budget on average, delivering 56% less value than predicted. The sports club app exceeded that average considerably, and delivered no value at all, because there was no product to deliver value from. Track the cumulative scope change as a percentage of original specification after every session, not just the budget spend. A product that is 40% larger than the original spec after six weeks of refinement is a budget overrun that has not yet shown up in the invoices. ## When the Funding Ran Out Before the App Store Did The project ended with the entire budget spent and no submission to the app store. The client and the agency parted ways at that point. Simon's description of the outcome is precise: "We got to the end of the project, they'd burnt through the entire budget adding feature after feature after feature and never actually getting anything on the store." What makes this outcome particularly costly is that the money spent was not wasted on bad work. The design was grounded, the engineering was sound, and the team had followed the brief they were given. The product simply could not be completed within any reasonable extension of the budget because it had grown to a size that the original funding was never designed to support. The founders had built something they could not afford to finish. The grassroots football product followed the same arc. The founders built what they believed the product should be rather than what the market was indicating, and the team's advice against overcomplicating the feature set was not taken on board. Development stopped, the team ceased working with them, and more than a year later the product still had no marketable release, only repeated announcements of "coming soon." Two separate projects, the same mechanism, the same result. Set a hard budget gate at the halfway point of any project. If scope has increased by more than 20% of the original specification, stop and reforecast the full project cost before continuing. The point is to surface the real cost while there is still a decision to make. ## The Warning Signs You Can Spot in Your Own Project The signs that a project is moving in this direction are visible before the budget becomes critical. The problem is that each individual sign feels manageable in isolation, so the cumulative picture only becomes clear when it is already expensive to change. 1. Refinement sessions consistently produce longer specifications than they started with. 2. Stakeholders describe new requirements as obvious or already implied, rather than as additions. 3. The team's process advice is acknowledged and then set aside in favour of the client's product instincts. 4. Incremental release is rejected on the grounds that anything partial is not good enough to ship. 5. Budget warnings are noted but do not produce a change in the decision being made. The sports club app had all five of these signs active from early in the project. The fitness and wellness product we worked on with two co-founders who were new to app development showed a related pattern: design sign-off was given and then walked back repeatedly, with approvals given to avoid conflict rather than as genuine decisions. That project never moved beyond the design and research stage, because the budget ran out before a single line of production code was written. The common thread across these projects is a decision-making structure that cannot say no to its own ideas, and a relationship with the development process that treats professional advice as optional rather than consequential. ## What an Iterative Release Would Have Cost Instead The alternative was available from the start. A single sport, a single platform, a focused set of core features: club finances, basic scheduling, and player management. That product could have reached the app store in three to four months. Real users would have been using it while the second and third phases were being designed, and the [feature decisions for those phases would have been informed by actual behaviour](https://weareaffective.com/learning-centre/why-your-best-users-are-often-your-worst-source-of-product-direction) rather than founder assumptions. The cost of that approach, at the original scoped budget, would have been a fraction of what the project ultimately spent. More importantly, it would have produced something: a live product, an early user base, and evidence about [what the market actually wanted from the app](https://weareaffective.com/learning-centre/what-does-good-ux-research-actually-look-like-at-seed-stage). Each subsequent phase would have been built on data rather than belief. The [football-focused social media app](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) we worked on separately reached a completed product, but only with feature compromises, because the client's budget and their expectation of what the budget would deliver were misaligned from the outset. That project at least got to market. The sports club app did not, because the client rejected the one approach that would have given them a product within their funding window. A phased release also changes the risk profile of the project entirely. A product that ships at month four and iterates is a product that can be funded from early revenue, or at minimum from evidence of user engagement. A product that ships at month fourteen, if it ships at all, has consumed its entire budget before it generates a single pound of return. ## Conclusion The sports club app is a story about what happens when the person with decision-making authority is too close to the product to hear professional advice, and too committed to a complete vision to accept a partial one. Both conditions are understandable. Together, they are expensive. The team did everything that could reasonably be asked of them. They recommended an MVP, flagged the budget risk early, documented the warnings, and continued to deliver good work throughout. What they could not do was override a client who held the authority to make the decisions and used it consistently to expand the scope. That is a structural problem, and it requires a structural answer: clearer scope gates, harder escalation points, and a shared understanding from the first session that refinement means reduction. The Standish Group's CHAOS Report puts the proportion of software projects that are cancelled before completion at 31.1%. The sports club app was not cancelled; it ran to zero. That distinction matters because it represents a different kind of decision at every stage: to keep going, keep adding, and keep believing that completion was just a few features away. If you are in a project that is showing these signs, the cost of addressing them now is always lower than the cost of addressing them when the budget is gone. [Let's talk about where your project stands.](https://weareaffective.com/get-started) ## Frequently Asked Questions What is scope creep and why is it so damaging to app projects? Scope creep is the gradual or active expansion of a project beyond its original brief, often driven by adding features or requirements during development. It is particularly damaging because it inflates budgets, extends timelines, and can ultimately prevent a product from launching at all, as this case demonstrates. Why did the team recommend launching with a single sport on a single platform? The team's recommendation was grounded in experience from comparable builds, where a focused MVP allows real user behaviour to inform future development. Launching with a narrower scope reduces risk, shortens time to market, and means decisions about what to build next are guided by actual data rather than assumptions. Is it not reasonable for a client to want a complete product before launching? The instinct to avoid releasing something that feels partial is understandable, particularly when the product is the business itself rather than a supporting marketing tool. However, waiting for completeness before launching is one of the most common reasons app projects fail, because the definition of complete tends to keep expanding. What were the warning signs that this project was heading off track? The development team flagged the problem repeatedly, documented their concerns, and advised against the expanding scope at multiple stages. A key indicator was that refinement sessions, which should have narrowed the product down, were consistently being used as opportunities to add new features rather than reduce complexity. What did scope creep actually cost this client in practical terms? The project ran for twelve to fourteen months instead of the planned three to four, and the budget nearly doubled. The product never reached the app store, the agency relationship ended, and the client had nothing to show for the investment. How can a development team protect a project from this kind of scope creep? Teams can flag concerns, document recommendations, and advise against expansion at every stage, as this team did. However, when the decision-making authority rests entirely with a client who consistently overrides that advice, documentation alone is not sufficient to change the outcome. Could better communication between the client and the agency have prevented this outcome? The article makes clear that communication was not the problem. The team repeatedly raised concerns through proper channels and the client understood the implications. The issue was a fundamental disagreement about product strategy that no amount of communication could resolve when one party held all the decision-making power. Is this kind of outcome unusual, or do many projects end this way? According to the article, the pattern is not unusual at all. Projects stall or collapse for this reason more often than clients expect, particularly when founders are deeply close to the product and equate launching a focused version with launching an inferior one. ## Related Articles [![Can I Build My App in Stages to Spread Out Costs?](https://weareaffective.com/hubfs/learning-centre-images/can-i-build-my-app-in-stages-to-spread-out-costs.webp)](https://weareaffective.com/learning-centre/can-i-build-my-app-in-stages-to-spread-out-costs) ### [Can I Build My App in Stages to Spread Out Costs?](https://weareaffective.com/learning-centre/can-i-build-my-app-in-stages-to-spread-out-costs) Spreading a build across several phases sounds like good financial planning. You pay for what you... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How to Spot a Product Vision That Won't Survive First Contact With Users](https://weareaffective.com/hubfs/learning-centre-images/how-to-spot-a-product-vision-that-wont-survive-first-contact-with-users.webp)](https://weareaffective.com/learning-centre/how-to-spot-a-product-vision-that-wont-survive-first-contact-with-users) ### [How to Spot a Product Vision That Won't Survive First Contact With Users](https://weareaffective.com/learning-centre/how-to-spot-a-product-vision-that-wont-survive-first-contact-with-users) Product vision statements get written in conference rooms, on whiteboards, and in the notes apps of... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What a Pre-Build Strategy Sprint Actually Costs, and What It Saves](https://weareaffective.com/hubfs/learning-centre-images/what-a-pre-build-strategy-sprint-actually-costs-and-what-it-saves.webp)](https://weareaffective.com/learning-centre/what-a-pre-build-strategy-sprint-actually-costs-and-what-it-saves) ### [What a Pre-Build Strategy Sprint Actually Costs, and What It Saves](https://weareaffective.com/learning-centre/what-a-pre-build-strategy-sprint-actually-costs-and-what-it-saves) Most businesses approach digital product development backwards. They dive straight into wireframes... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![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.