Your Support Window Is Measured in Days. Your Bugs Are Measured in Users.

A hosting platform sent us a notice this week about one of our builds. The database project was going to be paused for inactivity. Seven days without a query and it goes to sleep.

The app was live. It had been handed over two weeks earlier. Every account had been moved into the client's name, the code was deployed, the thirty day maintenance window was open and running. And a machine somewhere had looked at the traffic, found nothing, and correctly concluded that nobody was using it.

Nothing was broken. That is the part worth sitting with. The build was finished, the handover was clean, and the most accurate description of the product's first two weeks in the world came from an automated billing system: no activity detected.

The line in the contract nobody reads carefully

Almost every fixed scope software agreement ends with some version of the same clause. Thirty days of support after launch. Critical bug fixes only. No new feature work.

Founders read that line as a safety net, and it is one. It exists because software that has never met a real user is software that has not been tested, no matter how many times the build team clicked through it. The window is the period where the things you could not have found get found and fixed on someone else's clock.

Here is the mismatch. That window is measured in calendar days. The defects it exists to catch are not produced by days. They are produced by users.

A thirty day window with four hundred logins in it is worth a great deal. A thirty day window with zero logins in it is worth nothing at all, and it costs exactly the same. You can burn the entire thing on an app that is technically perfect and functionally asleep, and no invoice will ever show you what you spent.

What real users actually break

There is a specific class of defect that only exists once other people show up, and it is almost never in the feature list.

Someone signs up with a work email instead of a personal one and a corporate security scanner eats the verification link before the human clicks it. Someone gets invited twice. Someone leaves the tab open for four hours, comes back, and lands in a session the app does not know how to recover from. Someone is added, removed, and added again. Someone uploads a file that is technically supported and practically enormous. Someone does the steps in the wrong order, because nobody told them there was an order.

None of these are the kind of bug a developer finds, and that is not a criticism of developers. The build team knows the intended path. They walk it dozens of times a day. They cannot unknow it. The first stranger who touches your product brings something no amount of internal testing produces, which is genuine ignorance of how it is supposed to work.

That is what the support window is for. It is the period where a stranger's confusion is still covered.

Handover is a sequence, not a date

The other thing that quietly eats the window is that "launch" is rarely one moment.

On the build I opened with, the handover ran across several days and several systems. The client stood up accounts in their own name for hosting, for the database, for email delivery, for DNS, and invited us in as members so we could keep supporting them. Hosting transferred on one day. The database transfer had to be scheduled separately, because moving it carries a short stretch of downtime and doing that unannounced to a live app is not a thing you do to a client.

Every one of those steps is correct. Every one of them also takes calendar time, and on most agreements the clock is already running while they happen. By the time the last transfer lands and the founder is genuinely ready to put the product in front of people, a meaningful slice of the coverage is gone.

This is not an argument that handovers should be faster. Rushing account transfers is how a founder ends up locked out of their own infrastructure. It is an argument that the clock and the work are measuring two different things, and only one of them is in the contract.

The obvious fix is not "ask for longer support"

I want to be honest about the cheap answer here, because the cheap answer is to demand ninety days instead of thirty and feel like you negotiated something.

A longer window does not fix the problem. It moves the silence. If nobody uses the product in the first two weeks, nobody uses it in the first six either, usually for the same reason, which is that getting real users in front of a new product is work and nobody scheduled it. Founders consistently plan the build in detail and plan the launch not at all. The product ships into a calendar with nothing on it.

What actually works is deciding, before the window opens, what is going to happen inside it.

Four things to settle before the clock starts

What starts the clock. Ask whether the support period begins at handover or at first real use, and say which one you want out loud. Many shops will agree to the second if you ask, because a support window with usage in it is better for us too. We would much rather fix the invitation bug in week two than hear about it in month four when it is a favor rather than a commitment.

Who your first ten users are, by name, with a date. Not a segment. Ten actual humans, and the day each of them is going to log in. If you cannot name them, your product is not ready to launch, and that is a much cheaper thing to discover before the window than during it.

What each platform does when nothing happens. Free and starter tiers pause. Trials convert or expire. Certificates renew. Cards on file get replaced when a bank reissues them. Ask your team for the list of services your app depends on and what each one does after a stretch of inactivity, then put the renewal dates somewhere a human will see them. An app can go down without anyone touching the code.

What counts as a fix and what counts as a new request, in writing. The most common way a support window turns into a bad conversation is that the founder thinks "it should work like this" and the shop reads the scope document. Settle that definition while everyone is still happy. A written line about what the window covers protects both sides, and the shop that will not write one is telling you something.

The real point

A maintenance window is insurance you have already paid for. It is one of the few parts of a software agreement that gets more valuable the harder you use it, and almost the only one founders routinely leave on the table.

The most expensive version of launch is not the one where things break. It is the one where nothing happens at all, quietly, for several weeks, while the only coverage you were ever going to get runs out and a billing system somewhere notices before you do.

Do not ship into silence. Ship into ten people with a date next to their names.