How Do You Launch Software When Nobody Is Waiting for It?

There is a spreadsheet. It has a date in bold, a tab of publications nobody has spoken to, a countdown of tasks, and a row for the announcement post. On the Tuesday, the post goes out. Forty people visit. Two sign up, neither returns, and the team spends the following week arguing about whether the headline was wrong.

The headline was not the problem. The problem is that a launch does not create demand, it collects it. If nothing is waiting, there is nothing to collect, and putting a date in bold does not change the arithmetic. Most teams shipping their first product are in exactly that position, and the ceremony they are copying was designed for companies who were not.

So the SaaS launch strategy we would run for software nobody has heard of contains no launch day at all. It contains a sequence: a small number of design partners who genuinely have the problem, one narrow audience you can name, documentation that does the work of distribution, and a public opening that happens on a curve rather than on a Tuesday. It is slower to describe and much faster to recover from. What follows is how it runs, and what to do in the week after, which is the part everyone skips.

The launch day myth, and where it borrowed its confidence

The launch-day model comes from products that arrive into an audience which already exists. A phone, a film, a sequel, a console. The date matters because a distribution machine has been pointed at it for months and thousands of people have already decided to care. The event is the release of pressure that was built up deliberately, over a long time, at considerable expense.

Software teams copy the ceremony and skip the pressure. Then they are surprised when the ceremony does nothing, which is a little like renting a stadium and being disappointed that no team turned up. The launches you remember were also, almost always, the visible end of a year of quiet work: private betas, partner deals, a mailing list built one conversation at a time. You saw the last day of the process and mistook it for the process.

There is a subtler cost too, and it is the one that persuades us. A launch date compresses everything into a single sample. If it goes badly you learn that something was wrong: the audience, the positioning, the price, the onboarding, the product, the day of the week. One data point, six candidate explanations, and a demoralised team. A rolling opening produces a stream of small, attributable results instead, which is the only practical way to find out which of the six it actually was.

What a launch is actually for

Strip away the theatre and a launch has three jobs. Every one of them can be done without an announcement, and doing them without an announcement is usually better, because you can stop and fix things halfway through.

• Proof it works for somebody specific. Not that it runs. That a named person with a real problem now does something differently on Monday because of it, and would notice if you took it away.
• A sentence that repeats. One line a user says back to you, unprompted, when a colleague asks what it is. If you are still writing that sentence yourself, you are not ready for an audience.
• A path to the next user you can run again. Where they came from, what they read first, what convinced them. A path is only real once you have walked it twice.

Notice that none of the three is a number of visitors. Traffic without any of these is a spike you cannot reproduce, and reproducing it is the entire business.

Start with design partners, not beta users

A beta user tries the thing. A design partner commits to a problem, gives you their time on a schedule, and tells you when it is bad. That is the difference between a survey and a relationship, and only one of them changes what you build.

How many, and who

Three to six is the range we would aim for. Fewer, and one loud opinion becomes your roadmap. More, and you cannot give any of them enough attention to learn anything, which was the point of the exercise. Choose them for the same problem rather than the same industry: two agencies and a hospital can share a scheduling problem exactly, while two agencies with different problems teach you nothing about each other.

The strongest signal to recruit against is somebody already paying to solve this badly. A spreadsheet maintained by hand every Friday. A contractor doing it manually. An intern whose job is the workaround. Those people have a budget and a grievance, which is a far better qualification than enthusiasm. Enthusiasm is what you get from people who like the idea, and liking the idea has never predicted anything. This is also where honest research that could have changed the plan pays for itself, as opposed to research run to confirm a decision already made.

The deal, stated out loud

Write the arrangement down, even informally, because unwritten early-access deals end badly for both sides. They get access, real influence over what gets built, help moving their existing mess into the product, and terms that hold for a defined period. You get a scheduled conversation every two weeks, honest reports of what broke, and permission to ask uncomfortable questions. Both sides get an end date, after which the arrangement either becomes an ordinary paid relationship or ends cleanly.

One narrow first audience

After the design partners comes the first audience, and the instinct is to make it as wide as possible so as not to exclude anyone. That instinct is wrong for a reason worth internalising: a wide audience makes every result uninterpretable. If you sold to nobody in particular and nobody bought, you have learned nothing about who might.

Narrow means nameable

A first audience is narrow enough when you can list the three places those people gather, the words they use for the problem, and the job title of the person who signs off. If you cannot do all three, it is not a segment, it is a demographic guess. And you should be able to write the homepage so specifically that most visitors bounce and the right ones feel it was written for them, because it was.

Narrow now does not mean narrow forever. It means you earn the right to widen by having somewhere to widen from. Teams struggle here when they mistake a positioning problem for a product gap, which is why every conversation ends in a promise to build something. If your first audience keeps asking for the feature that would make you a different product, read that as positioning rather than backlog: the case is made in when a feature request is a positioning problem.

Documentation is distribution, not support material

For anything technical, the documentation is the top of the funnel and the sales conversation at once. People do not search for your category. They search for the problem in the words they use for it, at eleven at night, with an error message pasted into the box. The page that answers that question is doing more work than the homepage, and it does it while everyone sleeps.

