Ship your v1 to founding members (UK SaaS, Claude Code 2026)

You scaffolded the skeleton, wired Supabase auth and Stripe billing, and the core feature works. Three founding members have already paid you in pounds. The last step is the one that decides whether they stay: putting the v1 in their hands.

This is launch, but at the smallest, most forgiving scale you will ever have - three people who already believe in you. That is a gift. Most products launch to silence; you launch to a warm, paying, invested cohort. Treat it accordingly: this is not a public launch to optimise, it is a handover to get right.

Pre-launch: check the path, not the product

Before you send a single login link, run five checks. Notice they are all about the path your founding member will actually walk, not your whole feature set.

1. Signup-to-first-value works in production. A real magic link arrives, login succeeds, the user reaches the one valuable thing. End to end, on the live URL, not localhost.
2. A real GBP test payment works. Run a card through Stripe and confirm your webhook marks the account active in Supabase. The thing you built last session - prove it live.
3. Env vars and the live database connect. You proved this on day one when you deployed the empty skeleton; confirm it again now there is real data flowing.
4. Errors are visible to you. A basic error tracker, or at minimum structured logs, so you find out something broke before your founding member emails you.
5. Contact is one click away. A visible "something wrong? message me" the moment they hit a wall.

What is deliberately not on the list: every edge case, every settings screen, a polished marketing site. Founding members forgive rough edges. They do not forgive a login link that does not work. Check the path, ship, fix the rest live.

Ask Claude Code to walk the critical path with you and flag anything on those five points that is not solid. Then go.

Onboard the three by hand

With three founders, you do not need an automated onboarding flow. You need to walk each one in personally - and treat it as your richest research, not just delivery.

For each founding member:

• Send a personal message, not a templated drip. They paid early; they get a human.
• Give them the login link and a one-line "here is the thing you paid for."
• Get on a 15-minute call or ask them to record their first session.

Then watch where they hesitate. The moment a founder pauses, clicks the wrong thing, or asks "so what do I do now" is a precise instruction for your next build session - worth more than any analytics dashboard at this stage. Automating onboarding for three people is premature optimisation. Doing it by hand turns your launch into product direction.

This is the same instinct that made the Mom Test interviews work during validation: watch behaviour, do not ask for opinions. You are still doing that - now with a live product instead of a smoke test.

The launch-day sequence for three people

A founding launch is not a big-bang public launch, and trying to run it like one wastes the advantage. You are not chasing a Product Hunt spike or a flood of signups you cannot support. You are handing a finished thing to three people who already trust you. So sequence it small and staggered:

1. Send the first founder the link, alone. Not all three at once. The first handover is also your final smoke test - if the magic link is slow or the first-value flow has a rough edge, you find out from one forgiving person, not three at the same moment.
2. Watch or hear that first session, then fix the obvious thing. There is almost always one obvious thing - a confusing label, a missing "what now" prompt, a step that needs a sentence of guidance. Claude Code can ship that fix in minutes. Do it before founder two.
3. Send founders two and three once the path is smooth. Now you are handing over a path you have already watched a real person walk successfully.

Staggering across an afternoon or a day costs you nothing and means each founder's first impression is better than the last. With three customers you have the luxury of treating each handover as an event. Use it.

A note on what not to do on launch day: do not announce publicly, do not chase press, do not open signups to strangers. The v1 is sized for three people and a feedback loop. Widening the door before the founding cohort is happy and retained just imports noise and support load you are not ready for. Public launch is a later post in your story, after the product has earned it.

The feedback loop for a handful of users

A new v1 with three users does not need a feedback portal or a voting board. It needs a direct, low-ceremony loop:

• An instant channel. A small Slack or Discord, or honestly a WhatsApp group for three people. Somewhere they reach you in seconds.
• One-click in-app feedback. A button that fires a message to you, with context attached.
• A visible backlog. A short, public-to-them list of what you are working on, so they see their input turning into shipped changes.

The magic is the visible turnaround. When a founding member suggests something on Monday and sees it shipped by Thursday with a "you asked for this" note, they stop being a customer and start being invested. The goal of the loop is not to collect feedback - it is to close it visibly. A closed loop is what converts curiosity into loyalty.

Iterate fast, protect scope harder

After launch, ship a small visible improvement two or three times a week. Fast enough that founders feel momentum; slow enough that you are not breaking production daily.

The risk is not too few requests - it is too many. Three engaged founding members will generate more ideas than you can build, and most are theirs, not the market's. Filter every request through one question:

Does this remove friction from the core flow the founder paid for, or does it expand scope?

Build the friction-removers first. Park the scope-expanders in the visible backlog where founders can see they are not forgotten. Claude Code makes the building fast - which paradoxically makes discipline more important. When you can ship almost anything in an afternoon, the constraint is no longer speed, it is choosing the right thing. Keep the v1 narrow and let real usage, not the loudest voice, tell you what is next. The weekend vibe-coding playbook covers the build-cadence mechanics if you want them.

The only metrics worth watching at three customers

It is tempting to wire up an analytics dashboard on day one and start staring at it. Resist that too. At three customers, most metrics are noise dressed up as insight - a conversion rate calculated from three people tells you nothing, and a retention curve needs more than a week and more than a handful of users to mean anything.

There are exactly two things worth watching in the founding phase, and neither needs a dashboard:

• Did each founder reach the core value? Not "did they log in" - did they actually do the one valuable thing the product exists for. You can answer this by looking, because there are three of them. If a founder logged in once and never came back, that is your single most important signal, and it deserves a personal message, not a row in a chart.
• Is the feedback loop turning? Are suggestions coming in, and are you shipping them visibly? A loop that has gone quiet after launch usually means the product is not yet useful enough to have opinions about - which is itself the feedback.

Everything else - traffic, funnels, cohort curves - is for later, when you have enough users that aggregate numbers carry information. For now, the richest analytics you have is a 15-minute call. Spend your attention on the three humans, not on instrumenting them.

Turning three founders into three retained customers

The refund risk in month one is real, and it comes from exactly three places:

• The product never delivered the core value they were promised.
• They hit a wall and could not reach you.
• They felt ignored after paying early.

You defuse all three the same way: deliver the core thing fast, be radically available, and ship their suggestions with credit.

Concretely, in the first two weeks, make sure each founder has:

1. Reached the valuable outcome at least once. They have actually got the thing they paid for, not just logged in.
2. Had at least one piece of feedback shipped. Visibly, with a "you asked for this."
3. Heard from you personally. Not a broadcast - a message to them.

A founding member who got the thing they paid for, got heard, and watched the product improve because of them does not ask for a refund. They tell the next person. Retention in the founding phase is a relationship, and at three customers you can genuinely have one with each.

That is the whole loop, closed: you validated the demand, pre-sold the founders, scaffolded and shipped the v1 with Claude Code, and turned three paid promises into three retained customers. The next idea worth building is already waiting.

---

Building your validated idea? IdeaStack publishes one deeply-researched, UK-specific business opportunity every week - real keyword volumes, competitor analysis, SERP landscape, and copy-paste builder prompts. Read this week's free report and find the next one worth shipping.