You've outgrown the app builders. Take control.

Lovable, Bolt, v0 — the browser app builders are a genuinely great way to find out whether your idea deserves to exist. Describe what you want, watch it appear, share a link the same afternoon. If that's where you are, stay there; nothing in this series is urgent yet.

Then, for some apps, the ceiling arrives. A bug the builder keeps almost-fixing. A feature that loops through the same three wrong versions. A pricing tier you've outgrown. The creeping realization that your product — the thing you tell people you're building — lives inside someone else's website, and what you actually own is a login.

The ceiling has a name: control. And taking it doesn't mean learning to code. It means holding three things the builder currently holds for you.

What the builder is holding

Your app is, in the end, a folder of text files. That's the whole secret. Whoever holds the files holds the app — and right now the builder does, along with the two other things this series depends on:

The files. You can't put a rules file or a decision log into a project you can't see. Every practice in this series starts with the project being yours, on your computer, readable by any tool you choose.

The history. Serious projects keep every version of every file forever, with a note on what changed and why — which is what makes any mistake undoable. Builders keep some history for you, on their terms. You want it on yours.

The judgment about what's safe. The builder decides what checks run and what gets deployed. Once you hold the files, you set the rules — which is what the rest of this series is about.

The two tools that replace it

GitHub is where the files and the history live — think of it as the filing cabinet plus the save-point system, with a full copy of everything kept off your computer. It's free, it's where effectively all of the world's software lives, and it quietly solves a problem you'll meet again in part five: a copy of your app that survives your laptop.

Claude Code is the AI coding agent — the same kind of AI that powered the builder, but working directly on your files, on your machine, under your rules. It reads the rules file you'll write in part three, runs the checks, and explains what it's doing in plain language when told to. It's what Groundwork — this site — is built with, which is why this series names it; other local agents work similarly.

The difference in feel is real and worth being honest about: the builder was a product, with guardrails and a big friendly button. Claude Code is a capable colleague in a plain window, and it does what you ask — which is exactly why the rules and habits in this series exist.

The afternoon of basics

You need less than you fear. Four ideas, not four skills:

• A repository ("repo") — the folder that is your project, with its history attached.
• A commit — a named save point. The unit of undo.
• Push — copying your save points up to GitHub.
• The terminal — the plain text window where Claude Code runs. You type to it like a chat; it just isn't pretty.

Make a free GitHub account, install Claude Code from Anthropic's official quickstart, and let the official docs teach you the clicks — they're current, this page would rot. One afternoon is genuinely enough, because your AI handles the mechanics; you only need the ideas.

Moving out

Most builders can export your project or sync it to GitHub — the feature is usually called "export code" or "GitHub sync," and it's also the fastest way to find out how much of "your" app you were actually holding. Once the project is on your machine, paste this into Claude Code:

I just moved this project out of a browser app builder, and this is my
first time working outside one. I am not an engineer and I won't read the
code. In plain language, always:

1. Look through the whole project and tell me what's here — and what's
   missing because the builder was quietly providing it (the database,
   hosting, secret keys, sign-in). For each missing piece, tell me my
   options and costs before setting anything up.
2. Get the app running on my computer, explaining each step as we go.
3. Write a README.md: the instructions for getting this app running,
   exactly as we just did it, written so that future-me on a new
   computer — or a different AI tool — could follow them without you.
   Keep it updated whenever the steps change.
4. Set up the save habit: from now on we commit after every working
   change, with a one-sentence note, and push to GitHub.
5. Tell me anything about this project that worries you. Don't fix it
   yet — we'll get to that.

Step 1 is the honest part of the move: the builder was doing invisible work — hosting, database, sign-in — and each piece needs a home. Expect that conversation to take longer than the export did. And if your app is small, ask Claude Code whether rebuilding it fresh would be cheaper than untangling the export; sometimes it is, and now rebuilding costs a weekend, not a cofounder.

Once it runs on your machine and saves to GitHub, you own the files, the history, and the judgment. Now give your new colleague the thing the builder never had: a memory.