The first ninety days after launch

Five things arrive in the first ninety days, roughly in this order, and none is on the launch plan. Week one: a support load nobody staffed — every question a real user asks out loud is one your interface failed to answer silently. Weeks two to four: the bugs that only exist with real data, a different species from the ones you found in testing. Weeks three to six: the feature request that is actually a positioning problem, which costs a quarter if you build it. Weeks six to twelve: the first honest load question, which is not whether the product is fast but whether it is fast on the worst phones and the worst networks. And underneath all of it, the question that decides whether you are allowed to relax: is this working, or has nobody stressed it yet? Those are different states, and from the inside they look identical.

Start with why the reassuring evidence is not evidence. Everything you knew on launch day came from people who already knew what they were doing — you, whoever built it, and a few friendly testers on good laptops on good networks. That is lab data, and the distinction is standard enough that the people who publish web performance research state it before quoting their own figures. HTTP Archive's Web Almanac notes in its 2024 performance chapter that its own crawl "contains only lab performance data. In other words, it is data from a single website load event," which is "useful but limited if we want to understand how users experience performance" — so the chapter is built instead on real-user measurements from the Chrome User Experience Report (HTTP Archive, Web Almanac 2024: Performance). The same gap sits between your staging environment and your first customers.

The field numbers are humbling for anyone who assumes competence closes that gap. In the same chapter, 43% of websites had good Core Web Vitals on mobile in 2024 against 54% on desktop, and the breakdown by popularity overturns the comfortable assumption: only 40% of the thousand most popular sites cleared the bar on mobile, and 31% of the top hundred thousand, against 44% of sites ranked beyond ten million. The largest engineering organisations on the web do worse on real phones than the long tail does. The lesson at ninety days is that every quality your product appears to have on your own machine is an untested hypothesis until field data exists.

The support load is the first thing to arrive and the last thing anyone budgeted. It is worth knowing that this is a priced occupation rather than an overhead you absorb: the US Bureau of Labor Statistics reports a 2025 median pay of $62,890 a year for computer support specialists, across 903,100 jobs, with employment projected to decline 3 percent from 2025 to 2035 (US Bureau of Labor Statistics, Computer Support Specialists, Occupational Outlook Handbook, 2025 data). The point is not to hire one in week one. It is that a founder who plans for zero support is planning to do a job with a published national median for free, in the evenings, on top of selling. Do it deliberately for ninety days and then stop, because the first two hundred tickets are the most valuable product research you will ever get and the next two thousand are a staffing decision.

Read the tickets as data, because the ratio between three categories is a diagnosis. I could not find it is an interface problem and the cheapest to fix. It did not do what I expected is a mental-model problem: the product is behaving as designed and the design is wrong, which is the most expensive category to ignore because it never announces itself as a bug. It broke is the only one that is actually engineering. Drowning in the first is a navigation problem worth a week. Drowning in the second is a product problem worth a conversation with every one of those users before a line is changed.

The bugs that only exist with real data come in three shapes, and they arrive at tens of users rather than thousands. The first is the assumption nobody wrote down: a name with an apostrophe, an address with no postal code, a quantity of zero, a currency with no decimal places, an upload the size of a film, a user who registers twice with the same email in different capitalisation. Each is a rule your code enforces implicitly because nobody ever stated it. The second is the simultaneity bug — two requests that each read, compute and write, one of which silently disappears, or a double-tapped submit button that creates two orders. The third is the accumulation bug: the query that was instant on five hundred rows, the list page with no pagination, the nightly job that iterates every user ever created. None is a load problem, which is why a load test misses all three and a hundred real users do not.

What to measure in week one is two numbers, not a dashboard. Google's Site Reliability Engineering book defines the vocabulary precisely enough to borrow: "An SLI is a service level indicator — a carefully defined quantitative measure of some aspect of the level of service that is provided," and an objective is "a target value or range of values for a service level that is measured by an SLI." Its advice on how many to have is the part founders need: "Have as few SLOs as possible", and "if you can't ever win a conversation about priorities by quoting a particular SLO, it's probably not worth having that SLO" (Google, Service Level Objectives, Site Reliability Engineering). For a ninety-day-old product that is the success rate of your one critical path, and its latency at the ninety-fifth percentile rather than its average — the same book notes that "we generally prefer to work with percentiles rather than the mean (arithmetic average) of a set of values," because the long tail is where the users who leave actually live.

