In the previous Chapter 4, "Build with AI," you got something working. From here is Phase 4, "ship" — the stage of testing that it doesn't break, plugging security holes, and releasing it to the world. Don't settle for "it works"; carry it all the way to a state where others can touch it with peace of mind. It sounds hard, but AI is your partner here too.
"Unfinished is fine. Deliver it safely to one person first."
"Built" and "shippable" are different
Something that works on your own computer and something others can safely touch are two different things. You know "the right way to use it," so you operate it as intended. But once it's public, inputs, operations, and malice you never anticipated come flying in. People who submit blank fields, people who paste in mountains of symbols, people who try to peek at others' data.
That said, there's no need to brace yourself. What you should do first in indie development is just three very basic points: "does it not break," "do secrets not leak," "is others' data protected." This chapter is about clearing that minimum together with AI and launching with confidence.
You only touch it via the correct steps. If an error appears, you can fix it. You don't mind secret info showing on screen.
Unexpected inputs arrive. Internal info leaks from an error screen. A key accidentally exposed can cause huge bills or data leaks.
Leave testing and review to AI
"Solo, there's no senior to review your code." That's exactly the role to leave to AI. Have AI inspect, from a different angle, once more, the code you wrote (or had AI write). The one who wrote it (human or AI) has trouble noticing their own mistakes. That's why setting up an "auditor" works.
The method is simple. Just paste the code and ask this: "List the bugs, dangerous inputs, and missing tests in this code." Back come the holes you didn't notice, as a list. Then fix them one by one, highest priority first. Don't try to fix everything at once; the knack is to fix one item, verify it works, then the next.
When you ask AI to audit, spelling out perspectives like the following improves accuracy.
"When does it crash?" "What if I pass a blank or zero?" Have AI hunt for the conditions that break it.
Malicious strings, huge data, invalid files. Ask "how would an attacker exploit this?"
"Which cases should be checked but aren't?" Have it surface boundary values and exceptions.
"Are API keys or passwords hard-coded in the code?" Nip the seeds of a leak early.
💡 A test is "a mechanism that checks automatically." On the hands-on route, have AI write the test code too. Ask "write tests for this function, including the normal case and blank/abnormal-value cases," and next time you fix something you can re-verify nothing broke with one button. On the beginner route, even just manually "trying deliberately weird operations" is a solid first step.
The three security minimums
Security is a deep field, but when launching an indie project, just remember these three points you must lock down first. Miss these three and you could lose money, trust, and others' information all at once. Conversely, keep just these and it's enough for a first launch.
Don't write API keys, passwords, or tokens directly in the code. Move them into an environment-variable file like .env, and exclude that file from publishing (add it to .gitignore).
If you have a login feature, make it so user A can't see anyone else's data. Always add an owner check — "does this data really belong to this person?" — and have AI verify it.
Give external-service keys and DB permissions only as much as needed. Don't hand out a "can-do-everything" key. Issue keys scoped to purpose: disposable keys, read-only keys, and so on.
🚨 Never publish a secret key. This is the most common — and most costly — accident in indie development. Hard-code an API key and publish it to somewhere like GitHub, and it's automatically found and abused within minutes to hours. With a paid API, a bill of hundreds of thousands of yen by the time you notice has actually happened. Before launch, always have AI inspect "is a key still left in the code?" And any key you've exposed even once: deletion isn't enough — always invalidate it and reissue a new key.
If it feels "hard," just ask AI this and you'll be fine: "Before I publish this code, teach me the security things I should do, for a beginner." A concrete checklist tailored to your code comes back.
Run automation safely (for hands-on)
This part is mainly for the 🔧 hands-on route. Letting an AI agent like Claude Code handle file operations and command execution automatically speeds up development dramatically. On the flip side, the risk of it going rogue — "deleting an important file on its own," "running an unintended command" — isn't zero either.
That's why the concept of "isolation (sandboxing)" matters. When handing AI strong permissions, run it inside a box where any damage is harmless. Concretely, confine it to a dedicated working folder or container so it can't touch production data or secrets. Do this, and you can delegate automation to AI with peace of mind.
📦 "Experiment inside the box, take production slow" is the principle. Don't run AI's auto-execution straight on the production environment or important data. For the concrete how-to of isolation, see the Claude Code sandbox setup guide for a detailed walkthrough. For those on the beginner route, just knowing "there's a safety measure like that" is enough for this section.
Launch — from code to live on the web
Now to launch. "Launching" means taking what's inside your computer and placing it on the web so anyone can open it by URL. This is called deploying. It sounds hard, but these days you can put it on a free service in a few clicks.
The rough flow is the following 3 steps. A first indie launch can be fully covered entirely on the free tier. Spending money can wait until the people using it grow.
Save the code to somewhere like GitHub. Don't forget to exclude the secret file (.env). This becomes the foundation for launching.
Link GitHub to free hosting like Vercel. Register secrets as environment variables from the admin screen.
It builds on the web automatically and a public URL is issued. All that's left is to hand that URL to one person.
✅ Even unfinished, launch and show one person. "It's still missing features," "the design's iffy" — putting off launch with that feeling is the number-one reason indie projects vanish. 60 is fine. Carry it through to sending the public URL to one person nearby. Their single "this part's hard to use" is worth more than 100 hours of worrying.
The concrete steps — from saving to GitHub, to publishing on Vercel, to setting environment variables — are walked through with screenshots in the workflow for building with Claude Code / Cursor and publishing on Vercel. If you get stuck, just ask AI "I got an error on this screen, what should I do?" and you'll usually get out.
- Even solo, make AI your reviewer. Have it audit with "list bugs, dangerous inputs, missing tests," and fix one by one.
- Security's minimum three: secrets into environment variables / protect others' data / keep permissions minimal.
- Never publish a secret key. If leaked, invalidate and reissue, not just delete. Inspect with AI before launch.
- Launch (deploy) is fine on the free tier. Carry it through to handing the URL to one person, even unfinished.
With that, you've reached "build it and ship it safely." But the real contest starts here. Getting it used, improving it, and shaping it into something sustainable is the final phase. On to Chapter 6, "Grow — marketing and monetization."