You Can Vibe-Code a Tiny App. Can You Own Its Data?

It took Rebecca Yu seven days to vibe-code her dining app.¹ A person with no engineering background described what she wanted in plain English, and working software came out. The build is no longer the hard part. The hard part is owning what the app writes after you ship it — and that question almost nobody asks first.

This is not a warning about vibe coding. It is genuinely useful, and the scale is real. Collins named "vibe coding" its Word of the Year for 2025.² One market estimate puts the category at $4.7 billion in 2026, growing 38% annually.³ A term that did not exist fifteen months ago now draws 110,000 monthly Google searches.⁴

The shift is here, and it is worth riding. Riding it well means asking one question before you build: where does the data your app creates actually live, and do you own it? Code lock-in is mostly behind us. The data the running app produces is not, and by default it lives somewhere you did not choose.

The belief: if I can build it, I control it

The intuitive assumption is that building your own app means owning it end to end. You wrote the prompt, the tool wrote the code, the app is yours — so the data must be yours too. That feels obviously true. For most of software history, the person who built the thing did control the thing.

The builders reinforce this. Vibe-coding tools increasingly let you export real source code to your own repository, wired to your own backend project. Code lock-in, the thing people feared most, is largely solving itself. If you can download standard files and run them anywhere, what is left to worry about?

Concede it: code export is mostly solved

Give the builders their due. The fear that defined the no-code era — that your work was trapped in a vendor's proprietary format — has largely been answered. Most current vibe-coding tools export standard, conventional code you can host anywhere, and several sync directly to a repository you own. Lock-in of the source is no longer the main risk.

The evidence is in the tools' own behavior. One major platform reports over 200,000 new projects created on it every day; another says 50 million people have used it; a popular AI editor counts 7 million total developers.⁵ At that volume, the platforms compete partly on portability.

One even documents an import path that moves a project out of a rival builder and into its own workspace.⁶ When tools advertise how easily you can leave, leaving is no longer the hard problem. The data the app generates while it runs is.

The catch: the app is a tenant, and so is its data

Two things are easy to conflate: the app's source code and the app's runtime data. Exporting the code is increasingly solved. The data your app writes while people use it — names, notes, orders, the actual content — is a separate asset, and it usually lives wherever the builder's default backend put it. That store is rented, not owned.

This matters because micro apps are built to be temporary. Professor Legand L. Burge III of Howard University told TechCrunch that these are apps "that are extremely context-specific, address niche needs," and then "disappear when the need is no longer present."⁷ A disappearing app is fine. A disappearing app that takes its only copy of your data with it is not.

The risk is not hypothetical. When journalist Reed Albergotti's source scanned 1,645 apps built on one popular vibe-coding platform, 170 of them "allowed anyone to access information about the site's users, including names, email addresses, financial information and secret API keys."⁸ The point is not that one tool is unsafe. The point is that the data your app holds is the asset, and by default it can sit in a store you neither chose nor reviewed.

Notice what the assumption smuggles in. You own the prompt, and you may own the exported code, so you assume you own the data too. But the data lives in a backend the tool provisioned for you, under terms you probably did not read, in a schema you did not design.

Owning the code that reads a database is not the same as owning the database. The first is yours the moment you export it. The second is yours only if you can get the records out, intact and complete, on your own.

The honest part: even the builders find the last 10% hard

Andrej Karpathy coined the term "vibe coding."² He also tried to deploy a real one. His verdict on shipping MenuGen, the app he vibe-coded, is the most honest line in the whole movement: "Vibe coding menugen was exhilarating and fun escapade as a local demo, but a bit of a painful slog as a deployed, real app."⁹

The reason is structural, and he names it. "Building a modern app is a bit like assembling IKEA future. There are all these services, docs, API keys, configurations, dev/prod deployments, team and security features, rate limits, pricing tiers..."¹⁰ The generated code is the easy 90%. The deployment, the data store, the keys, the question of where everything lives — that is the slog. And the slog is exactly where ownership is won or lost.

The argument: own the output, not just the source

