The app goes live and something odd happens. The founder, who has been running at full speed for months, suddenly has nothing urgent to do, and the thing they have been imagining for a year is now a real object in the world that strangers can ignore. I have watched enough launches now to know that the post-launch month is the hardest stretch of the whole project, and it is the only part nobody plans for. There is a project plan for the build. There is a checklist for the store submission. There is almost never a plan for the four weeks that follow, which is where the product either finds its footing or quietly stalls.
Week one: the silence
The first thing founders are unprepared for is how quiet it is. You press publish and the world does not react. A handful of people you know download it, a couple of friends send a nice message, and then the graph flattens into a line that looks like nothing is happening, because nothing is.
This is normal, and knowing it is normal is most of the battle. An app launch is not an event that generates attention, it is a state change that makes attention possible. Nothing arrives on its own. The founders who cope well in week one are the ones who treated the launch as a starting gun rather than a finish line, which is the second of the three product decisions that derail every launch. They have somewhere to point people on day two, and day five, and day twelve. The ones who struggle spent every hour on the build and kept nothing back for the part where you actually go and find humans.
The other thing week one does is expose the difference between people who said they wanted this and people who will use it. Those are different populations. It stings, and it is the single most useful piece of information you will get all month.
Week two: the bugs you could not have found
Around the second week the real bugs arrive, and they are never the ones you tested for. Someone opens the app on a phone three OS versions behind. Someone types an apostrophe into a field that was never asked to hold one. Someone leaves the app backgrounded for two days and comes back to a session that expired in a way nobody designed. Real users do things no test plan contains, because real users are not trying to break it, they are just living.
What surprises founders here is not the existence of bugs but the emotional weight of them. A crash report from a stranger reads very differently to a failing test. There is an instinct to treat every one as an emergency, and that instinct will burn out a small team in a fortnight. The useful discipline is triage: does this stop someone using the product, or is it ugly but survivable? Fix the first category the same day, batch the second, and resist the urge to also ship three improvements while you are in there.
Plan for this before you launch by holding back capacity deliberately. If your developer is fully booked on new features from the day after release, you have no room for the only work that is guaranteed to exist.
Week three: the feedback that contradicts itself
By week three there are enough real users to have opinions, and the opinions disagree. One person wants it simpler. One wants the feature you cut. One has a workflow you have never seen and is annoyed the app does not support it. A founder reading this in one sitting will come away convinced the product is both too complicated and not complete enough, which is an unpleasant place to sit.
The mistake is treating feedback as a vote to be counted. It is not. It is evidence about a specific person doing a specific job, and it is only useful when you know which person you were building for. This is where the founders who narrowed early get their reward: they can sort feedback into “my person struggled” and “somebody else’s person wanted something else”, and they act only on the first. The founders who built for everyone have no way to sort anything, so every request feels equally valid, and the roadmap becomes a queue of other people’s ideas.
The other trap in week three is acting too fast. A single articulate user can move a roadmap more than they should, simply because they wrote a long and persuasive message. Wait for the pattern. Two people saying the same thing badly is worth more than one person saying something beautifully.
Week four: the decision nobody schedules
The fourth week is where the month actually resolves, and it usually arrives without anyone putting it in a calendar. You now have real numbers on whether people come back, real evidence about which part of the product does the work, and a list of things you could build next. The decision is what to do with all of it, and it tends to get made in a tired, reactive way because nobody planned a moment to make it properly.
Book that moment in advance. Put a date four or five weeks after launch in the diary, before you launch, and treat it as a formal review. Look at whether anyone came back, not how many signed up. Look at which single part of the product people actually used. Decide one thing to change and one thing to stop doing. That is it. A short, deliberate review beats a month of continuous anxious tinkering, and it also gives the team a finish line for the scramble, which matters more than founders expect.
What to have in place before the post-launch month starts
Four things, all cheap, all easier to arrange before launch than during it.
Have somewhere to send people on day two. Not a campaign, just a plan for who you will contact and where those first conversations will happen. Have analytics working before release rather than after, so week four has something to look at. Have a bug triage rule agreed with whoever is fixing things, so you are not making the judgement call at 11pm. And have a review date in the diary.
None of this is technical, which is exactly why it gets left out of project plans. It is also the difference between a post-launch month that produces a decision and one that produces exhaustion. If you are still upstream of all this and shaping the release itself, our guide to preparing a UK app for App Store review covers the mechanics, and if pricing is one of the things you plan to test in the first month, how to price your app subscription for UK users is the place to start.
What to do next
The post-launch month is quiet, then noisy, then contradictory, then decisive, and it goes far better when you have seen the shape of it in advance. Keep engineering capacity back, expect the silence, sort feedback by who it came from rather than how loudly it was said, and put the review date in the diary before you press publish.
If you are approaching a launch and want a second pair of eyes on the plan for the month after it, send us a project brief. It is a cheaper conversation to have now than in week three.
.webp)
.webp)
