Do You Actually Own Your App? A Founder's Guide to Source Code Ownership

Getting a code export is not the same as owning your product. Before you pick an AI app builder, no-code platform or agency, check what you'll really walk away with: the code, the infrastructure, the data and the knowledge to keep building.

Build with code you own — start free · Get a second opinion on your build

Why ownership is a buying decision

It feels abstract on day one. It becomes concrete when you need to raise money, hire an engineer, pass a security review, change vendors, or fix something the platform won't let you touch. Switching then can mean rebuilding.

Due diligence asks where the code lives and who can maintain it. "It's on a platform" is weaker than "it's in our repository, documented, and deployable by any competent team."

Five levels of ownership

Level 1 is the bottom of the ladder. Level 5 is the top. Most tools stop at levels 1–2.

Level 5. Continuity

Requirements, specs, architecture decisions, and runbooks travel with the code. A new team can see why it was built this way, not only what the files contain.

Level 4. Deployment

You control hosting, domains, environment variables, the database, and third-party accounts. The app runs without the vendor.

Level 3. Repository

The full codebase is in a Git repo you own, with real history, on a standard stack.

Level 2. Export

You can download code. It may be incomplete, tied to the vendor runtime, or unreadable.

Level 1. Access

You can use the app while you pay. The logic lives on the vendor platform. This is typical of no-code.

Real ownership is level 5. Code without the context of why it was built that way is a liability you own, not an asset.

What export actually gives you: a worked case

Lovable is the example because its documentation is public. Every statement below comes from Lovable's Git sync documentation, checked on 27 September 2026. The same page also covers GitLab and Bitbucket. None of this is a criticism of the tool. It is what "export" means in practice.

What you get. Two-way sync with a GitHub repository holding the project code. Commits you push to the synced branch appear back in Lovable.

What you don't get. Your database data (only the migration files that define its structure). Your secrets, which stay in Lovable. Deployment of backend changes: Lovable's docs say it does not deploy a changed Edge Function or run a new migration when your commits sync. Pushing commits updates the editor preview. It does not publish the live site.

What can go wrong. Rewriting the synced branch's history (force-push, rebase, or squash) can cause edits made only in Lovable to be lost. Code written outside Lovable may be modified by later Lovable requests unless you document constraints in Project Knowledge and keep tests. On a Lovable Cloud project, the .env in a local clone points at your live database, so records you create or delete locally change real data.

This is level 2–3 on the ladder (export and repository). Levels 4 and 5 (deployment and continuity) are yours to arrange, and the 10 questions tell you how. Every founder should know this before the pilot goes live.

Ten questions before you pay

Ask these before you pick a tool. If any answer is no, or it depends, that is the lock-in. Copy the list and write the answer next to each line.

10-question ownership checklist

Source code ownership checklist

Ask every vendor these before you sign or subscribe. If any answer is "no" or "it depends", that's where your lock-in is.

1. Is the full source code in a Git repository that I own, from day one?
2. Is it written in a mainstream stack that I can hire developers for?
3. Does the app run without your platform, runtime or proprietary libraries?
4. Who owns the hosting, database, domain and third-party accounts (payments, email, auth)?
5. Can I export all my data in a standard format, including user accounts?
6. What documentation comes with the code: requirements, architecture, environment setup, deployment?
7. Is there a test suite, and does it run in a pipeline I control?
8. Who owns the IP, contractually? Are there any licence restrictions on the generated code?
9. What happens to my app and data if I cancel, or if your company shuts down?
10. Could a new developer set it up locally and ship a change within a week?

What vague ownership costs

The bill shows up later, and it is rarely the subscription price. A rebuild when you outgrow the platform. A weaker negotiating position, because leaving means starting over. Harder fundraising and diligence, because you cannot show where the product lives. Slower hiring, because the next developer cannot run what you have. Compliance risk, if you cannot see where the data is stored.

Vibe coding is fine. Vibe owning is not.

Karpathy's original description of vibe coding, quoted by Simon Willison, is to give in to the vibes, forget the code exists, and paste errors back until it works. Willison's boundary is the useful one for founders: fine for low-stakes personal tools; not fine when other people depend on the software, security matters or money is on the line. A product with paying users is all three.

Addy Osmani on what separates AI-assisted engineering from vibe coding: a spec before implementation, review, tests and architectural ownership. A founder can't do the review personally, but they can insist that the spec, tests and runbooks exist and travel with the code. That is what level 5 means.

Ownership is not just the repo. It is the PRD, the scope and the decisions that explain why the code is the way it is. Code without that context is a liability you happen to hold the keys to.

What you actually walk away with

The rows below stay at the level you can check in a contract and a repository. They do not rank vendors against each other on features. No-code is the pattern behind Codalio vs Bubble. Prompt-to-app is the pattern behind Codalio vs Lovable.

