From prototype to product: everything you need beyond the code

There is a moment, when you are building with an AI coding tool, where you think you have built something that works and can be used. The thing runs on your laptop. It looks right. It does what you asked. You feel finished.

You are not finished. You have crossed the starting line.

This applies whether you are building a startup, a side project, a hobby tool, or something you made for fun and want to share. The moment you want other people to use what you built, a whole set of concerns kicks in that the prototype did not require. Security, reliability, discoverability, trust. The things that let a stranger find your product, figure it out without your help, and come back tomorrow.

The distance between a working prototype and that point is larger than most builders expect. AI tools have made the prototype almost trivial. Everything after it is mostly unchanged: the product work, the security work, the operations work, the legal work, and the launch work. Most projects die in that gap, not because the builder lacked skill, but because they did not know what was left to do.

This post is the map. I am a Senior Digital Product Manager currently building a product solo with AI coding tools, and this list comes from doing the work, not reading about it. It covers the key things at a high level. It is not a comprehensive list, and there is more to each topic than what is here. It is the first in a series. Each section below becomes a deeper post later. Read this one to know what exists and why it matters. Read the individual posts when you actually need them.

1. Start with the problem, not the prompt

The most expensive mistake in AI-assisted building is opening your coding tool before you have decided what you are actually building and for whom. AI tools are extraordinarily good at making the wrong thing fast. A weekend of confident prompting can produce a beautiful prototype that solves a problem nobody has.

Before you write a single prompt, answer these in plain language:

Who is this for? Be specific. "Small business owners" is not a person. "The owner of a small refill shop who uses Square for everything in store" is a person.
What problem are they currently solving badly? What are they doing today, and what does it cost them in time, money, or frustration?
What is the smallest thing that would make their life better? Not the full vision. The first useful slice.

If you cannot answer these, you are not ready to build. Talk to three real people who match your "who". Watch them work. Ask what they hate. The answers are almost never what you expected.

This step is not optional and AI cannot do it for you. The next post in this series goes deeper on how to validate whether a problem is worth solving.

2. Pick a stack you can move fast in

Now that you know what you are building, pick the tools that will let you move without fighting the framework. If you already know a stack, use it. The novelty should be in the product, not the technology.

If you do not know any stack yet, that is fine. Ask your AI coding tool to walk you through two or three common defaults for the kind of thing you are building, explain the tradeoffs, and recommend one. A common default for a small web product in 2026: Next.js, TypeScript, Tailwind, Postgres, hosted on Vercel. Not because it is the best stack for every job. Because it is well-trodden, AI tools know it intimately, and you will spend less time fighting unfamiliar tooling.

The wrong move is picking a stack because a tweet said it was fast. The right move is picking one that works for what you are building and sticking with it long enough to learn it properly.

3. Put it in version control early

Version control (git) tracks every change you make, so you can undo mistakes and see what changed when. The moment you have something you would be upset to lose, put it in version control.

Why it matters: AI coding tools move fast and sometimes break things. If you have version control, you can roll back to the last working state in seconds. If you do not, your only option is to manually figure out what went wrong. Version control is free, takes 30 seconds to set up, and pays for itself the first time something breaks.

A real project also needs:

A .gitignore — a file that tells git which files to ignore, so things like temporary files, installed packages, and secret credentials never get shared accidentally
A README so future-you (and any AI assistant you use) knows what this project is and how to run it
A project instructions file (like CLAUDE.md, AGENTS.md, or .cursorrules) capturing the decisions and conventions specific to this codebase. This is the file your AI coding tool reads at the start of every session. It is the difference between an AI assistant that helps and one that fights you.

4. Integrations and secrets

Most products need to talk to other services: a database to store data, an email provider to send messages, a payment processor to take money. These connections are called integrations, and they are how your product reaches beyond its own code.

Every integration needs credentials: an API key, a database password, a secret token that proves your product is allowed to connect. These are secrets, and they must never live in your source code. Not in a comment, not in a config file, not "temporarily until I move them later".

The pattern is simple:

Local development: secrets live in .env.local, a file that stays on your machine and is never shared
Production: secrets live in your hosting provider's environment variable store (Vercel, Fly, Render, GitHub Actions secrets)
Rotation: when something leaks, you rotate the secret immediately, not later

If you are using AI tools, the rules get stricter. Never paste a secret into a chat with any AI model. Once it is in the context, you cannot get it out. Treat your AI session like a public Slack channel.

5. A database (and what happens when it changes)

Whether you need a database depends on what you are storing, how much of it there is, and who needs to access it. A landing page with a contact form might not need one. A product with user accounts, saved data, or anything that needs to survive a page refresh probably does.

If you are building something personal and truly small, you do not need a real database on day one. A JSON file on disk, a Google Sheet, or a simple spreadsheet can be fine for a first version. Start simple. Swap in a proper database when the pain of not having one actually arrives.

When you do need one, Postgres is a safe default for most small web products. It is widely supported, free to start with, and well-known to AI tools. Hosted providers like Neon and Supabase let you create a database in seconds and scale later without managing servers yourself.

Databases change as your product changes. You will add columns, rename fields, realise the structure you chose in week one was wrong. Migrations are the way to apply those changes safely, in a way you can track and undo. Pick a migration tool early, even for a small project, because retrofitting one is painful.

You also need backups. Hosted providers usually do this for you, but check. The first time you accidentally delete data is not the moment to discover you have no recovery path.

6. Authentication

The moment your product has users, you need a way to identify them. Authentication is a topic where rolling your own is almost always a mistake. There are too many edge cases (password reset, email verification, session expiry, account recovery, abuse) and the cost of getting it wrong is your users' security.

