Keep a copy you own, the app and its data¶

Verified: 2026-10-13

In developers' words: A private repository you own, a database export, off the platform

By the end of this level your app is under your own name on GitHub, checked, and one copy of its database sits on your own drive, where the platform cannot touch it.

TIME: 5 MINPROMPTS: 3 + 4CODE: 0

The moment

"A copy you own."¶

The platform is down. Or your account is frozen, or support has not answered in six days, and your app is in there. Everything you made in level 1 lives on their servers too, unless you did one more thing. And v1-works never held what your users wrote: going back to it brings back your app and leaves their data exactly where it was. That is how a year of work becomes something you ask permission to see.

Developers keep two copies the platform cannot take: the app in a private repository under their own name, and the database as an export, a backup, on their own drive. A world on your own drive outlives the console. This is also the one place your app is not like the game: a commit holds the world, never the database. Three sentences.

Why this matters

The platform's copy is the platform's¶

On their servers, under their account, at their price. Until the day it isn't. A frozen account, a price change, a company that closes: your app goes with it unless a copy lives somewhere they cannot reach.
A commit never holds the database. Every undo on this course brings back your app and leaves what your users wrote where it is. This is how people with GitHub connected still lose their data.
Support is not a backup. Six days without an answer is six days your app is not yours. A copy on your own drive answers in six seconds.
You can't avoid it. "Repository", "export", "backup": every platform's settings page has them, and every "we are shutting down" email ends with one. Better to find out now what the export leaves out than the week the platform is down.
Five minutes now, or everything later. After this, "is my app mine?" costs you one sentence, and the answer is yes.

The map

The level in one picture¶

1THE PLATFORM

their servers, their account

your app, as a folder
theirs, while it sits here
the database: what your users typed
no commit holds it

2PRIVATE REPOSITORY

your app on GitHub, under your own name

owner: you · private
every commit, v1-works too

3THE EXPORT

the database as a file, on your own drive

guest-book-2026-10-13.sql
every table, every row · off the platform

↺LOAD = GO BACK TO V1-WORKS

brings your app back from the repository.
It never reaches the database:
only the export brings that back.

Three boxes: the platform is 1, your private repository is 2, the export is 3. The yellow note is the limit.

Step 1

Check that the copy on GitHub is yours¶

This step checks what level 1 made: that the repository on GitHub is under your own name, private, and complete. If the owner is an organisation with the platform's name in it, the repository is theirs, not yours.

Prompt: Open the GitHub repository this project is connected to and tell me: whose account owns it, is it private, and does it have every commit and tag that exists here? If anything is missing, push it now.

✓ Your username as the owner, "private", and "nothing missing". The thing that matters is that you can open it on github.com, signed in as yourself, with the platform closed, and see the latest commit there.

Before
Your app as a folder on the platform's servers, under their account.
▼
After the prompt
The same app under your own name, private, every commit in it. Checked, not assumed.

Step 2

Export the database to a file, once¶

A commit never holds the database, so you export the database itself: what your users wrote, every table and every row, as one file. "Anything that is not in it" is the important answer: uploaded images, logins and secret keys often live somewhere else.

Prompt: Export everything in this app's database, every table and every row, to a file I can download and keep. Tell me where the file is, how big it is, and anything that is not in it.

✓ A file you can download, its size, and a sentence about what is not in it. The platform has its own export button? Use it too, then ask this anyway: the button's export and the full export are not always the same thing.

Before
What your users wrote lives on the platform's servers, and no commit holds it.
▼
After the prompt
The database as one dated export, and a list of what it leaves out.

Step 3

Move the file somewhere that isn't the platform¶

A backup kept on the platform goes down with it. This step moves the export off the platform, onto your own computer or your own cloud drive, and deletes the server copy once yours is safe. It holds your users' data, so the link must not be public.

Name the file with the tag and today's date, and keep it somewhere you already back up.