Add one product number beside those two: the proportion of new accounts that complete the workflow the product exists for, measured weekly rather than cumulatively. Cumulative numbers only go up, which is why founders quote them and why they say nothing. A weekly completion rate falling from 60% to 40% while signups rise is a product getting worse inside a chart that looks like success.

Week eight is where the trend becomes a target, and where the instinct to chase perfection has to be argued down. The same source is blunt about it: "100% is probably never the right reliability target: not only is it impossible to achieve, it's typically more reliability than a service's users want or notice," and "cost does not increase linearly as reliability increments — an incremental improvement in reliability may cost 100x more than the previous increment" (Google, Embracing Risk, Site Reliability Engineering). The companion chapter warns against the opposite failure under the heading "Don't overachieve": "If your service's actual performance is much better than its stated SLO, users will come to rely on its current performance" (Google, Service Level Objectives). Set a number you can defend, treat the gap between it and perfection as budget, and spend it on shipping.

The feature request that is a positioning problem does the real damage, because it is indistinguishable from demand. Three tests separate them. First, does the request arrive from users who do not resemble each other? Repeated by people with different jobs in different industries, it is a feature. Repeated by one segment, it is information about that segment. Second, would satisfying it make the product worse for the users you meant to serve — more settings, more onboarding, a slower core workflow? Then it is a positioning decision wearing a feature's clothes. Third, ask what they did before they found you: the answer tells you which market you are actually in, and it is not always the one on your website. Which of those you accept is a business judgement, not an engineering one — the subject of what a non-technical founder should own.

Something will break, and the ninety-day version of incident response is smaller than the literature but not different in kind. NIST's current guidance opens by noting how much the ground has moved: incidents used to be rare and "incident response and recovery was usually completed within a day or two," whereas today "incidents occur frequently and cause far more damage. Recovering from them often takes weeks or months due to their breadth, complexity, and dynamic nature." Its most portable recommendation costs nothing to adopt at three people: "The lessons learned during incident response should often be shared as soon as they are identified, not delayed until after recovery concludes" (NIST, SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025). Write the note while the incident is open, with timestamps. Nobody reconstructs it accurately afterwards, and the reconstruction is what stops the second occurrence.

That settles what the operational surface has to include before the ninety days are up, and it is short: the success and failure rate of the critical path, a way to find one specific request from last week, and an alarm that reaches a human before a customer does. It is the control plane any operator needs — a payment orchestration dashboard we built exists for exactly that, putting payment volume, success versus failure rates and full system logs in one place. Your product is smaller and the requirement is identical.

Now the question the whole period is really about: is it working, or has nobody stressed it yet? Four tests distinguish them, and all four can be run in an afternoon. Concentration: what share of all activity comes from your three most engaged accounts? If it is most of it, you have three users and a mailing list. Unprompted return: how many accounts came back in week three without an email, a nudge or a conversation? That number, not signups, is the product. Unintended use: has anyone used it in a way you did not design? Products that genuinely work get bent, and the bending is the roadmap. Absence of failure: if nothing has broken at all in ninety days at low volume, the honest reading is not that the system is robust — it is that nobody has visited hard enough to find out.

What to do on Monday, in order. Pick the one workflow the product exists for and write down its success rate and its ninety-fifth-percentile latency, even if the only way to get them today is counting by hand. Sort every support message from the last fortnight into the three categories above. Take your top three accounts out of the activity numbers and look at what is left. Then take one real complaint and find the exact request behind it — however long that takes is your incident response time, and if it cannot be done at all, structured logging with a request identifier is the highest-value week of engineering available.

Underneath all of this, launch moved the work from building to operating — which is the work a startup software development company is worth hiring for, after the first version exists rather than before it. The failure modes that show up in these ninety days are catalogued in what breaks when an AI-built prototype meets real users, the measurement layer for anything with a model in it is AI evaluation and observability work, and the run-rate arithmetic nobody does before launch is in what an MVP build actually costs. To have the failure modes named for your own system, the free production-readiness diagnostic reads a description of what you shipped and returns the ones most likely to bite first.