Path	Where the code lives	Runs without the vendor	What travels with the code
No-code platforms	On the platform	Usually no	Visual config only
Prompt-to-app AI builders	Exportable or synced to Git, varies by tool	Often, with rework	Prompt history, rarely a spec
Traditional agency	Your repo, if the contract says so	Yes	Depends on the agency
Spec-first software factory (Codalio)	Your repository	Yes	PRD, technical spec and code, linked

Codalio Blueprint

If you already have a vibe-coded app, Codalio Blueprint is free and gives you the first three steps back to ownership: /code-to-prd rebuilds the spec from the code, /secure-coding reviews auth and data exposure, and /test-planning tells you which tests must exist before you ship. For the rest, the Vibe-Code Rescue path is how Codalio takes a prompt-built app to something maintainable: spec written down, code restructured, tests added, deployment moved to infrastructure you control. If you are starting fresh, Codalio builds spec-first from day one, in a repository you own, with the PRD, technical spec and code kept linked.

Paste this into your coding tool

Snippets 1, 2 and 5 work in any AI tool that can read the repo, including Lovable, Replit and Bolt chat for the plain prompts. Snippets 3 and 4 need Blueprint installed.

Snippet 1 — Ownership audit of an exported or vibe-coded repo (any AI tool with repo access).

Audit this repository for ownership and hand-off readiness. Answer each question with Yes / Partial / No and one line of evidence from the code:
1 Is there a README that lets a new developer run it locally in under an hour?
2 Are all required environment variables listed, with what each one is for (no values)?
3 Are deployment steps documented, and does the app run without the original platform's runtime?
4 Which third-party services does it depend on (auth, payments, email, database), and who owns each account?
5 Is there a test suite? Does it run? What does it cover?
6 Are database migrations present and do they match the schema the code expects?
7 Are there any secrets, tokens or live credentials committed to the repo?
8 Is there any documentation of what the product is supposed to do (PRD, spec, ADRs)?
9 What licence applies, and are there dependencies with licences I should know about?
10 Could you, right now, make a small change and ship it? What would stop you?
Finish with a prioritised to-do list to reach "another team could continue this".

Snippet 2 — Generate the hand-off pack.

Create a docs/handoff/ folder with: README-local-setup.md (run it locally), ENVIRONMENT.md (every env var, purpose, where it is set, no values), DEPLOY.md (how it gets to production, step by step), SERVICES.md (every third-party account, what it is for, who owns it), and DECISIONS.md (the main architectural choices and why, in ADR format). Where you cannot find the answer in the code, write TODO and the question I need to answer.

Snippet 3 — Rebuild the missing spec (Blueprint installed).

/code-to-prd
This app was built by prompting without a written spec. Reconstruct the PRD from the code: what it does, for whom, the workflows, the data model, and the features that exist but look unfinished or unused.

Snippet 4 — Security and data-exposure review before pilot (Blueprint installed).

/secure-coding
Review authentication, authorisation and data exposure in this codebase. Focus on: who can read or change another user's data, secrets in the repo or client bundle, and anything that talks to the production database from a development setting.

Snippet 5 — Memory-file rule (CLAUDE.md, AGENTS.md, .cursor/rules, Lovable Project Knowledge):

Project rule: never commit secrets or .env values. Every new environment variable must be added to docs/handoff/ENVIRONMENT.md in the same change. Every new third-party service must be added to docs/handoff/SERVICES.md. Every architectural choice gets an ADR in docs/adr/ before the code.

Frequently asked questions

Do I own the code generated by an AI app builder?

It depends on the tool's terms and technical setup. Check the IP clause and whether the code runs outside the vendor's platform. Owning the IP on paper doesn't help if the code can't run anywhere else.

Is exporting code the same as owning it?

No. An export can depend on the vendor's runtime, skip parts of the app, or be too tangled to maintain. Ownership means the code runs, deploys, and can be changed without the vendor.

Does ownership matter for an MVP?

Yes, if the MVP works. The MVP that gets traction becomes the product. Choosing a path you'd have to rebuild is a bet that it won't succeed.

What's a "vibe-code rescue"?

Taking an app built quickly with AI prompts and making it maintainable: a spec written from the existing app, then production-ready code you own in your repository. Codalio's vibe-code rescue starts with a free Code→PRD audit of the repo.

What documentation should come with my code?

At minimum the PRD, architecture and data model, environment setup, deployment steps, and a list of third-party accounts. Technical Scope Template.

Can I move off a no-code platform later?

Usually only by rebuilding, because the logic lives in the platform's configuration rather than in code. Plan for that before you start if you expect to scale.

Related

• AI App Builder with Source Code — how a build lands in a repository you control, with the spec attached.
• Codalio vs Bubble — a no-code platform compared with a repository you own.
• Codalio vs Lovable — a prompt-to-app builder compared with a spec linked to the code.
• Vibe-Code Rescue — turn a prompt-built app into a spec and production code you own.

Build in a repository you control

Every feature starts as a PRD, becomes a technical spec, then production-grade code in a repository you own. The decisions stay attached to the code.

Build with code you own — start free · Book a call about your current build