How to avoid vendor lock-in when building with an AI app builder

The question to ask before you start

The question that matters is not what a builder can create, but what you are left holding if you stop paying. Plenty of tools produce impressive results that exist only inside the tool. That is fine for a prototype and dangerous for a business.

Four questions separate the two cases.

1. Can you export, and what exactly comes out?

"Export" means very different things across tools. Some give you a proprietary project file that only reopens in the same product. Some give a static snapshot of the visual output with the logic stripped out. What you actually want is the complete, working source — the markup, the styling and the logic that makes it function.

2. What format is the exported code in?

This is the part people miss. Source code you cannot understand or maintain is barely better than no source code. A ZIP of standard HTML, plain JavaScript and CSS can be opened by any developer, in any editor, forever. A ZIP that requires a specific framework version, a proprietary build step or a runtime that only the vendor ships is lock-in wearing an export button.

3. Where can it run?

Test this concretely: can you take the export, put it on hosting you already pay for, and have it work? An app that only functions on the vendor's domain, or that breaks the moment it is served from anywhere else, is not portable no matter what the marketing page says. Being able to bind a custom domain matters for the same reason — your users should reach your brand, not a subdomain you do not control.

4. What happens to the data?

Code portability without data portability is half a solution. Ask where the database sits, whether you can connect your own, and whether you can export the records. A tool where the data lives in an account you cannot detach ties you to the platform even if the code is free to leave.

Applying the four questions to this platform

It would be cheap to write the questions above and then not answer them. So here is what a NorthernGo export actually is, including the parts that do not pass cleanly.

The Download ZIP action on a project card produces a Capacitor-shaped project: your entire app as www/index.html, a www/manifest.json, a minimal www/sw.js, a capacitor.config.json pointing at www, and a package.json whose only dependencies are @capacitor/core and @capacitor/cli.

On question two it does well, and for a structural reason rather than a stylistic one. Generated apps are deliberately monolithic: one HTML document containing the markup, the Tailwind classes and all the JavaScript in a plain <script> tag. No ES modules, no imports, no external local assets, no build step. That is a constraint in the generation rules, not a coincidence, and it means the file opens in any editor and renders by double-clicking it. There is no framework version to match and nothing to compile.

On question one, the honest caveat is that export is a paid feature. The Free plan has no source code export at all, so if code ownership is the reason you are here, the free tier is a trial rather than a home.

Where the export stops being self-contained

This is the part a page like this has an obligation to state plainly about its own platform.

The exported HTML still contains calls to the injected platform SDK — window.NorthernGoDB for data and login, window.NorthernGoAI for text, image and voice features, window.NorthernGo for e-mail and CSV or Word export, and window.NorthernGoShopify if the app is a shop. Those globals talk to the NorthernGo backend. Open the exported file on your own hosting and the layout, the styling and all the client-side logic work immediately; the data calls keep pointing back here until you replace them.

So the accurate claim is not "the export is fully independent". It is "the export is a complete, readable, standard-format copy of your application, whose backend calls are confined to four documented global objects". That is a meaningfully better position than a proprietary project file, and it is not the same thing as zero dependencies. Anyone telling you their export has zero dependencies while their app still has a login system is not being straight with you.

The offline behaviour does not travel either: the www/sw.js in the ZIP is a stub that passes requests through to the network, not the caching service worker used on hosted apps. That difference and what to do about it is covered in the offline and PWA guide.

How you would actually cut the cord

Because the app only ever calls those globals and never reimplements them — again, a rule in the generation prompts rather than a convention — replacing the backend is a bounded job. You rewrite the globals to point at your own service and leave the rest of the application untouched.

window.NorthernGoDB = {
  save: (collection, data) =>
    fetch(`/api/${collection}`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(data),
    }).then((r) => r.json()),

  get: (collection) => fetch(`/api/${collection}`).then((r) => r.json()),

  delete: (collection, field, value) =>
    fetch(`/api/${collection}?${field}=${encodeURIComponent(value)}`, { method: 'DELETE' }),
};

Keep the method names and the promise-returning shape and nothing in the app needs to know. That is the whole reason the four-methods-wide API is worth having: a narrow surface is a short migration.

Test the exit before you need it

The single most useful thing you can do about lock-in takes twenty minutes and almost nobody does it.

Export the project, unzip it, open www/index.html directly from the filesystem, and watch the browser console. What renders is what you own outright. What throws is your dependency list, itemised, for free. Do this once at the start of a project rather than during an emergency, and you will know exactly what leaving costs instead of guessing.

Repeat it after any significant change. An app that was portable in March can quietly acquire dependencies by June.

Data portability, concretely

The built-in database is a shared Supabase PostgreSQL instance reached through window.NorthernGoDB. There is no one-click database dump in the workspace, and pretending otherwise would be exactly the kind of claim this page exists to warn about.

What there is, is enough to get your data out without one. Inside your own app, window.NorthernGoDB.get(collection) returns the records and window.NorthernGo.exportCSV(records, 'export.csv') writes them to a file, so a hidden admin view with an export button is a ten-minute build. For a continuous copy rather than a snapshot, the Custom Database setting mirrors every write to an HTTP endpoint you own, as JSON — which is a mirror rather than a replacement, and the database guide explains why that distinction matters.

Hosting and the address itself

An app is not portable if its address is not yours. There are three ways to reach a published app here, and they rank cleanly.

A Pro custom domain is the portable option: the app is the whole site at an address you registered, so moving hosts later is a DNS change rather than a migration. A <subdomain>.northerngo.com address on Premium or Pro is fine for internal tools and staging and is not something you should print on a business card. The northerngo.com/?app=<projectId> fallback used by Free plan projects is the least portable of the three, because the domain, the path and the identifier are all ours.

If the app matters, bind your own domain with SSL early. It costs a CNAME record and it removes an entire category of future regret.

The mobile question

Because the ZIP is already shaped for Capacitor — webDir set to www, the Capacitor CLI in package.json — turning the export into native iOS and Android projects is npx cap add rather than a rewrite. Those projects then build in Xcode and Android Studio like any other app, which means the app store route does not depend on the platform continuing to exist. The Capacitor export guide walks through it.

How other builders answer the same four questions

The four questions are only useful if you actually ask them of everything you are considering, including tools that are better than this one at things this one does not do.

We keep side-by-side pages that work through exactly these questions rather than comparing feature counts. If you are weighing this against Lovable, Bolt.new or Bubble, start there — and read them with the same scepticism you should apply to this page, since we wrote both.

A reasonable standard

You should be able to download a complete working copy of your application, open it in any code editor, understand roughly what it does, host it somewhere else, and take your data with you. Anything less means the app is not really yours — you are renting it. That distinction rarely matters on day one and matters enormously the day pricing changes, priorities shift, or the product shuts down.