In the first 90 days after launching an MVP, do five things in order: make the product stable and measure one core metric, talk to users every week, sort feedback into fix, iterate and ignore, review the evidence at around day 75 and decide whether to continue, narrow or pivot, and set a budget and a team arrangement for the next stage. Resist the two common reflexes, which are adding features immediately and planning a rewrite.
The 90-day plan at a glance
| Period | Focus | What you should have at the end |
|---|---|---|
| Days 1–14 | Stabilize and instrument | Launch bugs fixed, error tracking on, the core metric and funnel measured, a feedback channel open |
| Days 15–45 | Learn | Ten or more user conversations, first retention picture, friction in the first-run experience removed |
| Days 46–75 | Iterate | Two or three deliberate changes shipped, each with an expected effect on the core metric that you checked afterwards |
| Days 76–90 | Decide | A written decision: continue, narrow, pivot or stop. A budget and team plan for the next two quarters |
The schedule assumes that users are arriving. If they are not, the first task is distribution, not product. An MVP with no users produces no evidence, however good the analytics.
Instrument one core metric
Pick the single number that shows users are getting the value the product exists to deliver. Sign-ups, downloads and page views do not qualify. They measure interest in the promise, not delivery of it.
| Product type | Candidate core metric |
|---|---|
| B2B workflow tool | Accounts completing the core workflow at least once a week |
| Marketplace | Completed transactions per week, and the share of buyers who transact again |
| Consumer app | Users who return and perform the core action in week two and week four |
| Content or data product | Users who view the content on three or more separate days in a month |
| Subscription product | Trial-to-paid conversion, then retention after the first renewal |
Around that metric, measure the path to it: visit, sign-up, first core action (activation), repeat core action (retention), payment. Five or six tracked events are enough. The aim is to see where people drop out, not to fill a dashboard.
Practical setup for the first two weeks:
- Product analytics with the funnel events defined and tested
- Error and crash tracking with alerts to someone who will act
- Uptime monitoring and working backups
- A feedback channel users can find in one tap: email, in-app form or chat
- A weekly cohort view: of the users who joined in a given week, how many were active one, two and four weeks later
- A privacy policy that reflects what you now collect, and consent where your users' jurisdictions require it
With small numbers, read cohorts as individual stories. If eleven people signed up in week one and two are still active, find out who those two are and what they have in common. That is more useful than the 18% figure.
Talk to users every week
Analytics tell you what happened. Only people can tell you why. Aim for three to five conversations a week during the first two months, across three groups:
- Retained users. What were they doing before? What would they use if the product disappeared? Their answers define your real value proposition, which is often not the one on your home page.
- Users who signed up and left. What did they expect, and what did they find? These are the hardest to reach and the most informative. A short personal email from the founder gets more replies than a survey.
- Users who never completed the first core action. Where did they stop? If possible, watch a new user go through sign-up on a call without helping.
The same rule applies as in pre-build validation interviews: ask about what they did, not what they would do. Feature requests are data about a problem. Ask what the person was trying to achieve when they wanted the feature, because the problem is often solvable more cheaply than the request.
Triage feedback: fix, iterate, ignore
Within a month you will have more requests than budget. Sort every item into one of three groups, using the same rule each time.
| Group | What belongs here | Action |
|---|---|---|
| Fix | Anything that stops a user completing the core action: crashes, data errors, broken sign-up or payment, security problems, unusable slowness | Now, ahead of everything else |
| Iterate | Friction or gaps on the path to the core metric, reported by several users in your target segment, or visible as a drop-off in the funnel | Rank by expected effect on the core metric against effort. Ship the top two or three per cycle |
| Ignore, for now | Requests from outside your target segment, one-off requests, features for scale you do not have, cosmetic preferences, "a competitor has this" | Log it with the requester's name. Revisit when it recurs |
Four questions settle most items:
- Does it block the core action? If yes, fix.
- Is the person asking in the segment you are building for?
- Have at least three such users raised it independently, or does the funnel data show it?
- If it worked, which number would move, and by roughly how much?
One exception to "several users": in B2B, a single customer who will sign a contract if a specific gap is closed can justify the work. Check that the feature serves other customers too, or you are doing custom development for one client at product prices.
Write down the expected effect of each change before building it, then check after release. Teams that skip this step ship steadily and learn nothing.
When to pivot, and when to persevere
A weak first month is normal and proves little. A pivot is a change of segment, problem or approach made because evidence points somewhere better. It is not a reaction to a bad week.
| What you see | Likely meaning | Response |
|---|---|---|
| People sign up, few complete the first core action | Onboarding or clarity problem | Persevere. Fix the first-run experience |
| People activate, few return | The value is weak, infrequent or a one-off | Investigate. Interview the ones who did return |
| One sub-group retains well, the rest do not | You have found your segment | Narrow. Rewrite positioning and roadmap around that group |
| Users use a secondary feature more than the core one | The product's value is somewhere you did not expect | Consider re-centering the product on it |
| Strong usage, nobody will pay | Wrong buyer, wrong price model, or a problem not worth money | Test pricing and buyer before changing the product |
| Few sign-ups despite real distribution effort | The promise does not resonate, or the channel is wrong | Test messaging and channels; revisit validation |
| Fair test completed, core metric flat, no retained sub-group | The problem or the solution is wrong | Pivot or stop |
A fair test means: enough users from the right segment, launch bugs fixed, the obvious onboarding friction removed, and six to eight weeks of attention. Decide in advance what result at day 75 would make you change direction, and write it down. It is much harder to be honest about a threshold you set afterwards.
The MVP codebase: refactor or rewrite
MVP code is written for speed of learning, and some of it will show. The question after launch is whether the shortcuts are slowing you down enough to matter. Most of the time the answer is a few weeks of targeted refactoring, not a rebuild.
| Symptom | Usually means | Response |
|---|---|---|
| Changes in one area take longer than they should | Local design debt | Refactor that module when you next work in it |
| Fixes cause new bugs elsewhere | Missing tests, tangled dependencies | Add tests around the core workflow first, then untangle |
| Pages slow down as data grows | Missing indexes, inefficient queries, no caching | Profile and fix. This is rarely architectural |
| Deployments are manual and stressful | No pipeline, no staging environment | Invest a week in CI/CD and staging. It repays itself quickly |
| Outdated dependencies with security warnings | Maintenance has been skipped | Schedule regular updates; see what app maintenance involves and costs |
| The product's central concepts changed after a pivot and the data model no longer fits | Foundation mismatch | Redesign the data model and rebuild the affected parts in stages |
| Built on a platform that cannot do what customers now need, or cannot be exported | Platform ceiling | Planned rebuild, using the current product as the specification |
| No developer can explain the code, no documentation, no tests, original author gone | Unknown risk | Commission an independent code audit before deciding anything |
Rewrites are tempting because new code always looks cleaner than old code. They are also the riskiest move available: months in which no customer-facing improvement ships, while the old system still needs fixes. Rules that keep the decision sober:
- Do not rewrite before you have evidence of demand. Rewriting a product nobody retains is the wrong investment.
- Prefer replacing one part at a time behind the same interface and the same database.
- Reserve a steady share of each cycle for refactoring, in the order of 15–20% of development time as a rule of thumb, so debt is paid continuously and not in a crisis.
- If a new team tells you everything must be rewritten, ask for a written audit with specifics. Our guide to rescuing a struggling software project explains what a proper audit covers.
Budgeting the iteration phase
The most common planning error is spending the whole budget on the build. An MVP without money to act on what it teaches is an expensive survey. The figures below are planning estimates using an illustrative $50,000 MVP built over four months, which is $12,500 a month during the build.
| Line | Planning rule | Illustration |
|---|---|---|
| Maintenance: updates, fixes, monitoring | 15–25% of build cost per year | $7,500–$12,500 a year, about $625–$1,040 a month |
| Iteration: changes driven by evidence | 25–50% of the monthly build pace | $3,125–$6,250 a month, or $9,375–$18,750 over 90 days |
| Infrastructure and services | Usually modest at this scale | Often tens to low hundreds of dollars a month |
| Acquisition and research | Set separately; product spend cannot replace it | Depends on channel |
If the iteration budget in the table includes bug fixing, as most monthly arrangements do, the maintenance line is largely contained within it during this phase and does not need to be added on top.
Structure matters as much as the amount. Fixed-price scopes suit a defined first release. After launch, priorities change every two weeks, so a monthly arrangement with a set capacity and a ranked backlog works better. Agree the capacity, review the backlog at the start of each cycle, and keep the right to scale down with reasonable notice.
If the money is nearly gone at launch, say so early and cut the plan to fit: stability fixes and two or three carefully chosen changes will teach you more than a long list half-finished.
Hire in-house or continue with a studio
There is no universal answer, and a studio's advice on this deserves scrutiny. These are the rules we would apply in your position.
| Situation | Sensible arrangement |
|---|---|
| Demand not yet proven, direction may change | Stay with a studio or freelancers on a monthly arrangement. Hiring employees for a product that may pivot or stop is costly for everyone |
| Workload is uneven: busy cycles, quiet cycles | External team with adjustable capacity |
| Retention is evident, revenue or funding secured, steady full-time work for at least a year ahead | Begin hiring in-house, starting with a senior engineer who can own the codebase |
| Technology is the core of your competitive advantage | Build internal ownership early, even if a studio still does much of the delivery |
| You are non-technical and have nobody to assess candidates | Get help with vetting from the studio or an independent advisor before you hire, and avoid making the first hire a junior |
| You have one or two engineers and need more capacity or a missing skill | Hybrid: internal lead, external team working in your repository and process |
Hiring takes months from job post to a productive engineer, and the product cannot stand still in the meantime. The usual sequence is to continue with the team that built the MVP, hire the first internal engineer alongside them, and hand over gradually. Whichever route you choose, make sure a handover is possible at any moment:
- Source code in a repository your company owns
- Hosting, domains, app store and third-party accounts in your company's name
- Setup and deployment instructions that a new developer can follow
- A short architecture overview and a list of known shortcuts
- Credentials stored in a password manager you control
The full trade-off, including cost comparisons and hybrid models, is in our guide to in-house versus outsourced development. When you do start recruiting, how to hire developers for a startup covers the order of hires and vetting. If you want a team to keep the product moving without hiring yet, BBR's product engineering service is the ongoing arrangement we offer, and we can join or take over an existing codebase. If you have not launched yet, the MVP development page describes how the first release is scoped.
Mistakes that waste the first 90 days
- Celebrating sign-ups while nobody measures whether users return
- Building every request from the loudest user
- Going quiet after launch and waiting for growth to happen
- Starting a rewrite, a redesign or a second platform before retention is visible
- Running experiments on twenty users and trusting the percentages
- Letting the development team idle for lack of decisions, or letting it choose the roadmap for lack of direction
- Reaching day 90 without a written decision about what the evidence says