AI App Builders: What They Generate, and What They Leave to You

Every AI app builder is selling the same promise: skip the setup, get to the interesting part. That promise is mostly true, and it's worth understanding exactly how it's true — because the value is concentrated in a specific place, and so is the risk.

The honest framing is this: a generator is very good at the part of the project that is identical across every app, and it is necessarily silent about the part that is specific to yours. Knowing which is which is the difference between a tool that saves you two weeks and a tool that hands you a codebase you don't understand.

What Actually Gets Generated

The setup work in an AI SaaS is remarkably consistent. Every one of these apps needs:

Authentication — email/password plus OAuth, session management, a user table.
A database layer — an ORM, a schema, migrations.
Access control — roles, permissions, the question of who can use which model.
Provider management — API keys for OpenAI, Anthropic, and whatever else, stored encrypted rather than in a .env file someone will eventually commit.
A chat interface — streaming, conversation history, model selection.
A retrieval pipeline — document ingestion, chunking, embeddings, search.

None of that is interesting, all of it is necessary, and it's the same in every project. This is exactly the work a generator should do, and when it does it well, it's genuinely two weeks of your life back.

The interesting question is what the generator does with the seams — the places where its choices meet yours.

The Seam That Matters Most: Configuration vs. Code

There are two ways a generator can deliver a feature. It can install it as a dependency you call, or it can inline it as code you own.

The dependency approach is cleaner in theory and worse in practice for this kind of tool, for a specific reason: the moment you need to change the auth flow, or the retrieval strategy, or the provider fallback logic, you're either forking a package or working around it. The generated app is supposed to be yours, and a dependency you can't modify is a boundary you'll fight.

The inline approach — where the feature arrives as source files in your repo — means you can read it, change it, and delete it. The trade-off is that you now own it: no upstream fixes, no version bumps that solve your problems for you. But for scaffolding, that's usually the right trade, because the whole point is that you're going to modify it.

The question to ask of any generator: when I need to change how this feature works, do I edit code in my repo, or do I fight a package? If the answer is the second one, the time you saved at setup is time you'll spend later.

The Seam That Bites: The Feature Matrix

Generators offer feature selection, and feature selection implies that features are independent. They usually aren't.

The classic example is auth and RBAC. Auth gives you a user table and a session. RBAC gives you roles and permissions. But RBAC depends on auth — it extends the user model, it hooks into the session, it changes what the auth helper returns. A generator that lets you pick RBAC without auth has to either refuse, or silently install auth anyway, or generate something broken.

The same pattern shows up everywhere: a chat UI that needs a provider layer, an admin dashboard that needs roles, an audit log that needs something to audit. The dependencies are real, and a good generator makes them explicit — it tells you "this feature requires that one" rather than letting you build a combination that can't work.

When you evaluate a generator, look for how it handles this. Does it validate combinations? Does it tell you what it's adding implicitly? Or does it let you select anything and find out at runtime?

The Seam That's Invisible: The Defaults You Didn't Choose

Every generator makes decisions you didn't make, and the ones that hurt are the ones that are invisible until they matter.

A database default is the clearest case. A generator that defaults to SQLite for development is making a reasonable choice — no Docker, no setup, works immediately. But SQLite and PostgreSQL are not interchangeable, and the differences that matter (concurrency, types, full-text search, the exact SQL dialect) show up exactly when you move to production. If the generator doesn't make that boundary visible — "this is a development default, here's what changes for production" — you'll discover it at the worst possible time.

The same is true of the embedding model, the chunk size, the default model per provider, the session strategy. Each is a decision with consequences, and each is easy to accept without noticing. The good generators surface their defaults; the bad ones bury them.

What a Generator Should Never Do

Two things a generator should not do, and both are about honesty:

It should not hide its dependencies. If installing a feature pulls in a package, that should be visible. A generated project where you can't tell what's a dependency and what's your code is a project you can't reason about.

It should not pretend to be complete. The most useful thing a generator can tell you is where it stops. "This gives you auth, RBAC, and a chat UI; it does not give you billing, and here's why that's a separate problem" is more valuable than a feature list that implies everything is handled. The gaps are where your actual work is, and knowing them upfront is the difference between a plan and a surprise.

The Questions Worth Asking

Before committing to any AI app builder, these are the ones that actually predict whether you'll be happy with it:

Do I own the generated code, or do I depend on it? Can I edit the auth flow without forking?
How does it handle feature dependencies? Does it validate combinations, or let me build broken ones?
What are the defaults, and are they visible? Database, embedding model, session strategy — do I know what I got?
Where does it stop? What's explicitly out of scope, and is that stated or implied?
Can I read the whole thing? If the generated project is a black box, the time saved at setup is a debt you pay later.

Conclusion

An AI app builder is a good deal when it does the boring, identical work and hands you code you own. It's a bad deal when it hides its choices, pretends to be complete, or gives you a codebase you can't modify.

The setup work is real and worth automating. But the value isn't in the feature list — it's in whether the seams are honest. A generator that tells you exactly what it did, what it didn't do, and what you'll need to change is worth far more than one with a longer feature list and a shorter explanation.

Further reading: Next.js – Project Structure for the conventions most generators target; Prisma – Database Providers for why the SQLite-to-PostgreSQL boundary is not a config change.