How to launch a product people actually use

I've launched products as a technical co-founder, as a founding engineer and as a solo founder. Some grew, some closed. The difference was rarely the code. It was whether we picked a real problem, shipped something small enough to learn from, and got it in front of the right people. This guide is the process I use now.

1. Start with a problem, not a feature list

Write one sentence: who has the problem, what it costs them, and what they do about it today. If you can't fill in the last part, the problem may not hurt enough for anyone to switch.

TracklistFinder started like this: fans of DJ sets on YouTube want the tracks, and today they scroll through comments and search songs one by one. That sentence told me exactly what the first version had to do, and what it didn't.

2. Talk to ten people before writing code

User interviews are the cheapest way to avoid building the wrong thing. For Granino, my sister and I interviewed specialty-coffee enthusiasts before building most of the product. It changed what we built first.

• Ask about the last time they had the problem, not whether they'd use your idea.
• Ask what they tried, what it cost and what annoyed them.
• Listen for the words they use. They become your marketing copy.
• Stop when you hear the same answers; often that's 8 to 12 interviews.

3. Cut the first version down

An MVP is the smallest product that proves people want this. Write every feature you have in mind, then mark each one: does a user need it to get the core value on day one? Everything else goes on a "later" list. That list is a feature, not a failure.

A good first version usually has one core workflow, sign-up, a way to pay or express intent (even a waitlist), and analytics. It does not need an admin dashboard, five integrations or a mobile app.

4. Build it so it can grow

"Throwaway MVP" is a myth: the code you ship first is usually the code you live with. You don't need to over-engineer, but a few choices are expensive to change later:

• Data model. Spend an extra day on it. It outlives everything else.
• A boring, well-supported stack. Rails, Next.js, Supabase and Postgres are boring in the best way.
• Hosting that scales without a DevOps hire. Vercel, Render or managed AWS services.
• Analytics from day one, so you can learn from the first user.

Release weekly, even before launch. Clicking through a real product every week is how founders and builders stay aligned.

5. Get found before you launch

Most launches fail quietly because nobody sees them. Start the visibility work while you build:

• A landing page that states the problem in your users' words, with a waitlist.
• Technical SEO basics: fast pages, clear titles, structured data, a sitemap.
• Pages for the questions your users search for, not just your product name.
• Make your content readable for AI assistants: clear structure and an llms.txt file.

This is what made the difference for TracklistFinder: it ranks high on Google and gets recommended by AI assistants, and that search traffic is a big part of its growth. See how to grow your website's visibility for the full checklist.

6. Launch where your users already are

Forget the single big launch day. Launch several times, in the places your users already spend time: the communities, forums, newsletters and social channels your interviews revealed. Share the problem and what you built, ask for feedback, and reply to everyone.

7. What to do after launch day

1. Watch what users actually do. Where do they drop off?
2. Talk to the first users who stayed, and the first who left.
3. Fix the biggest drop-off before adding features.
4. Pick one growth channel that works and double down.
5. Decide on pricing early. Charging is the best validation there is.

8. Where AI fits

AI is a tool, not a strategy. It shines with messy text, fuzzy matching and summarising: TracklistFinder uses an LLM because tracklists are written in a hundred different formats. Use it when it beats the simpler alternative, and build it with fallbacks and cost limits like any other production feature.

The goal isn't to launch. It's to build something people use and pay for. Launching is just the first time you find out.