The five problem areas common to all AI app builders →
Why does Bolt.new consume so many tokens?
Because before making a change the agent has to analyse large parts of the existing project — it is not only the prompt that costs, but the context behind it. With large, closely connected codebases that share grows with every file.
Token consumption is one of the most discussed topics around Bolt. Many users expect only their own input to count. In fact the agent reads the project context as well before it can carry out a change.
Typical cost drivers
- large codebase
- many files connected to each other
- long prompts
- repeated error fixing
- large refactorings
- unclear requirements
- repeated re-reading of the project context
Why debugging becomes expensive
A typical problem cycle looks like this:
- The agent carries out a change.
- An error appears.
- The agent analyses several files.
- The error is partly fixed.
- Another function breaks.
- The agent analyses the entire context again.
It is exactly these loops that drive consumption. Keep changes small and isolated — and before large refactorings, secure a stable intermediate state you can return to.
Bolt Database or Supabase?
The question is not a technical one but a strategic one: how much simplicity is how much long-term independence worth? The integrated option starts faster, the external one remains in place when the project leaves the platform.
Bolt Database is a fit when
- as little configuration as possible is wanted
- the project is meant to start quickly
- frontend and backend are meant to stay closely inside the platform
Supabase is a fit when
- external control over the database matters
- an existing Supabase project is being used
- auth and database are meant to run independently of Bolt
- long-term portability matters
The technically better database is not automatically the right one. What decides the matter is how important simplicity is against long-term independence — and that decision is best made before the first table, not after the fiftieth.
Why does Bolt not work with Supabase?
Usually because of configuration, not because of code: wrong environment variables, missing tables, column names that differ, row-level security blocking requests, or migrations that were not run in full.
Supabase is powerful, but it brings additional complexity with it. That complexity almost always shows at the transitions between the development and production environments.
Common sources of error
- wrong environment variables
- missing tables
- wrong column names
- row-level security blocks requests
- auth users and profile data are not linked correctly
- migrations were not run in full
- the development and production environments use different values
In the frontend, a database problem often looks like a UI error. Anyone searching there finds nothing — the cause usually lies in missing permissions or an inconsistent data structure.
Why does the deployment not work?
Because the preview runs under different conditions than the production environment: different variables, a different domain, different permissions. An app can look correct in the preview and still fail on deployment.
Typical causes
- missing environment variables
- build errors
- wrong API endpoints
- external services do not allow the production domain
- auth redirects still point to the development environment
- database access only works locally
Deployment checklist
- Production build
- Environment variables
- Auth redirect URLs
- Database access
- API keys
- Domain
- HTTPS
- Error logs
Can you leave Bolt and keep the code?
Via GitHub, yes — and that belongs at the start of the project, not at the end of it. An external repository is the precondition for an MVP being taken over by a development team later.
Code ownership is particularly relevant when an MVP is meant to turn into an application that is actually run. A repository outside the platform gives you:
- an external version history
- backups
- local development
- code reviews
- alternative hosting providers
- a simpler transition to developers
Bear in mind what does not move across with the code: database, auth configuration, secrets and hosting settings. Anyone who only secures the code has secured half the application.
We have described how the move from an AI-generated prototype to an application fit for daily operations works here: When no-code no longer holds.
What Bolt.new is well suited to
For projects where real code is meant to appear quickly and where code, preview and development environment sit closely together — more technical MVPs where the team wants to work on the code itself.
The biggest challenges arise as complexity grows. Five areas decide whether a Bolt project stays viable: token costs, debugging, database architecture, deployment and versioning. Anyone who structures them early can use Bolt far more efficiently.
What this means for companies in Germany
With Bolt.new, which questions have to be settled depends on one early decision: does the database sit inside the platform or in your own Supabase project? Data location, contractual position and the ability to export follow from that.
That decision is usually made out of technical convenience and still has the greater legal effect. With your own database project, location, access and export stay in your own hands; with the integrated option, both shift to the platform provider.
Data location
Where do the application, the database and the backups run — and was the region chosen deliberately? With an external database, where the application itself is hosted also has to be settled.
Data processing
An agreement under Article 28 GDPR is needed for every provider involved: platform, database service, hosting and the services the application itself brings in.
What to check
For personal data, a deletion policy, data subject rights and the record of processing activities. For data relevant to bookkeeping, retention, immutability and export in line with GoBD.
In practice it pays to answer the question before the first real row of data. A database can be moved in an hour at the beginning and, after six months in production, hardly at all without a migration project.
This section is descriptive. Which requirements apply to your company specifically, and whether they are met, is for your data protection officer to judge — not for this article.
Frequently asked questions
Why does Bolt.new consume so many tokens?
Because before every change the agent has to analyse large parts of the existing project. It is not only the prompt that counts, but the project context behind it — with large, closely connected codebases and in debugging loops that share grows sharply.
Bolt Database or Supabase — which is the right choice?
Bolt Database when as little configuration as possible is wanted and the project is meant to start quickly. Supabase when external control over the database, an existing project, running auth and database independently, or long-term portability matter.
Why does Bolt not work with Supabase?
Usually because of configuration rather than code: wrong environment variables, missing tables, column names that differ, row-level security blocking requests, auth users and profile data that are not linked, or migrations that were not run in full. In the frontend a database problem often looks like a UI error.
Why does the deployment in Bolt.new not work?
Because the preview runs under different conditions than the production environment. Typical causes are missing environment variables, build errors, wrong API endpoints, external services that do not allow the production domain, and auth redirects that still point to the development environment.
Can you leave Bolt and keep the code?
Yes, via a GitHub repository — sensibly from the start of the project. It gives you an external version history, backups, local development, code reviews and alternative hosting providers. The database, auth configuration, secrets and hosting settings do not move across with the code, however.
What has to be settled on data protection with Bolt.new?
First, whether the database sits inside the platform or in your own project — data location, contractual position and the ability to export follow from that. An agreement on data processing under Article 28 GDPR is needed for every provider involved. The assessment is for your data protection officer to make.