Prompt: Tell me where the export file is saved and whether that location is on this platform's servers. If it is, give me a download link so I can keep a copy off the platform, on my own computer, and delete the server copy once I say I have it.

✓ A download on your own computer, and nothing left on the server. Too big to download in one go? Ask for it one table at a time.

Before
The file is on the platform's servers. A backup that lives on the thing it backs up isn't one.
▼
After the prompt
The file is on your own drive, and the server copy is gone.

Keep that sentence. It is your export, and the one line on this page to remember: "export every table and every row to a file I keep, and tell me what is not in it".

Your turn

Go back to `v1-works`, and watch the database stay¶

See the one limit once, safely, on the preview from level 3. Nothing here touches your users. Four prompts, one at a time.

Prompt 1: Add one row to the preview's database by using its form, then show me the row.

Your row, with whatever you typed, in the preview's database.

Prompt 2: Go back to the save point v1-works on the preview.

The preview's app is back at v1-works. Nothing is said about the database.

Prompt 3: Is the row from a moment ago still in the preview's database?

Yes. It is. The reset came and went, and the database did not move.

Prompt 4: Export the preview's database to a file, and tell me whether that row is in the file.

Yes. The export holds it. That is the only thing on this course that does.

Prompt 1
One row, yours, in the preview's database.
▼
Prompt 2
Back at v1-works. The app is back; the database is not mentioned.
▼
Prompt 3
The row is still there. Going back never reached it.
▼
Prompt 4
The export holds the row. It is the only thing that does.

That is the limit, seen once. Next Tuesday, when the platform is down, you have your app under your own name and the database as of your last export, and you type "export every table and every row" the moment it comes back.

The limit

An export is as old as the day you made it¶

One limit. The export holds the database as it was when you made it, and nothing your users wrote since. Once is enough to know you can, and to know what the export leaves out. Exporting on a schedule is the next page of this habit, and the last page of the course says where that row is.

If it didn't work

Common problems¶

The owner is the platform's organisation.
Then the copy is theirs. Ask "create a private repository under my own account and push everything there, every commit and every tag", then send step 1's prompt again.
The platform connected GitHub for me.
The repository may be under your account but created by their app, which is fine. The thing to confirm is that you can open it on github.com while signed in as yourself, and that the latest commit is there.
The platform has its own export button.
Use it (where it is moves), then send step 2's prompt anyway: the button's export and the full export are not always the same thing. Compare what each one leaves out.
There is no way to download the data at all.
That is the finding, and the last page's row for it is for you. An app whose data cannot leave the platform is an app you rent.
The file is too big to download in one go.
Ask for it one table at a time. If the tool cannot give you a link, the platform's own export button from step 2 can.
The download link is public.
It holds your users' data. Download it, then ask "delete the server copy and make sure that link no longer works", and confirm by opening the link again.
The platform offers a "backup".
Ask where it is kept. A backup that lives on the platform goes down with the platform. Keep it, and keep your own copy off it as well.
On Lovable and Bolt.new.
Step 1 is their GitHub connection in the project's settings: open the repository on github.com yourself and check the owner. Step 2 is your database provider's export, usually Supabase, from its own dashboard. Not yet tested there.

The words

Each thing on this page, with its three names¶

In the game	Developers say	Plain
the world folder	`the project folder`	your app as a folder
your world on your own drive	`a private repository`	a copy you own, under your own name
a copy of the guest book	`an export, a backup`	the database as a file
your own drive	`an off-platform backup`	somewhere that isn't the platform
(no game word)	`code is versioned, data is not`	loading a save brings back your app, not its data

Next · The last page "You have an undo. Here's what undo doesn't fix." The one check on your own app, and the row on the map it leads to.

