After launch: from trial release to a product that pays

Stage 1: the trial release, with pilot customers

Your pilot customers are using the product for real work. Your job now is to learn, quickly and specifically.

• Watch usage, not opinions. Which features get used every week? Which are ignored?
• Talk to users every week. Short calls, with the people doing the work, not only the buyer.
• Keep a list of everything they ask for, and resist building it all. Look for requests that come from several customers.

Stage 2: the commercial release

This is the version you can sell to customers who were not part of the pilot. It usually needs:

• Self-service onboarding, so a new customer can start without you on the phone.
• Billing that runs without manual work.
• Support and admin tools, so you can help customers without asking a developer.
• The security and compliance evidence your buyers will ask for.

Signals that it is working

For business products, the clearest signals are behavioural: pilot customers converting to paid, customers renewing, accounts adding users or sites, and customers introducing you to peers. If customers keep using the product but none will pay, revisit the price or the buyer before building more features.

Stage 3: the iteration loop

Settle into a rhythm: decide what to learn, build the smallest change that teaches it, ship it, measure it. Short cycles of a week or two beat large releases. Keep a written list of what you are not building this quarter.

Stage 4: technical scaling, when it is actually needed

Most early products do not have a scaling problem; they have a customer problem. Signs that the technology genuinely needs attention:

• Pages or reports getting noticeably slower as data grows.
• Releases that frequently break something unrelated.
• A large customer whose requirements (single sign-on, data residency, audit logs) the current design cannot meet.

Fix the specific bottleneck. A full rewrite is rarely the right answer this early.

Stage 5: the team

Your first hires after launch are usually customer-facing: someone to sell and someone to support. Your first in-house engineer makes sense when there is a steady stream of work and someone to lead them. Until then, a build partner who already knows the code is usually cheaper and faster.

Preparing to raise

Investors at this stage want evidence of customers paying and staying, and confidence that the product can be extended. If you need a credible technical story for a round, the Fundraising Tech Pack covers scope, architecture, cost and a technical partner letter in two weeks.

On our Founder's Path, this is also the period when the revenue share starts recovering the Build Value, which keeps us invested in exactly these stages.