How long should my app pre launch phase actually be?

The question comes up on almost every project we work on, usually around the time a founder realises that "we're nearly ready" has been the answer for several weeks running. Pre-launch phases have a strange quality: they expand to fill whatever time is available, and the teams inside them rarely notice it happening until a lot of budget has gone. So the honest answer to how long a pre-launch phase should be is that it depends almost entirely on decisions that should have been made before the phase began.

A pre-launch phase is a diagnostic of the decisions made before development ever got started.

What we have found, across projects in fitness, football, social, and gaming, is that the length of a pre-launch phase is less a reflection of a product's complexity and more a reflection of how clearly the brief was defined at the start. Products that launched in reasonable timeframes had clear value propositions, tested onboarding, and founders who were willing to take an MVP to market and iterate. Products that ballooned past their original timelines usually had one of three problems: scope that was never properly bounded, a founder whose conviction outweighed the evidence coming back from users, or a launch date announced publicly before anyone knew if the product was ready. Often all three.

This piece walks through the specific patterns we have seen, what they cost, and what a genuinely ready-to-launch product looks like from the inside.

What a pre-launch phase actually contains

A pre-launch phase is not simply the period between a build finishing and an app going live. It contains several distinct workstreams that run concurrently, and the common mistake is treating them as sequential. App Store copy, screenshots, and product framing are not things you write in the final week. Onboarding testing with real users is not something you squeeze in after the developers have finished. Safety features, if the product requires them, cannot be added on at the end.

The core things that need to be in place before any product goes live are: a validated user need beyond the founder's own experience, an onboarding flow that real users have moved through without confusion, a value proposition that is clear within the first 60 seconds of use, and a path to completing a first meaningful action inside the product without friction. Those are the non-negotiables. Everything else, the App Store listing, the screenshots, the social proof on the product page, sits in a secondary tier but still needs time and attention.

Treat App Store copy as a design workstream, not a writing task. It needs to communicate everything a user needs to know before they even open the product, and it should be drafted in parallel with the build, not after it.

The trap is believing that pre-launch work begins when the development work ends. In practice, by the time a build is complete, pre-launch work should already be well advanced. Teams that start it late are the ones who announce a launch date and then quietly push it by three weeks.

Why six weeks feels like six months

Pre-launch phases stretch because decisions that feel small accumulate. A round of amends to the onboarding flow, a change to how the value proposition is framed, a request to rethink one screen before submitting to the App Store, each one feels reasonable in isolation. Together they add up to weeks, and by the time anyone notices, the original timeline is a memory.

The deeper cause is usually that the product brief was never properly closed. When a founder can still change their mind about what the product is trying to do, the pre-launch phase becomes a secondary design phase with no agreed endpoint. We have seen this on a bootstrapped social football platform where design was driven by one of the client's own team members, without any consideration for the development impact of each change. The scope kept shifting, the budget tightened, and midway through we made the decision to pause Android development entirely and reallocate everything remaining to the iOS product. The client launched iOS only, reaching roughly half the audience they had originally planned for.

The other reason timelines stretch is that teams underestimate how long App Store review and testing infrastructure take to set up properly. These are structured processes that need to be planned, and when they are left to the end, they always take longer than expected.

The decisions that should have been made before development started

A long pre-launch phase is almost always evidence of decisions that were deferred from the discovery stage. By the time a product is in build, the cost of changing something has risen considerably. By the time it is in pre-launch, changing anything structural is expensive both in budget and in time. According to Nielsen Norman Group, investing more time in discovery reduces the risk of project failure by 75%. The pre-launch phase is not where you discover what the product is. That work needs to happen before a single line of code is written.

The decisions that most frequently arrive late, and most frequently cause pre-launch delays, are these:

Decisions deferred from discovery do not disappear, they resurface in pre-launch where they are far more expensive to resolve.

• Which platform or platforms to launch on first
• What the MVP feature set actually is, and what is deferred to a future release
• How the product handles users who do not complete onboarding
• What the App Store listing needs to communicate before a user opens the product
• Whether the product requires any safety, compliance, or moderation infrastructure

The anonymous messaging product we built is a clear example of how one undecided question can reshape the entire pre-launch workload. Because the product required upfront registration before any value was visible, we had to invest heavily in out-of-app content, specifically the App Store listing, the screenshots, and all the surrounding copy, to communicate everything about the product before a user even opened it. Messaging that would normally unfold gradually through use had to be front-loaded entirely into the App Store presence instead. That changed the scope and the timeline of the pre-launch phase considerably, and it was a consequence of a product decision made much earlier.

Scope creep is a pre-launch problem disguised as a development problem

Scope creep tends to be discussed as something that happens during development, but its roots are almost always in decisions that were not properly made before development began. By the time a pre-launch phase arrives, scope creep has usually already done its damage. The product is larger than it should be, the budget is thinner than expected, and the team is trying to get an over-built product across the line rather than a focused one to market.

We worked on a well-funded sports club app designed to manage finances, games, schedules, and players across multiple sports. From the outset, the client rejected any form of incremental release. Despite our advice to launch with a single sport, a single platform, and an MVP, they insisted on launching everything at once and refused to go to market until the full product was complete. What should have reached market in three to four months never launched after twelve to fourteen months of development, and the budget almost doubled over the course of the project. Every one of those outcomes was forecast early on.

A grassroots football club app followed a similar pattern. The client wanted to combine several different apps into one product rather than release a focused feature set and grow from there. The scope kept expanding, the budget kept rising, and the product never reached market because it became unnecessarily complex. We tried to get the client to focus on releasing a small set of features first, test the market, and build from what they learned. The warning signs were visible early, but the advice was not acted on.

