How to Add a Real Backend and Database to an AI-Built App

You built an app with Bolt, Lovable, Cursor or v0. It looks right. The screens match your idea, the buttons work in the preview, and the demo wins the room. Then someone signs up, adds their own record, closes the tab, and comes back. The data is gone. Or two people log in and see the same account. That is the moment founders email us, and the problem is almost always the same. The AI tool built a front end only app with seeded data and never built the part that makes it real.

A front end only app is the screen without the engine. The AI wrote the pages and filled them with sample records so the demo looks alive, but there is no ai app backend database behind it holding real users, saving real work, or enforcing who can see what. This guide walks through adding that backend: the database, the API and the auth, while keeping the front end you already approved. That last point matters, because rebuilding the screens is where most of the money gets wasted.

What a front end only app is missing

A front end only app renders screens and sample data in the browser, with no server holding the real records. It is missing four things: a database that stores data for good, an API the screens can call, authentication that proves who a user is, and server-side handling of secrets. Until those exist, nothing a user does is actually saved.

The clearest symptom is seeded data, sometimes called mock or demo data. The AI hard-codes a few example records into the front end so the list page looks full. It is convincing in a demo and useless in production, because every visitor sees the same fixed rows and nothing they create survives a refresh. Getting real data, not seeded data, into the app is the heart of this job.

The second issue is structure. An AI build is often one bundle with no real separation between a front end and a backend, because there is no backend to separate from. It runs fine on your laptop and is unfit for a real server deployment. We go deeper on this in why AI-built apps break in production. The fix is not a patch. It is adding the missing half of the application.

The figure above is the order we follow on most rescues. You do not have to do all of it in one week, but you do have to do it in roughly this sequence, because each step leans on the one before.

Step one, model your data before you pick a tool

Data modelling means writing down what your app stores and how the pieces relate, before you choose any backend. List your core things, users, orders, posts, whatever your app is about. Then the fields each one holds and the links between them. A clear data model makes every later choice easier. A rushed one costs you a rebuild.

Most AI builds skip this because the tool invents a shape on the fly just to make the screen render. So start here. A customer has many orders. An order has many items. An item belongs to one product. Those relationships decide your tables and how you query them, and they are far cheaper to get right on paper than after real users have created data you cannot throw away.

This is also when you decide between a relational database and a document database. A relational database, like PostgreSQL, stores data in tables with strict relationships and is the safe default for anything with orders, payments or reporting. A document database, like Firestore, stores flexible records and suits fast-changing or loosely structured data. If you are unsure, pick relational. Most apps that handle money or accounts want it.

Choosing a backend, managed vs custom

You have two honest routes. A managed backend, such as Supabase or Firebase, gives you a database, an API and auth out of the box, so you ship in days. A custom backend, your own Node and PostgreSQL API, gives you full control of logic and data, at the cost of more time to build and to run. For a first real version, managed usually wins.

Managed backends do the heavy lifting for you. Supabase, for example, states that every project gets a full Postgres database, "not a Postgres abstraction", in its database overview docs. It also builds the API for you: Supabase says it "auto-generates an API directly from your database schema allowing you to connect to your database through a restful interface", described in its API docs. Firebase takes a different shape. Google describes Cloud Firestore as "a cloud-hosted, NoSQL database that your Apple, Android, and web apps can access directly using native SDKs", in the Firestore documentation. One gives you SQL with a generated REST API. The other gives you a NoSQL store your app talks to directly.

A custom backend means you write the API yourself, usually a Node service in front of a PostgreSQL database, and you host it. You decide every endpoint, every rule and every integration. This is the right call when your logic is genuinely complex, when you need to connect to systems a managed tool cannot reach, or when data ownership and control cannot be compromised. It is more work up front and more to maintain. For context, our own builds run on Flutter, Node and PostgreSQL, so we use both routes depending on the app.

The real supabase vs custom backend decision is not about which is better in the abstract. It is about where you are. If you are proving an idea and need real users soon, a managed backend removes weeks of work. If you already know the app has complex rules, heavy reporting or integrations a managed service will fight you on, a custom API saves you a painful move later. You can also start managed and switch to custom once the product has earned it.

Adding auth you can trust

Authentication proves a user is who they claim to be. Authorization decides what that user is allowed to do. An AI build usually fakes both, with a login screen that accepts anything, or a single shared account. Real auth means hashed passwords or social login, sessions or tokens, and rules that run on the server, not in the browser.

