The demo is always about getting in. The first app, the fast win, the dashboard your team built before lunch. What no demo shows you is the exit — and the exit is the part that decides whether this platform is a tool you use or a vendor you’re stuck with.
Here’s the uncomfortable truth: lock-in is settled long before the renewal conversation. It’s settled by architecture — where your data lives, in what format, on whose infrastructure — and those choices are made the day you sign, whether you ask about them or not. By the time leaving feels urgent, the answers are fixed.
So ask early. These five questions cut straight to it. They work on any low-code or no-code platform, and the difference between a confident answer and a vague one tells you almost everything.
1. Can I export the schema — not just the records?
Almost every platform will let you download a CSV. That’s not the question. A CSV is a flat snapshot: it drops the relationships between your tables, the field types, the constraints — the structure that makes your data mean something. Hand that CSV to a new system and someone rebuilds the model by hand.
A weak answer: “Yes, you can export to CSV/Excel anytime.” A strong answer: “Your data is a real database; you can take the whole thing — tables, keys, types, and all.”
If the structure can’t leave, you don’t own your model. You own a photocopy of it.
2. Can my own developers query the data directly?
There’s a tell that separates platforms that hold your data from platforms that host it: can a developer on your team connect to the actual database and run a query, today, without going through the vendor’s API or UI?
If the only way to reach your own data is the runtime the vendor controls, then every report, integration, and one-off analysis is gated by their roadmap and their rate limits. You own the records on paper, but you can’t run anything against them without permission.
A weak answer: “Everything’s available through our API.” A strong answer: “Connect with any standard database client and query it directly.”
3. Where do my files live — and can I take them too?
This is the question most checklists forget, and it’s where “we own our data” quietly falls apart. Your records might be portable while your files — the contracts, receipts, scanned documents, attachments — sit in a storage bucket you can’t see, referenced by IDs that mean nothing outside the platform.
Data and files are two different stores, and you need both to walk away whole. Ask plainly: where are the uploaded files, are they in a format and a location you can copy, and do the references still resolve once you’ve moved everything?
A weak answer: “Files are managed for you.” A strong answer: “Files are in a directory (or a bucket) you control, referenced by simple relative paths — copy it alongside the database and everything still points where it should.”
4. Can I self-host, on infrastructure I control?
Self-hosting isn’t only about cost or compliance — though it’s about both. It’s the ultimate answer to “whose computer is my business running on?” If the platform can only run on the vendor’s cloud, then your continuity depends on their uptime, their pricing, and their continued existence, forever.
Watch for the tiering trap, too: self-hosting or data isolation offered only on the plan above the one you’re on. And ask whether your data is genuinely isolated — your own database — or pooled into a shared multi-tenant store that’s far harder to extract cleanly.
A weak answer: “We’re fully managed cloud” (full stop). A strong answer: “Cloud or self-hosted, your choice — and either way your instance is isolated and yours to back up.”
5. What survives if the vendor disappears tomorrow?
The bluntest test, and the most clarifying. Imagine the company is acquired, pivots, raises prices 4x, or simply shuts down. What do you still have?
If the answer is “a data export and a rebuild project,” you were renting. If the answer is “a standard database and file store I can run on my own infrastructure, with developers who can pick it up,” you were owning — you just chose to let someone else operate it for a while. That’s the difference between a dependency and a tool.
A weak answer: “That won’t happen” (not an answer). A strong answer: “You’d still have your database, your files, and the freedom to host or migrate them — nothing of yours depends on us still being here.”
Scoring it
You don’t need five perfect answers. Some trade-offs are reasonable — a fully managed platform you never intend to leave can be exactly right. The point is to know what you’re trading before you commit, not to discover it during a renewal.
But if a vendor can’t give a clean, confident answer to most of these — especially the schema, the files, and the “what if you disappear” — then what you’re buying isn’t software you own. It’s access to software, on terms that can change.
This is the bar dForge was built to clear: your app is a standard PostgreSQL database, your files sit in a store you control, you can self-host, and there’s nothing to “export” because it was never trapped. We wrote about exactly where that line sits — and, honestly, where it doesn’t — in Only You Own Your Data, and it runs through how the whole platform is built.
Ask the five questions of any platform you’re considering. The good ones won’t flinch.
