A backend builder takes a description of the data an application holds and who may touch it, and returns the back end: tables and relationships, sign-in, an API over the data, and the rules that decide which user may read or change which record. Some app builders generate this as part of the whole application. Others offer it on its own, as the back end for a front end you build yourself.
It is fast, and it is where the costs of this rung concentrate. A generated component can be replaced in an afternoon. A generated schema with a year of customer data in it cannot, and the access rules around it are the only thing standing between one user and another user's records.
What it is for
- A working back end for a prototype, so the front end has real data and real sign-in to talk to.
- Persistence and authentication for front-end and mobile developers who do not want to stand up a server.
- Exploring a data model. Describing the entities and seeing the tables is a fast way to find out what you had not thought about.
Who it suits
Front-end and mobile developers who can read a schema and want to skip the boilerplate. Founders whose app builder generated a back end they now need to understand. Anyone prepared to read every table and every rule the tool wrote before real data goes in.
It suits less well anyone who cannot yet read a schema or an access rule, because in this category the parts you cannot read are the parts that hurt.
How to tell this is your category
- You described entities, relationships and permissions in words, and got tables, policies and endpoints back.
- You can open the schema, but you did not write it, and there is no history of changes you wrote either.
- Your front end talks to the generated API, or straight to the database, and the generated rules are what keep users apart.
- If the tool also built the screens from the same description, you are using an AI app builder, and everything here still applies to its back end.
What it costs you later
The layer page covers the schema you did not design and the access rules nobody can explain. These are the costs that follow from them.
- Changes without a history. The first schema arrives whole. Every later change to a live database needs a migration: a recorded, repeatable step that moves the data from the old shape to the new one. If changes are made by regenerating the schema rather than by writing migrations, there is no record of how production reached its current shape, and no reliable way to build a second copy of it or step back from a bad change.
- Rules that read correctly and let too much through. An access rule is code, and it can look right and be wrong. The test is not reading it but trying it: sign in as one user and ask for another user's record by changing an identifier in the request. A flaw of that kind is in the logic rather than the configuration, so a scanner looking for known signatures passes it, the point AI is finding bugs faster than teams can fix them makes. Write that test for every table holding personal or financial data, and keep it in the suite.
- Business logic in the wrong place. Prices, totals, discounts and entitlements have to be computed where a user cannot change them. A generated front end that works out the total and sends it to the back end is trusting the browser with the price. Decide once where money arithmetic happens: on the server, in integer minor units, before the first order exists.
- Identity decided by default. Sign-in comes with choices: how long a session lasts, whether an email address must be confirmed, how a password is reset, and what happens to a user's data when they delete their account. The tool made each one, and each has consequences for security and for what you owe the people whose data you hold. Read them as decisions, and change the ones you would not have made.
- Data you cannot recreate. Code can be regenerated. Customer data cannot. Know where the data lives, how it is backed up, and whether you can export all of it in a form another system could read. Then restore a backup once, on purpose, before you need to.
- Clients tied to the generated shape. When the front end reads the generated API's exact shape, changing the schema means changing every client at the same time. A website can be redeployed in minutes. A mobile app already installed updates when its users let it, not when you do.
Before real data goes in
The window in which all of this is cheap closes the day the first real record is written.
- Read the schema. For each entity, ask whether it can happen more than once, because the answer decides whether it is a column or a table of its own.
- Settle money: integer minor units, with the arithmetic on the server.
- Write down, in one sentence each, who can read and change every table. Then test each sentence by trying to break it.
- Get the schema into files you can replay, and make every later change a migration.
- Restore a backup.
Designing a feature an AI coding agent cannot improvise works through the first two on a refund flow.