If a client cannot describe the MVP in a single sentence, the scope has not been defined yet. That conversation needs to happen before development begins, not during it.

When founder conviction overrides user evidence

One of the most consistent patterns we have seen across projects is the tension between what a founder believes the product should be and what user research actually shows. When that tension is resolved in favour of the founder's instinct rather than the evidence, the pre-launch phase becomes a vehicle for building a product the founder wants rather than one users need. We describe this as a vanity product: shaped by the founder's preferences, insulated from feedback, and rarely ready for market in the way the founder imagines.

We identified this pattern across two specific projects: a fitness and wellness app and a grassroots football product. In both cases, founders with strong personal conviction in their vision ignored data coming back from research, focus groups, and surveys. Early warning signs were the same in both: an excessive drive to perfect the product before any external user would see it, rolling back sign-offs to request further changes, and prolonged decision cycles that had no clear resolution. We flagged the trajectory early on both projects. Both exhausted their budgets in design and build without reaching a fully live product.

The pre-launch phase in both cases expanded because the finish line kept moving. Every time a decision was made, it was unmade a week later in favour of something closer to the founder's original vision. Real user feedback was available but not acted on. The product was being built for one person's idea of the user, not for users themselves.

When sign-offs are being rolled back repeatedly or decisions are taking significantly longer than the project plan allows, treat it as a signal about the brief rather than the design. The issue is usually upstream of what is visible on screen.

Why announcing a launch date too early costs you twice

Announcing a launch date publicly before a product is confirmed ready creates two separate problems. The first is reputational: every time the date shifts, audience trust erodes a little. The second is financial: the marketing spend used to build anticipation around a date that is then revised is gone, and rebuilding that momentum costs more than the original campaign did.

We advised against this on two separate projects, a gaming app for art enthusiasts and a grassroots football product. Both clients chose not to follow the advice. Each picked an arbitrary date, began drip-feeding social posts with that date attached, and then encountered development changes that pushed the launch past the announced date. Both were then in the position of having to update their audience publicly on a schedule they had already committed to. The posts teasing the product were fine. The specific dates on those posts were the problem.

The approach we advise is to build social anticipation without fixing a public date until the product is confirmed ready. Language can be narrowed progressively as confidence grows: "coming soon" becomes "coming this year" becomes a specific month once the team is certain. That progression costs nothing and leaves room for the product to be ready before the audience expects it, which is a far better position than the reverse.

App Store readiness is not a final step

App Store submission is treated on most projects as the last thing that happens before launch. In practice, it is a process with its own requirements, review timelines, and dependencies, and treating it as a final-step formality is a reliable way to add two to three unplanned weeks to a pre-launch phase.

App Store copy and screenshots need to communicate everything a user needs to know about a product before they open it. For most products, some of that communication would normally happen through the onboarding experience itself. When a product requires significant upfront commitment before any value is visible, the App Store listing has to do more work than usual. On the anonymous messaging product, we had to invest substantially in out-of-app content because the product's design meant we could not drip-feed value during the first session. Everything that would normally unfold through use had to be in the listing before the user even downloaded the app.

TestFlight and internal testing groups also need to be structured and managed properly throughout development, not assembled in the final week. On the social football product, we set up three internal testing groups on App Store Connect: one for our team, one for the client, and one external QA beta group for the client's testers. The structure worked well until the client began bypassing it by manually sending builds to whichever group they chose. Because the account was registered in their name and we had admin rather than owner access, we had limited ability to prevent it, and it caused disruption to the testing process in the final stages of the project.

How to know when you are genuinely ready to launch

The honest answer is that no product is ever perfect, and waiting for perfection is the fastest way to burn through a budget. The question is not whether the product is finished in some absolute sense. The question is whether it can deliver a clear, complete first experience to a real user without confusion or friction.

The checks we work through before recommending a launch fall into two tiers. The first tier covers the things that cannot be deferred:

1. User need has been validated beyond the founder's own experience, through surveys, focus groups, or equivalent research
2. The onboarding flow has been tested with real users and any points of confusion have been addressed
3. The core value proposition is clear within the first 60 seconds of use
4. A new user can complete a first meaningful action inside the product without hitting friction
5. The product does not overwhelm a new user in the first session

The second tier covers App Store readiness: copy, screenshots, and product framing that communicate the product accurately to someone who has not yet downloaded it. These matter a great deal, but they can be refined after launch in a way that the core experience cannot.

When all five first-tier conditions are met and the App Store listing is honest and clear, the product is ready. Not finished. Ready. The difference matters because a product that is live and learning from real users is in a fundamentally better position than one still being refined in isolation.

Conclusion

A pre-launch phase has a natural length, determined by what still needs to be resolved before real users arrive. When that length keeps extending, it is almost always because something upstream was not properly decided: the scope, the MVP, the platform strategy, or the founder's relationship with the evidence coming back from users.

The projects we have described here, the sports club app that never launched after fourteen months, the football product that grew too complex to ship, the social platform that lost half its audience by pausing Android, the two products whose founders built for their own vision rather than their users', all of them had one thing in common. The decisions that determined their fate were made, or not made, before the pre-launch phase began. By the time a product is in pre-launch, the expensive mistakes have usually already happened.

What we can say with confidence is that launching a focused product that works, and then iterating from real user feedback, produces better outcomes than extending a pre-launch phase in pursuit of a version that may never arrive. A product that is live and imperfect is learning. A product still in pre-launch is spending.

If your pre-launch phase is running longer than expected and you want to understand why, let's talk about your product and where it is getting stuck.

Frequently Asked Questions