The good news is that the boring options are excellent:

Magic links (one-time login emails): the simplest possible auth. No passwords for users to forget, no password reset flow to build. Best for low-security products.
OAuth (sign in with Google, GitHub, Apple): zero password management, very high conversion. Best when your audience already has those accounts.
Email and password: the default everyone knows. Highest friction. Use a battle-tested library, never write your own hashing.

For most projects, NextAuth, Clerk, Supabase Auth, or Neon Auth will save you weeks of work and hundreds of edge cases.

7. Where it actually runs

Your laptop is not where users find your product. You need somewhere it lives on the public internet, with HTTPS, a custom domain, and an automatic deploy pipeline so a git push becomes a live site.

The current best-default for small web products is Vercel: connect a GitHub repo, get production deploys on every push to main and preview deploys on every pull request, with HTTPS and global CDN included. Alternatives like Fly, Render, and Cloudflare Pages are equally fine.

You also need a domain. Cloudflare Registrar sells them at cost (around £8 to £15 per year for most TLDs) with no upsells. Buy your domain there, point it at your hosting, and never think about it again.

CI/CD is a fancy term for "the website rebuilds itself when I push code". Set this up on day one. The friction of manual deploys is the reason most projects stop getting updates.

8. Email

Almost every product sends email. Welcome messages, password resets, order confirmations, weekly newsletters. Email is ancient, deeply weird, and surprisingly hard to get right.

The two things you need to know:

Transactional email (one message to one user, triggered by an action): use a provider like Resend, Postmark, or SendGrid. Do not try to send through Gmail or your own SMTP server. Your messages will land in spam.
Deliverability: the difference between an email landing in the inbox and the spam folder is mostly DNS records (SPF, DKIM, DMARC are records that prove to mail providers you are allowed to send from your domain). Your email provider will tell you exactly what to add. Add them on day one.

If you are sending marketing email, an unsubscribe link is legally required in most jurisdictions and morally required everywhere.

9. Knowing it works (and knowing when it breaks)

Software breaks. You need to know when, where, and why. Three different tools, three different jobs:

Tests tell you the code does what you wrote it to do, before you ship it. Worth writing for the parts of the system where bugs would be expensive: payments, auth, anything destructive. Not worth writing for everything.
Logs and monitoring tell you what happened in production after the fact. Vercel, Fly, and most hosts give you basic logs for free.
Error tracking (Sentry, Highlight, Rollbar) tells you when a real user hit an exception, with the stack trace and the steps that led to it. This is the single most useful tool you can add. Set it up before launch.

There is a fourth thing, which is analytics: knowing whether anyone is using your product. Plausible, Fathom, and PostHog are good privacy-respecting options.

10. Legal basics

Even a side project that takes one email address has legal obligations. The exact rules depend on where your users live, but a sensible default for any product launched in or near Europe:

A privacy policy that says what data you collect and why
A cookie notice if you set non-essential cookies
An unsubscribe link in every marketing email
A way for users to delete their data if they ask (GDPR right to erasure)
A terms of service if you take payment or host user content

You do not need a lawyer for version one. There are templates. The wrong move is to skip this entirely and hope.

11. Launch (and after)

A working product that nobody knows about does not exist. Everything in this list so far is about making your product ready for real people. This section is about getting it in front of them.

There are two parts to launch: making your product findable, and actively putting it where people are.

Make it findable:

A sitemap and robots.txt so search engines can index your pages
Meta tags and an Open Graph image so links look good when shared on social media, Slack, or messaging apps
A favicon so your product looks legitimate in browser tabs
A contact method so users can tell you when something is broken

Put it where people are:

Post in the communities your users already visit: Reddit, Hacker News, Discord servers, Slack groups, niche forums
Share it on social media with context, not just a link. Explain what it does, who it is for, and what problem it solves
Tell the people you spoke to during validation (section 1). They already understand the problem.
Ask for feedback, not downloads. People are more willing to try something when you are genuinely asking for their opinion

The launch is not the day you push to production. The launch is the day someone uses your product without you explaining it to them.

That first contact with real usage is where you learn the most. Features you thought were obvious will confuse people. Things you considered edge cases will turn out to be the main use case. The earlier you get your product in front of others, the faster you learn what actually matters. Everything before launch is guessing. Everything after it is learning.

SEO, content marketing, and long-term growth get their own posts later in this series. The items above are enough to get your first real users.

After launch, the work continues: backups, performance, accessibility, documentation, support. Shipping is the start of the real job, not the end of it.

What is not in this list (yet)

This post is already long, so I cut topics that matter for many products but deserve their own space: payments (Stripe, tax, fraud), onboarding (what the first-time user actually sees), design and UX (the gap between "it works" and "a person can figure it out"), security beyond secrets (input validation, injection attacks), and several others. They are coming as their own posts in this series.

What this series is for

None of this list is meant to be a gate. It is not about doing everything perfectly before you are allowed to ship. It is about knowing what exists so you can make conscious choices about what to do now, what to do later, and what to skip entirely.

The point of this series is to make the gap between idea and shipped product visible, then walk through it one section at a time. AI tools have changed which parts of that gap are hard. They have not removed it. If anything, by making the prototype faster, they have made the rest of the work more obviously the bottleneck.

Each section in this list becomes its own post, going deeper into the how. Follow along for the rest of the series, or subscribe at prototypetoproduct.com to get them by email.

If you are building something and want hands-on help getting it to production, I offer one-to-one sessions.