Managed backends include this layer. Supabase says its Auth product "makes it easy to implement authentication and authorization in your app" and that it "integrates with Supabase's database features, making it easy to use Row Level Security (RLS) for authorization", per its auth docs. Row Level Security is a database rule that decides which rows a given user can read or write, enforced by the database itself. That matters because the front end can always be tampered with. The database cannot be talked out of a rule. Firebase does the same job with Firebase Authentication and Security Rules. If you go custom, you build this layer yourself with a vetted library, and you test it hard.

Connecting your existing UI to real endpoints

This is where the front end you approved meets the new backend. You replace the seeded arrays in the screens with calls to real endpoints, an api for ai app that returns live data from the database. The screens stay. The data source changes. Done well, the app looks identical and finally remembers what users do.

In practice you find every place the UI reads or writes sample data and point it at the API instead. A list that mapped over a hard-coded array now fetches from an endpoint. A form that did nothing now posts to the server and gets a saved record back. You handle the states the demo never had: loading, empty and error. This is also when you add a database to my app in the literal sense, the save finally lands somewhere permanent.

The reason to keep the front end is money and trust. The design is approved, the layout is signed off, and your users or investors have already seen it. Rebuilding it from scratch throws that away and usually adds around 30 percent to the cost and timeline for no visible gain. Keeping it also signals you are serious about shipping the thing you promised. If you are weighing a full redo against this approach, we lay out the trade in rebuild or finish your AI-built app.

Tool-specific steps differ a little. Adding a bolt backend to a Bolt.new app follows this same shape, swap the preview data for real endpoints, but each tool packages its export differently, so the connection work is where you earn your time.

Moving secrets off the front end

Any key, token or password shipped in front end code is public, because a browser hands your code to every visitor who opens the page. AI builds routinely paste an API key straight into the client to make a call work. Moving secrets server-side means the key lives on your backend, and the browser asks the backend to act for it, never seeing the key.

When you add a real backend, this becomes natural. The front end calls your API. Your API holds the keys and talks to the database, the payment provider and any third party. Nothing sensitive reaches the browser. This is often the first thing we fix in a rescue, because it is the fastest security win available. Security goes well beyond this one step, and we cover the full checklist in how to secure an AI-built app.

Migrations, so the next change does not break you

A migration is a recorded, repeatable change to your database structure. Instead of editing tables by hand, you write the change as a script that can run on every copy of the database. This part is boring, and it is the difference between a hobby project and software you can safely change after launch.

When you move off seeded data, set up migrations from the first table. Your development database, your staging copy and production all get the same change in the same order. Without this, the three drift apart, and a deploy that worked yesterday corrupts data today. Managed backends give you tools for this. A custom stack uses a migration library. Either way, do not skip it.

When it is not worth adding a backend yet

Adding a real backend is not always the right next move. If your whole budget is only $1,000 to $2,000, it is usually not worth acting on, because a proper backend, auth and migration setup is real engineering a tiny budget cannot finish. You would spend all of it and still not have a shippable app. Be honest about the money before you start.

There are two other cases to pause on. First, if the idea itself is unproven and you only need to show a concept, the seeded front end may already do its job, so keep it as a demo and spend on validation, not engineering. Second, if the app's real value depends on strategy you have not settled, the features, the launch, the support, the day-to-day operations, remember that code does not make a business succeed. An AI tool writes code and gives no strategy. The backend is necessary, but it is not the whole job.

None of this means the AI tool failed. These tools are genuinely good at the early work, turning an idea into screens, exploring a design, and producing a front end to react to. That is real value. They just stop at the hard part, the architecture, the data, the security and the production hardening, which is the 20 percent that takes most of the skill.

Our take

After doing a lot of these, our rule is plain. Keep the front end, rebuild the architecture behind it. Model the data first, start with a managed backend unless you have a concrete reason not to, add real auth, replace seeded data with live endpoints, and get your secrets off the client. Set up migrations on day one so you can keep changing the app without fear.

If you want the whole sequence from here to a live product, our guide on how to launch an AI-built app is the pillar that ties every step together. And if you would rather hand the backend work to a team that does this every week, that is exactly what our AI app rescue service is for. We take an AI prototype and build the real backend, database and API underneath your approved front end. You can see how we finish and ship AI-built apps, and read our published pricing before you decide.

Frequently asked questions