You wrote it with Cursor or Claude Code. Here's what it needs for production.
We take the app into your company's cloud account, where the platform adds what's missing, whatever the AI wrote: company sign-in, roles, keys out of the repository and deployment that doesn't run from a laptop. We also review every change, and you keep building with the same tool.
For whoever wrote the app in Cursor, Claude Code, Codex or Windsurf, and for the IT person who now has to deploy it.
Updated 22 October 2026
GitHub or another Git host. Code in a folder on a laptop we'll put into Git.
Zerops, or AWS on request. Registered to your company, not to us.
Claude Code, Cursor or Codex. A change goes live only after our review.
What does an app from Cursor or Claude Code still need for production?
The code itself is usually fine. What's missing is around it: whose accounts it runs on, where the keys are, who can sign in and who lets changes go live.
What's usually fine
- Regular code, say TypeScript or Python, on a common framework. The tools only wrote it, they don't run it.
- The code is in Git, often on GitHub, with its history.
- Dependencies are in files like
package.json, so the app builds elsewhere too. - The repository often has rules for the AI (
CLAUDE.md,AGENTS.md,.cursor/rules). We build on them.
What's usually missing
- Keys sit in a committed
.env, in the code, or in hosting settings on the author's personal account. - A secret key with a
NEXT_PUBLIC_orVITE_prefix ends up readable in the browser. - The app has a public address, and without sign-in that leads straight to the data.
- Sign-in is missing, a shared password or the app's own sign-up, so nobody closes access when someone leaves.
- The database runs on the author's account, say on Supabase, Neon or Railway, paid by their card.
- Deployment runs from a laptop or straight from main, with no review and no test environment.
- Nobody answers for errors, outages or the author leaving.
“Non-eng are using CC or Codex to build one-off internal tools, but they're deploying them on their personal Vercel accounts and sending the url over Slack.”
“After three full days, the site still isn't live.”
Try it yourself
Run this in the repository root. If it prints anything, an .env file has been in Git: treat its keys as exposed, even if you deleted it since. An .env.example without real values is fine.
git log --all --oneline -- '*.env*'How does the takeover work?
Screens and logic stay the same. Sign-in, permissions, keys and deployment move to the platform. How long it takes depends mostly on the data; the offer says exactly.
- 01
Scoping call
free · 30 minYou send a link to the repository and tell us who uses the app and where it runs. Within a few days you get an offer with the scope, timeline and price.
- 02
The repository moves to the company
you, in a few clicksYou transfer it from the author's personal account into your company's organisation; code from a laptop we put into Git. We don't need anyone's Cursor or Claude account.
- 03
We go through the code
part of the takeoverKeys in the code and Git history, sign-in, who sees which data, where data goes, the database and the build. We discuss the findings with you.
- 04
Small changes
part of the takeoverThe platform takes over sign-in, permissions, keys and deployment. Keys that passed through the repository are issued again. Screens and logic stay.
- 05
The data comes along
togetherThe database moves into your cloud account. With Supabase there are three options; for other databases we'll say the route after seeing the code.
- 06
Deployment into your account
one-offInto a cloud account registered to your company, on Zerops, or on AWS on request. No public address, separate test and production.
- 07
Switching off the old copy
from go-live · monthlyYou remove the deployment on the personal Vercel or Railway and delete the old database once the data has moved. Every later change goes live after our review, with a report.
What we look at in the repository
.env, .env.* What's in them, and whether they've been in Git history. package.json, requirements.txt What the app is built on and how. vercel.json, railway.json, Dockerfile Today's deployment. The platform replaces it. middleware, auth/ Sign-in. The platform takes it over. CLAUDE.md, AGENTS.md, .cursor/rules Rules for the AI. We add the platform's. Which apps do you take over?
Code that runs outside the tool it was made in, as apps from Cursor, Claude Code, Codex or Windsurf usually do. Apps from Bubble and similar builders we can't take over, but we can rebuild them.
Usually a yes
- A web app, say on Next.js or React with Vite, with its own backend.
- A backend and scripts, say in Node or Python.
- A database, say PostgreSQL or SQLite, on your account or a service like Supabase or Neon.
- Code from a freelancer or agency made the same way.
Examples, not a full list.
We'll tell you once we've seen the code
- Mobile or desktop apps.
- Apps that need a particular device at the company, such as a printer or a reader.
- Long-running background jobs or large volumes of data.
- Systems reachable only from inside the company network.
Not sure? Send us the repository.
We'll tell you whether a takeover makes sense and what it involves, or where the app would be better off.
Can I keep building with Claude Code or Cursor?
Yes, with the same tool and the same repository. Only the way into production changes: you push to Git, we review permissions and work with data, and the platform deploys with a report. New features get tried in the test environment.
Rules for the AI in the repository
We add an AGENTS.md or CLAUDE.md saying what the platform handles and what the AI leaves alone, typically sign-in and keys.
Your own AI
Always on your own plan, never on production data. We train nothing on your data and can advise on the provider.
What stays with you?
The repository
In your company's organisation. The code is yours.
The cloud account
Registered to your company, with the data and the domains. The platform in it is open source, and you can remove our access at any time.
The decisions
What the app does, who gets which role, and which change goes out when.
When isn't Fabrika for you?
- A public service for thousands of customers, with open sign-up and payments. Fabrika is for company apps.
- Your developers or IT can run the app and review changes. Then move it onto company accounts and turn on your host's access protection.
- One person uses the app and nothing important depends on it.
- Whoever builds needs to deploy on their own, without review.
- Your IT requires Azure, your own servers or SAML-only sign-in. Fabrika runs apps on Zerops, or on AWS on request, and connects company accounts through OIDC (for example Microsoft Entra ID, Google Workspace or Okta).
- You want the code checked once and will run it yourselves. A one-off audit is cheaper.
Wouldn't moving it to a company Vercel account do?
As a first step, yes: the company then owns the repository, hosting and database.
But each app still handles sign-in and roles on its own, keys are managed by whoever has access, and whatever is pushed goes live. Fabrika holds these in one place for all your apps, whoever wrote them, and on top of that someone reviews every change.
What people ask about apps from Cursor and Claude Code
Our .env file with the keys is in the repository. What now?
Treat those keys as exposed, even if you delete the file: it stays in Git history. During the takeover each service (database, payments, AI) issues new keys, which go into the cloud. There they can be written but never read back, and each app sees only its own.
The app runs on my personal Vercel and we share the link on Slack. Is that a problem?
Not while it's just you. Once colleagues depend on it, anyone with a forwarded link knows the address, the account and card are yours, and changes go out without review. On Fabrika the app has no public address and the only way in is company sign-in.
Deploying takes us days. Do we have to learn DevOps?
No. Deployment is built into the platform: a change goes from Git and, after our review, gets deployed. We set up the cloud account and platform once for all your apps.
I'm not a programmer, I just build with Claude Code. Can I handle it?
Yes. If you can develop the app today, you can after the takeover. We set up Git for you. Sign-in, access and keys are held by the platform, not by the code the AI writes, and if a change isn't right, we tell you what and why.
What do the takeover and running it cost?
You pay the cloud provider directly for the servers, by usage. The takeover is a one-off, sized mostly by where the data and sign-in live today, and then there's a monthly fee for operations and review per app, never per user or per hour. You get the figures in the offer after the scoping call. What an internal app costs.
Who picks the app up when the person who wrote it leaves?
A colleague, a developer or we carry on: the repository and cloud account are the company's, and we handle operations and review. Closing their company account ends their access. Who maintains the app.
A freelancer wrote our app in Cursor. Does this apply to us?
Yes, the takeover is the same. The freelancer can keep developing it; changes go through our review and your contract for operations is directly with us. When your developer or agency builds.
A colleague brought us the app and IT is supposed to deploy it. Where do we start?
With the scoping call, ideally with both of you. For IT we've written up what the platform handles and the answers to a typical security questionnaire: Security.
Send us a link to the repository.
Half an hour and access to the repository. We'll tell you what the takeover involves, what happens to the database and the keys, and whether it makes sense for you at all.