You built something real. It works, people use it, maybe it even makes money. But there's a quiet question that sits in the back of your mind: if the tool you built it on disappeared tomorrow, or tripled its price, or changed its terms, what would actually still be yours?
That question is worth taking seriously, and it's answerable. "Do I own my app?" feels like a vibe. It isn't. Ownership breaks down into five concrete layers you can check one at a time: your code, your data, your domain, your accounts, and your billing and terms. Some of yours might be locked up tight. Others might be sitting entirely inside a vendor's account with no export button. The point of this audit is to find out which is which, give yourself a score you can trust, and know what to fix first.
This is not a pitch to flee your platform. Plenty of no-code and AI-built apps run for years without incident, and rebuilding "properly" is rarely the right move for a solo builder who has a working product. The goal is smaller and more useful: understand exactly what you control, so a surprise can't strand you.
In Plain English: what "owning your app" actually means
Owning your app doesn't mean you have to host it yourself or understand every line of code. It means that if you had to, you could keep your business running without any single vendor's permission.
More precisely, ownership is the answer to one test, applied five times: if this specific thing went away, could I recover and rebuild elsewhere? For your customer data, that means having an export you can actually open. For your domain, it means the registrar account is in your name. For your code, it means you can at least get a copy of it, even if you can't fully read it yet.
Here's the part most people miss. These layers fail independently. You can fully own your data and not own your domain. You can own your domain and have your entire app running under a contractor's login. Owning one layer tells you almost nothing about the others, which is why a checklist beats a gut feeling every time.
A quick word on what this audit is not. Passing it does not guarantee you can migrate your app tomorrow, or that a vendor can never disrupt you, or that any contractual "you own your data" line will hold up in a dispute. It gets you from "I have a nagging feeling" to "I know precisely where my gaps are." That's the honest promise.
Layer 1 and 2: Code and data, can you get them, read them, and take them elsewhere?
Code and data are two different things, and people constantly conflate them. Your data is your customers, orders, content, and records: the stuff that took months of real-world activity to accumulate and could never be recreated. Your code is the logic and design of the app itself: usually recreatable, if painfully. Losing your data is often the bigger catastrophe, even though people worry more about code.
Owning your data
Start here, because for most solo builders this is the highest-value asset and the easiest to check.
Ask: can I export my data right now, in a format I can open somewhere else? A real export is a file (CSV, JSON, a database dump, a spreadsheet) that lands on your own computer and contains the actual records, not a screenshot or a report. If the only way to "get your data" is to look at it inside the platform's dashboard, you don't have your data. You have a view of it.
Test it for real. Don't assume the export button works the way you hope. Run it, download the file, open it, and check that the important fields are there and readable. Exports vary a lot between platforms in what they include and how complete they are, so verify against your own app rather than trusting a marketing claim.
If your export passes, do one more thing: schedule it. A data export you ran once eight months ago is a museum piece. For a deeper walkthrough of getting a clean, current copy, see how to export your data and code out of a no-code platform.
Owning your code
Code ownership is fuzzier on no-code and AI platforms, and that's expected. Grade it in three levels:
- Green: you can export the actual source code or project files and open them outside the platform. Common with AI code generators and some app builders that produce standard files.
- Yellow: you can't export runnable code, but you have a complete, current description of how the app works: your logic, workflows, screens, and rules, documented well enough that a competent developer could rebuild it. On many visual no-code platforms this is the realistic best case, and it's genuinely valuable.
- Red: the app's logic lives only inside the platform, you can't export it, and you have no written record of how it's built. If the platform vanished, so would the design.
Notice that Yellow is a perfectly reasonable place to be. You do not need to "just rebuild it properly" to be safe. A thorough export of your data plus a solid written spec of your app covers most of the real risk for a working product.
The single point of failure test
Now combine the two. Look at your app and ask: if this one vendor disappeared overnight, what could I still recover, and what is simply gone?
Write down the honest answer:
- My customer/order data: recoverable / gone
- My app's logic and design: recoverable / gone (or documented / not)
- My content, files, and images: recoverable / gone
If the answer to any of these is "gone," you've found a single point of failure. That's not a reason to panic, and it's usually not a reason to switch platforms. It's a reason to create a recovery path (an export, a backup, a written spec) so that vendor stops being a single point of failure. For a wider view of how these dependencies pile up, where your app's data actually lives is a useful companion read.
Layer 3: Domain, DNS, and email, the assets people forget until they're locked out
This is the layer that quietly strands people, because it feels like plumbing until the day it doesn't.
Your domain (yourbusiness.com) is one of the few things you can own outright and carry anywhere. But only if it's registered in an account you control. A common and painful pattern: an agency, a freelancer, or the app platform itself registered the domain "for you" inside their own account. It has your business name on the website, but the actual ownership record and the ability to move it sit with someone else.
What to check
- Registrar account. Log in to where the domain is registered (the registrar) using your own credentials, not a link someone sent you. Confirm the account is in your name, with your email, and that you can see the domain listed. If you can't log in yourself, you don't fully control the domain, regardless of what a contract says.
- Registrant contact. The domain's own contact/owner record should list you or your business, not an agency or platform. (Some of this is masked by privacy protection, which is fine; the point is who holds the account.)
- DNS control. DNS is the setting that points your domain at your app and your email. Confirm you can reach the DNS management screen and see the records. Whoever controls DNS can redirect your entire site and email, so this matters as much as the registration itself.
Why email deliverability rides on this
Your email (both the address customers see and whether your messages land in inboxes) depends on DNS records tied to your domain. If you don't control DNS, you can't reliably fix or move your email, and you can't set up the authentication records that keep your mail out of spam folders. If your domain and DNS live in someone else's account, your professional email is effectively borrowed too.
The fix here is usually straightforward and high-value: get the domain transferred into a registrar account you own, or at minimum get your own administrator login to the existing account. If a contractor set this up, ask them, in writing, to move ownership to you. This is a normal, reasonable request.
Layer 4: Accounts and access, whose login is the app really under?
Here's a scenario that catches careful people off guard. The data exports fine, the domain is yours, everything looks healthy, and then you realize the entire app is running under a login that belongs to a developer you hired last year, or a personal Gmail you set up in a hurry, or an account tied to a co-founder who has since left.
The account is the container everything else sits inside. If you lose access to it, you can lose access to all of it at once, no matter how well you scored on the other layers.
What to check
- Root account ownership. For every core service (your app builder, your database, your hosting, your domain, your payment processor, your email), identify the primary account holder. It should be an email address and login that you, the business owner, control today.
- The business email trap. Ideally your critical accounts are registered to a business email you own on your own domain, not a personal address and definitely not a contractor's address. If a freelancer's email is the recovery address on a core account, they hold a spare key to your business.
- Recovery paths. Check that password recovery and two-factor authentication for each account route to you: your phone, your email, your authenticator. A stunning number of "I got locked out" stories are really "the recovery method pointed at someone or something I no longer have access to."
- Access versus ownership. Being an admin or collaborator on an account is not the same as owning it. Collaborators can be removed by the owner. Make sure you're the owner on anything you can't afford to lose, and grant others access under your umbrella rather than the reverse.
If you're currently building under someone else's account, don't rip anything out in a panic. Plan a calm handover: create accounts you own, invite the right people as collaborators, and migrate ownership deliberately. The mistake to avoid is discovering this problem during an emergency instead of during a quiet audit like this one.
Layer 5: Billing and terms, the contract that can change your ownership overnight
The final layer is the one you can't fully control, and pretending otherwise would be dishonest. Your app runs on someone else's platform under someone else's terms, and those terms can change.
This section is educational, not legal advice. For anything that actually matters to your livelihood, verify the current terms in the vendor's own documentation and get a qualified professional to review anything you plan to rely on.
What to check
- Whose card is on file. The billing account should be under your name and payment method. If a contractor is paying for your infrastructure and invoicing you, a lapsed relationship can take your app offline. Bring billing in-house.
- What you're actually renting. Most of what you "own" on a platform, you're really licensing month to month. That's normal. The audit question is just: which parts stop working the moment you stop paying? Usually the app's live hosting stops, while your exported data and your domain remain yours. That gap is exactly why Layers 1 through 4 matter.
- Export rights and data ownership language. Vendor terms differ on who owns what and what you can take with you, and those terms change. Confirm ownership, export formats, fees, and termination effects in the current contract and technical documentation; then prove the export and restore path with your own test.
- Price and term changes. Assume prices and terms can change and that notice periods vary. Your protection isn't a promise from the vendor; it's the recovery path you built in the earlier layers. If your data and domain are portable, a bad terms change becomes a decision instead of a crisis.
For a structured look at how these dependencies compound, vendor lock-in, explained and scored breaks the concept down, and 7 ways solo builders accidentally lock themselves into a tool covers the specific habits that quietly deepen it.
When to bring in a professional: if you're evaluating a contract you'd stake the business on, if you handle customer payments or personal data, or if you're about to sign an enterprise agreement, have a qualified attorney review the actual terms. A checklist can flag the questions; it can't give you legal certainty.
Score yourself and triage: what to fix this week versus this quarter
Now turn the audit into a number. Grade each of the five layers green, yellow, or red.
| Layer | Green | Yellow | Red |
|---|---|---|---|
| 1. Code | Exportable source/project files | No code, but a solid written spec of how it works | Logic only inside the platform, undocumented |
| 2. Data | Tested export you can open, run regularly | Export exists but untested or rarely run | No real export; data only viewable in-app |
| 3. Domain & DNS | Registrar and DNS in an account you control | You have some access but not full ownership | Domain/DNS held by an agency or platform |
| 4. Accounts | Core accounts owned by you, recovery routes to you | Owned by you but recovery/2FA is messy | Core accounts under a contractor or personal account you can't rely on |
| 5. Billing & terms | Billing in your name, you know what's rented, terms reviewed | Billing yours but terms unread | Someone else pays; terms unknown |
Score it simply: green = 2, yellow = 1, red = 0. Add it up out of 10.
- 8 to 10: You genuinely control your app. Keep your exports current and re-run this audit a couple of times a year.
- 4 to 7: Solid foundation with real gaps. Work through the reds and yellows in priority order below.
- 0 to 3: You have a working app but thin ownership. Don't panic and don't tear anything down; start the triage and you'll climb quickly, because the first fixes are the cheapest.
Triage: what to fix first
Sequence matters. Fix the things that are cheap to fix and catastrophic to lose, before the things that are expensive to fix and merely annoying to lose.
This week (the emergency-proofing pass):
- Run and save a real data export. Highest value, lowest effort. Do it today and confirm the file opens.
- Confirm you can log in to your domain registrar yourself. If you can't, start the access/transfer request now; these take time.
- Check the root account owner and recovery method on your one most critical service. Make sure a lockout can't happen because recovery points at someone else.
This quarter (the durability pass):
- Bring domain, DNS, billing, and any contractor-held accounts under logins you own.
- Write or export a spec of how your app is built, so a Yellow code layer stays Yellow instead of quietly sliding to Red.
- Read the current terms for your main platform and note what stops working if you stop paying.
- Set a recurring reminder to re-export your data and re-run this scorecard.
Notice what's not on the list: switching platforms, rebuilding from scratch, or firing your contractor. Those are big decisions that this audit informs but rarely demands. Most builders who run this honestly find they're in better shape than they feared, with two or three concrete fixes standing between "borrowed" and "owned." If migration does turn out to be the right call later, how to migrate off a tool without downtime covers doing it calmly.
In Plain English
What this is: a five-layer audit (code, data, domain, accounts, billing) that turns "do I actually own my app?" into a score out of 10 and a short, ordered fix list.
Who it helps: a non-technical solo builder, founder, or indie hacker who already shipped something with AI or no-code tools and has a nagging feeling they don't fully control it.
When to use it: now as a baseline, again before any big change (adding payments, taking on customers' personal data, hiring or parting with a contractor, or considering a platform switch), and a couple of times a year as maintenance.
What to do next: run the audit, grade your five layers, and knock out the "this week" list, starting with a tested data export and confirming you can log in to your own domain registrar. If your score is low, that's information, not a verdict, and the first fixes are the easiest.
Where to go next
- How to Export Your Data and Code Out of a No-Code Platform for the hands-on version of Layers 1 and 2.
- 7 Ways Solo Builders Accidentally Lock Themselves Into a Tool for the habits that quietly weaken your score.
- Own Your Bubble App: Export, Back Up, and Plan an Exit if you're building on Bubble specifically.
- Vendor Lock-In, Explained (and How to Score Yours) to go deeper on the dependency question.
- How to Migrate Off a Tool Without Downtime for when a move is genuinely the right call.
You can also browse the Own Your Stack hub for the full set of ownership guides.
Ready to put a number on it? Run the free App ownership audit and the Lock-in scorecard to score your own app across all five layers, then work through your fixes in the order the audit gives you, at your own pace. No rush, no fear, just a clear picture of what's yours.
Some tool links on this site may be affiliate links, disclosed on our disclosure page. Tool details are based on documentation review, not hands-on testing, and can change; verify current features and terms in each vendor's official docs.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.