THE FRAME
Developers say	In the game	Plain
`the developer`	the player	YouYou give the orders and check the work. The controller never changes hands.
`the agent, the assistant`	the character you give orders to	Your AI tool: Lovable, Bolt, Cursor, Claude CodeFast and tireless, and it guesses what you meant. When it guesses wrong, level 4 is the way out.
`the project`	your world	Your app: the folder of files you are buildingNot the chat and not the editor. It can be saved, copied and moved, and every move in this course keeps it safe.
`the platform defaults, rollback`	autosave	The platform’s own undoIt saves when it wants, in one slot with no name, and writes over it. Fine until the day it isn’t.
`process, developers’ habits`	the strategy guide	The five habits in this courseWhat developers do so that losing work stops happening. One per level.

LEVEL 1 · A SAVE POINT
Developers say	In the game	Plain
`a repository, on GitHub`	your save files	A copy of your app on GitHub, under your own accountIt lives outside the platform, so nothing the platform does can write over it. Every commit goes here.
`a commit`	a save	A snapshot of your app: every file as it is at one moment, with a date and a messageThe tool gives each commit a short id like a1b2c3d. Level 2 keeps each one to a single change.
`a tag`	the save’s name	A name you put on a commit, like v1-worksMany commits say “working”. The tag is the one you ask for by name, and still recognise in three weeks.
`“go back to v1-works”`	load	Go back to a commit, by its tag“Go back to v1-works” puts every file back as it was then. It brings back the app, never the data.
`rollback`	autosave	The platform’s undo buttonIts autosave: one slot, no name, written over. Not a commit, and not yours.

LEVEL 2 · READ THE CHANGE
Developers say	In the game	Plain
`the plan`	the placement ghost	The list of files a change will touch, before anything changesAsk for it, read it, then say go. A file you never asked about is the one to ask “why?” about.
`small commits`	one block per save	One change per commitThen “which change broke it” has one answer, and one commit to take out.
`a diff, in plain words`		What changed since a commit, file by fileAsk for it in plain words, with the commit each file came in with. The file name tells you where to look.
`Login.tsx, SignUp.tsx`	a file in the world folder	One page or part of your app, as a fileUsually named after what it does: Login.tsx is the login. A file name on a plan or a diff is the clue.

LEVEL 3 · TRY IT ON A COPY
Developers say	In the game	Plain
`your users`	the guests	The people who use your appThey use what you built, get stuck, and leave if it is broken. Everything you try, you try in front of them, unless there is a preview.
`publishing, going live, deploying`	opening the gates	Sending a change to the live copyOnce it is published, your users see it. The preview comes first.
`a preview, a staging environment`	practice mode, the gates closed	A second copy of your app at its own address, where nothing countsBuilt from its own line of commits, with its own test database. Every change goes here before it is published.
`production`	the gates open	The live copy of your app, the one your users are inWhatever is published here is real. Nothing here is a test.
`an environment variable`	the copy’s world settings	A setting that says which database, email service or payment provider a copy of the app usesOne line like DATABASE_URL, set per copy. It decides where a form’s data went; the green tick does not.
`the database`	the guest book	Where your app keeps what your users typedTables of rows on the platform’s servers. A commit never holds it, so going back to v1-works never touches it.

LEVEL 4 · STOP AFTER TWO TRIES
Developers say	In the game	Plain
`an attempt`	one death	One fix: your order, and everything the AI changed in answerTwo that fail is the limit. The third is a fix of the fix.
`the error message, the stack trace`	the death message	The line the tool printed when it brokeThe closest thing you have to the cause. Read it before you try again.
`reset to the save point`	load the save	Go back to v1-works after two failed attemptsThe attempts were never committed, so they go. The original problem is still there, on its own, without the two new ones.
`/clear, a new chat`	a fresh run	A new chat that has not seen the two failed attemptsIt remembers nothing, so tell it: the commit you are at, the error message, the two attempts, and “don’t repeat those”.
`the loop`	the death loop	Try, try again, worse each timeEach attempt is built on the last broken one. The way out: stop, reset, new conversation.
`a bug report`	a guest’s complaint	A user’s “it broke”, in their wordsAn error message you did not see yourself. Read it the same way, then the same three moves.