The durable move is to treat your app's output as the thing to own, in a format that outlives the app. Source code you can regenerate. The data your app produced while it ran is the part no prompt can recover. Get it into plain, portable files you control, and the app becomes safely disposable.

Steph Ango, who runs Obsidian, put the principle in two sentences. "In the fullness of time, the files you create are more important than the tools you use to create them."¹¹ And: "Apps are ephemeral, but your files have a chance to last."¹¹ He was writing about notes, but the rule generalizes cleanly to anything a vibe-coded app generates. The app is the tool. The data is the file. Keep the file.

The instinct is the same one that says to keep your notes in plain text and to get your AI chat history out as files you keep. A vibe-coded app is just the newest tool that produces something worth keeping. The discipline does not change with the tool.

"Plain, portable" is doing real work in that sentence. A proprietary export that only the original tool can re-open is not ownership; it is a longer leash. The formats that outlast tools are the boring ones: Markdown, CSV, JSON, a SQLite file.

They open in a hundred programs, they read fine in a text editor, and they will still parse in a decade when the app that wrote them is a dead link. If your app's data can land in one of those, it is genuinely yours.

This reframes the export question entirely. "Can I export my code?" is increasingly answered for you. "Can I get every record this app created, in a format I can read without the app, stored somewhere I chose?" is the question still on you. That second question is worth asking before you build, not after the tool sunsets.

The practice: four questions to ask before you ship

Before you deploy a vibe-coded app — yours or one you depend on — answer four questions about its data. They take an afternoon, they cost nothing, and they decide whether a tool's shutdown is a shrug or a loss. Owning the app is easy now; owning its output is the part that still takes a deliberate choice.

1. Where does the runtime data physically live? Name the store. If you can't, you don't own it yet.
2. Can I export every record in an open format (Markdown, CSV, JSON, SQLite) without the app running?
3. Does that export include everything, or just what the app's UI happens to show?
4. If the tool shut down tomorrow, what would I still have? If the answer is "a screenshot," fix it now.

A vibe-coded app is worth building the moment it saves you an hour. It is worth trusting only once its output lands somewhere you'd still hold if the tool vanished. Those are two different thresholds, and most people only check the first.

Frequently Asked Questions

What happens to the data my vibe-coded app creates — do I own it?

The app's output is data, and by default it lives in whatever backend the builder wired up. You own it only if you can export every record in an open format, without the app running, to storage you chose. Treat the data as files to keep, not state inside a rented tool.

Who owns the code from a vibe-coding tool?

Increasingly, you do — many tools now export standard source code to your own repository. But code ownership and data ownership are separate questions. Verify the tool exports real, standard files, then verify where the runtime data the app generates actually lives. The second answer is the one that still varies.

Can I export my app, or is there lock-in?

Source-code lock-in is largely solved: most current builders export standard frontend code to your own repository and backend project. The unsettled part is the data the running app stores. Confirm you can pull every record in an open, app-independent format before you depend on the app for anything you can't afford to lose.

Is my data safe in a vibe-coded app?

Not automatically. A scan of 1,645 apps on one major platform found 170 exposing user data, including names, emails, financial information, and API keys.⁸ Generated apps can ship insecure defaults. Assume the data store needs your review, and keep an independent, exported copy of anything that matters.

Will the app I built still work if the tool shuts down?

Maybe not — micro apps are designed to "disappear when the need is no longer present."⁷ The app disappearing is fine; the data disappearing with it is not. The defense is an export you control: if the only copy of your records lives in the tool, the tool's shutdown is your data loss.

What is vibe coding?

Vibe coding, named Collins' Word of the Year for 2025, is using AI prompted in natural language to write code.² The term was coined by Andrej Karpathy.² It lets non-developers ship working software fast — and shifts the hard problem from writing code to owning what the resulting app produces.

The app you vibe-coded is a tool, and tools are meant to be disposable. The data it wrote is not — so keep it in plain files you could still open if every tool you used today were gone tomorrow.

This builds on Steph Ango's "file over app" principle.¹¹ To keep your app's output as open, local files you control, mnmnote.com lives in your browser — your notes stay on your own device, in plain Markdown you can take anywhere.