Which means the docs have to exist before the opening rather than after it. Publish the setup guide with real commands. Publish the limits, including the embarrassing ones. Publish the migration path from whatever people use now, because that is the actual objection. Publish a changelog with dates on it, since nothing reassures a cautious buyer like evidence that the thing is alive. And publish the comparison you would rather not write, because somebody else will write it worse.

Two practical points. First, docs only work if they are crawlable: outside the login, linked from somewhere, present in the sitemap, and written to answer a question rather than to list features. Search fundamentals do more for a small product than a campaign budget does. Second, docs rot the moment updating them becomes somebody’s separate chore. Keeping them beside the code helps, and a workspace like Acrosite approaches it from the editorial side, generating the files, committing them to GitHub and triggering the configured deployment, so a documentation change becomes the same kind of event as a code change rather than a favour someone does on a Friday. Treat the docs as part of shipping and they stay true. Treat them as a chore and they become the reason a good product looks abandoned.

The honest limitation: this is slow. Documentation compounds, and compounding takes months before it looks like anything at all. A team that needs revenue inside eight weeks should not treat it as the primary channel, and should be talking to people directly instead. It is the channel that keeps working after you stop pushing, which is a different and better property, but it will not rescue a runway.

The slow public opening

Here is the sequence we would run once the design partners are using the product on their own initiative and the first audience has a name. Each step carries a condition for moving on, and the conditions are the whole point.

1. Publish the product pages and the docs quietly. No announcement. Let them be indexed, let colleagues read them, and fix the three sentences everybody misreads before anyone important arrives.
2. Open a request list with a real reason to join. Not “join the waitlist”. A specific promise: early access for people running the exact workflow you support, with help moving across.
3. Let people in a handful at a time, by hand. Manual approval is a feature at this stage. You get to watch each first session, and you get to stop when something is broken instead of breaking it for everyone at once.
4. Fix the first ten minutes until it stops generating questions. Every question asked twice is a defect in the interface or the copy, not a gap in the user. Fix it before the next batch arrives.
5. Remove the gate when support per new account stops climbing. That is the signal that the product now explains itself. Until then, more traffic simply buys you more of the same conversation.
6. Then tell people, once, with something to show. A public opening backed by working documentation, a changelog and users who will say the sentence for you is worth more than the identical post sent three months earlier.

A launch is not a date. It is the moment you stop hand-carrying every new user and the product keeps working anyway.

The week after, which nobody plans

Whatever form the opening takes, the seven days that follow decide more than the opening did. Teams plan the announcement in detail and plan the week after not at all, so the week after fills up with whatever is loudest.

What to watch

Not signups. Signups measure your copy, and by the second week they will have flattened anyway. Watch activation: the proportion of new accounts that reach the moment where the product has actually done its job once. Watch where sessions end, because the drop-off point names the defect. Watch the questions that arrive twice. And watch the first ten minutes closely enough to sit through a recording of one, keyboard and screen reader included, because an onboarding path that cannot be completed without a mouse excludes people silently.

Resist the urge to judge retention this early. It is the slowest signal you have, and reading it at day seven produces confident nonsense. The argument for watching earlier behaviour instead is set out in churn is a lagging indicator, and it applies with double force in a first month where the sample is tiny and every account arrived by a different route.

What not to do

Do not rewrite the roadmap from the loudest email. Do not buy traffic to fix what is actually an activation problem, which is the most expensive mistake available in week one and the reason cost per lead is a trap exists as an argument. Do not declare the thing a failure on day seven, because the sample is far too small to carry the conclusion. And do not go silent, which is the most common failure of all. Ship something visible every week, tell the people who signed up what changed, and let the lifecycle messaging do the work of staying present without anyone having to be clever about it.

One staffing note, because it decides whether any of this happens at all. A rolling launch needs somebody watching sessions and answering messages every day for weeks, which is precisely the capacity a small team does not have while also delivering client work. Decide in advance who is protected from that pull, and name them. If the answer is that everyone will pitch in, the honest translation is that nobody will, and the opening will quietly become an announcement after all.

When a launch day is genuinely the right call

The advice reverses under four conditions, and they are worth naming precisely because they are the conditions most teams wrongly believe they meet. You already have an audience that has asked for this, by name, in writing. A marketplace listing, a conference slot or a platform release hands you a fixed distribution moment you did not have to build. A regulatory or seasonal deadline makes the product worthless a week late. Or a funding round requires a public moment on a schedule somebody else set.

In those cases the date is a forcing function attached to real distribution, and the ceremony earns its cost. Outside them it is a costume. The test is simple: if the date vanished from the calendar tomorrow, would any person outside the company notice? If not, the date was for you rather than for them.

And the honest cost of the approach argued here, since it has one. A rolling launch is harder on morale. There is no day where the team stands together and celebrates, no photograph, no clean before and after, just a long series of small weeks. You have to manufacture the milestones deliberately: the first account that renewed without a conversation, the first support question answered by the docs, the first user who described the product to somebody else correctly. Mark those out loud, or the team will feel as though the thing never launched. The funding question underneath all of it, whether the runway comes from client work or from the product, is argued in client work and product work.

The decision rule we would leave you with: pick the smallest group you can serve completely, serve them until the product explains itself, and let the opening be the consequence rather than the cause. If you are planning a product launch and want a second opinion on the sequence before the calendar hardens, tell us who it is for and what they do today instead.