stack.json you own and review — one plan, one deploy, one meter, instead of a builder plus a backend plus a host Stay where you are — until someone has to own it.
If a prompt-built app does everything you need, keep it. AI can write and deploy software, but the moment someone is responsible for how it runs, scales, costs, and evolves, that someone needs more than a prompt box — they need the levers. That is the moment the switch pays off.
Stay on Lovable / Bolt if…
- the app is a landing page, prototype, or internal demo with a short shelf life
- forms, CRUD, and a managed database cover the whole product
- nobody is answerable for production — uptime, cost, scaling, security — beyond what the builder provides
- nobody needs to inspect, change, or run the backend outside the builder
- you are still validating whether anyone wants this at all
Move to KERNSTACK when…
- you — not the builder — are responsible for how it runs in production, and you need to see, review, and change the system, not just re-prompt it
- you want to choose the intelligence — a specific model for cost, capability, or data-residency reasons (e.g. a European model), in the harness your team already uses
- a process has to keep running — a worker, a queue consumer, your own server — not just answer a request
- something has to happen on a schedule, on a data change, or over a websocket
- you need search or a model on your own data — full-text, vectors, or a trained predictor served next to the tables it learned from
- your backend is not JavaScript — or should not have to be: Go, Node.js, Python, and PHP run as workers
- a client has to see and comment on living previews — without a console login or a cloud key
- data has to stay in Europe, under your control — up to running the same stack on your own hardware
Lovable abstracts away the developer. KERNSTACK empowers the developer.
Both start with AI building the software. They differ in who the system is designed for once the software matters — and in who can answer for it afterwards.
No developer required — by design.
The builder chooses the architecture, the backend, and the hosting, and hides them behind a prompt. That abstraction is the product: it is exactly right while nobody on your side needs to inspect, change, or operate what is underneath.
AI speed, engineering control.
KERNSTACK brings the speed of AI-powered app development to professional software engineering. Your agent works on real code in your git repo — with the harness and the model you selected, not the one a builder vendor picked for you; the whole system is declared in one stack.json; every change is planned, diffed, and approved by an engineer before it ships. AI builds. Engineers own — and clients and partners collaborate around the result.
Same AI speed. Different owner.
All three get software live. They differ in what happens on day thirty — who can inspect it, change it, operate it, and answer for it when it runs, scales, and evolves.
| Dimension | Lovable | Bolt | KERNSTACK |
|---|---|---|---|
| The developer | Abstracted away — no developer required; the builder is the developer | Abstracted away — prompting in the browser replaces the development setup | Empowered — the engineer directs, reviews, and approves; AI does the building |
| Who builds | Their builder agent, in their editor | Their builder agent, in the browser | Your agent — Cursor, Claude Code, Codex, or the built-in @agent — working on real code in your repo, under your review |
| Agent harness & building model | No choice, by design — Lovable's own agent only; its control plane selects and swaps models behind the scenes. You cannot pick the building model or bring your own harness | Their agent, their tiers — Standard / Max (Bolt picks the underlying model); Forge adds selectable open models on eligible plans, still inside Bolt's own agent | Your harness, your model — chosen independently. Pair Cursor with Composer, OpenCode with Mistral, or run Claude, GPT, or Grok models through Claude Code, Codex, or the built-in @agent. Swap either side without migrating the stack |
| Who owns production | The builder's cloud, within the builder's standard path and limits | The builder's cloud, within token and hosting limits | You do — architecture declared in stack.json, every deploy planned and diffed first, separate dev / QA / production environments with their own keys and quotas |
| Backend | Managed cloud backend on a Supabase foundation; edge functions | Bolt Cloud database and server functions; JavaScript / Node.js only | Functions plus real workers — long-running containers in Go, Node.js, Python, PHP, with schedules, websockets, and change streams |
| AI in the product | AI features billed through workspace credits (in-app models — separate from the builder agent above) | No inference layer in the deployed stack — model choice stays builder-side | Catalog models, your own inference endpoints, and models trained as workers on your tables — deployed into the same stack |
| Your code | Yours — but moving the built-in backend to your own means rebuilding schema, auth, and functions by hand (their docs say so) | Exportable; the database can be claimed into your own Supabase project | A normal git repo from day one, hosted git included, whole system declared in one stack.json — existing codebases migrate in |
| Clients & partners | Workspace sharing | Team sharing | In the project conversation — board, Telegram, WhatsApp; @agent demos deploy to an isolated branch and environment, your main is never touched |
| Where it runs | Their cloud | Their cloud | Our own infrastructure in Europe, data stays in its zone — or on-premise on your hardware as a User Node |
| What you pay for | Build credits plus cloud usage | Tokens plus hosting limits | What actually runs — one credit balance across every service, scale-to-zero instead of idle infrastructure |
Your frontend stays. Your engineers take ownership.
A migration is not a rewrite, and it is not handing your product to another black box. The generated frontend is ordinary code; what changes is that everything behind it becomes declared, reviewable, and deployable from one file — architecture, infrastructure, and production your team controls directly. See the stack.json IaC reference.
Bring the repo
Export or sync your Lovable/Bolt project into a KERNSTACK project with hosted git. Your agent — or ours — inventories what the builder assembled: pages, functions, tables, storage, secrets.
Declare the stack
Each piece becomes a named resource in stack.json. kernstack plan shows the diff before anything goes live — no console archaeology, no hidden builder state. An engineer reviews and approves the system; the agent does not silently become its owner.
Run both, then switch
Deploy to an isolated KERNSTACK environment next to the running app, compare, then move the domain. Environments stay separate afterwards: dev, QA, production — each with its own keys and quotas.
-
Generated frontend →
apps[]React, Vue, Svelte, Next.js static export — your framework's build, published by the same deploy. Server-side rendering runs as a worker instead.
-
Edge / server functions →
functions+workersRequest handlers become functions. Anything that outlives a request — imports, media processing, integrations, your own HTTP server — becomes a worker in Go, Node.js, Python, or PHP.
-
Builder database →
tablesItems move into serverless tables with indexes and seed files in git. Table changes can trigger functions directly via change streams.
-
File storage →
bucketsObjects, direct browser uploads via presigned URLs, CDN routes, and frozen volumes that workers mount.
-
“Add AI later” →
search+inferenceFull-text and vector search over your tables and buckets, catalog models, your own endpoints, and training jobs that run as workers on the data already in the stack.
{
"stack": { "target": "shop.prod" },
"apps": [{ "name": "web", "out": "apps/web/dist" }],
"gateway": { "routes": [
{ "name": "www", "type": "prefix",
"default_key": "index.html", "cdn_enabled": true,
"target": { "kind": "bucket", "name": "www" } },
{ "name": "api", "type": "http",
"target": { "kind": "function", "name": "api" },
"domains": [{ "hostname": "shop.example" }] }
]},
"resources": {
"functions": [{ "name": "api", "schedules": [
{ "schedule_name": "nightly-sync",
"cron": "0 3 * * ? *" }] }],
"workers": [{ "name": "imports", "runtime": "python" }],
"tables": [{ "name": "orders", "key_name": "id",
"key_type": "string", "indexes": [],
"change_stream": { "function": "api" } }],
"buckets": [{ "name": "www" }, { "name": "uploads" }],
"search_indexes": [{ "name": "catalog",
"sources": [{ "type": "tables", "name": "orders",
"fields": ["items"] }] }]
}
} Migrated, not just generated.
In closed preview, six projects run on KERNSTACK — four of them for clients. Two existing client codebases were migrated onto the platform rather than rebuilt, and a first app in the app stores runs entirely on it. Three clients already follow their projects in Telegram conversations, where @agent previews land as links.
Keep the AI speed. Take engineering ownership.
The builder got you validated. KERNSTACK combines that AI-native development speed with engineering-grade infrastructure: background workers, schedules, search, your own models, and separated environments in the same repo — declared in stack.json, planned and diffed before every deploy, in the languages your team already uses.
Everyone collaborates. Engineers stay in charge.
Clients join the project conversation and board — no console, no keys. Ask @agent for the change; it builds on its own branch, deploys to its own environment, and answers with a living preview. The client approves the product; your engineers approve what ships to production.
Asked by everyone who switches
You do. That is the design. AI can write and deploy the software, but engineers remain responsible for how it runs, scales, and evolves — so KERNSTACK gives them the ownership to match: code in your git repo, architecture declared in stack.json, every change planned and diffed before it ships, and environments, keys, and quotas under your control. Lovable abstracts the developer away; KERNSTACK is built for the developer who stays.
No. The frontend is ordinary framework code and keeps its build. Backend logic and data are mapped onto declared resources — functions, workers, tables, buckets — so the system becomes visible in one stack.json instead of living inside the builder. Two client codebases have already made exactly this move.
Yes — that is the normal path. stack.json is readable by agents, the CLI previews every change with kernstack plan, and there are SDKs, agent-readable docs, and a Cursor plugin. Cursor, Claude Code, Codex, OpenCode, and the built-in @agent all work against the same stack — and you pick the model behind them, from Composer and Claude to GPT, Grok, or Mistral.
Your code lives in your git repo, and your infrastructure is a declared file rather than builder state — leaving means taking both with you. The same applies to intelligence: no single lab model or harness is baked into your stack, so a better, cheaper, or European-hosted model is a switch, not a migration.
A builder plan wins on sticker price while the app is small. KERNSTACK pricing starts from what runs: one credit balance across compute, storage, network, search, training, inference, and agent runs, with scale-to-zero instead of idle infrastructure — and no second and third platform bills behind the builder.
KERNSTACK is in closed preview. Migrations are a good first conversation: bring the repo, we map the stack together, and you see the plan diff before anything moves.
AI builds. Engineers own. Everyone collaborates.
Bring the repo. We will show you its stack.json — and the diff — before anything moves.