You wrote it with Cursor or Claude Code. Here's what it needs for production.
The code is usually already in Git. What's missing sits around it: sign-in with company accounts, roles, keys kept out of the repository, deployment that doesn't run from someone's laptop, and a second pair of eyes on every change. We add that by taking the app into your company's cloud account, and you keep building it with the same tool.
This page is for whoever wrote the app with AI in Cursor, Claude Code, Codex or Windsurf, and for the IT person who now has to deploy it.
Updated 28 September 2026
GitHub or another Git host. If the code only lives in a folder on a laptop, we'll put it into Git.
Cloudflare or Zerops, or AWS if you prefer. Registered to your company, not to us.
You keep building in 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?
Cursor, Claude Code and Codex write ordinary code into an ordinary repository. That's a good place to start. What's missing is usually not in the code but 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
- It's regular code, say TypeScript or Python, usually on a common framework. Cursor, Claude Code, Codex and Windsurf don't run the app, it was only written in them.
- The code tends to be in Git, often on GitHub, with its history.
- Dependencies are written down in files like
package.json, so the app can be built again somewhere else. - The repository often already has rules for the AI (
CLAUDE.md,AGENTS.md,.cursor/rules). We build on them.
What's usually missing
- Keys to the database, payments or AI sit in an
.envfile that made it into the repository, straight in the code, or in the hosting settings on the author's personal account. Nobody quite knows who has seen them. - A secret key with a
NEXT_PUBLIC_orVITE_prefix ends up in the browser, where anyone can read it. - The app has a public address. Whoever knows it gets at least to a sign-in screen, and if the app has no sign-in, straight to the data.
- Sign-in is missing, is one shared password, or is the app's own sign-up. It isn't tied to company accounts, so when someone leaves, nobody closes their access.
- Who may do what is handled by each app in its own way in the code, or not at all.
- The database runs on the author's personal account, say on Supabase, Neon or Railway, and their card pays for it.
- Deployment happens from a laptop or straight from the main branch, with no second pair of eyes.
- There's no separate test environment, so new features get tried on live data.
- Nobody is on the hook for running it: errors, outages, or what happens when the author leaves.
“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.”
“CC + Railway works until someone pastes a prod key into an env var.”
“After three full days, the site still isn't live.”
Try it yourself
Run this in the root of the repository. If it prints anything, an .env file has passed through Git at some point. Treat the keys in it as exposed, even if the file has since been deleted. An .env.example without real values is fine.
git log --all --oneline -- '*.env*'How does the takeover work?
The app stays the same app: same screens, same logic. What changes is who handles sign-in, permissions, keys and deployment, and where it runs. How long it takes depends mostly on the data; the offer says exactly.
- 01
Scoping call
You send us a link to the repository or show us the app, and tell us who uses it, where it runs today and where the data lives. Within a few days you get an offer with the scope, the timeline and the price.
free · 30 min - 02
The repository moves to the company
If the code sits on the author's personal account, you transfer it into your company's organisation, typically on GitHub. If it's only in a folder on a laptop, we set up the repository. We only need access to the repository, not to anyone's Cursor or Claude account.
you, in a few clicks - 03
We go through the code
Keys in the code and in the repository's history, sign-in, who sees which data, where the app sends data, what the database runs on and how the app gets built. We go through what we find with you.
part of the takeover - 04
Small changes
We adjust the app a little so the platform takes over sign-in, permissions, keys and deployment. Colleagues use their company account through Google, Microsoft or Okta, outside people a password. Roles are set in one place. Keys move into the cloud, and any that passed through the repository are issued again. Screens and logic stay as they are.
part of the takeover - 05
The data comes along
The database moves with the app into your cloud account. If the app runs on Supabase, we decide together whether to move elsewhere, run Supabase in your account, or leave it where it is. The three options in detail.
together - 06
Deployment into your account
We set up Fabrika in a cloud account registered to your company, on Cloudflare or Zerops, or on AWS if you prefer, and deploy the app. It has no public address; the only way in leads through the platform. Test and production environments are separate.
one-off - 07
Switching off the old copy
So that no second copy runs outside review, you remove the deployment on the personal Vercel, Railway or wherever it ran, and delete the database on the personal account once the data has moved. From then on every change goes live only after our review, and each version comes with a report of what we checked.
from go-live · monthly
What we look at in the repository
.env, .env.* What's in them, and whether they've ever been in Git history. .gitignore Whether files with keys are kept out of the repository. package.json, requirements.txt What the app is built on and how it gets built. vercel.json, railway.json, Dockerfile How it's deployed today. Platform deployment replaces this. middleware, auth/ Where sign-in is handled. The platform takes this part over. migrations/, prisma/, drizzle/ The database schema and how it changes. CLAUDE.md, AGENTS.md, .cursor/rules Rules for the AI. We add the platform's rules. Which apps do you take over?
Ordinary code that can run outside the tool it was made in. Apps from Cursor, Claude Code, Codex or Windsurf usually meet that condition, because these tools only write the code. They don't run it.
What we can't take over are apps clicked together in Bubble and similar builders, where the code never leaves the tool. Those can serve as a brief, and we build them again.
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 own account or with a service like Supabase or Neon.
- Code from a freelancer or an agency that was made the same way.
These are examples, not a list of what we support. What matters is whether the app can be built and run outside the tool.
We'll tell you once we've seen the code
- Mobile or desktop apps.
- Apps that need a particular computer or device at the company, such as a printer or a reader.
- Long-running background jobs or large volumes of data.
- Connections to systems that can only be reached from inside the company network.
Not sure? Send us the repository.
We'll look at it and tell you whether a takeover makes sense and what it involves. If the app would be better off somewhere else, we'll say so.
Can I keep building with Claude Code or Cursor?
Yes. After the takeover you keep building with the same tool, say Claude Code, Cursor or Codex, on your own computer and on the same repository. The only thing that changes is how a change gets into production.
Deploying from a laptop stops. You push the finished change to Git, we review it and the platform deploys it. New features get tried in the test environment, not on live data.
Rules for the AI in the repository
During the takeover we add rules for the AI to the repository, for example in an AGENTS.md or CLAUDE.md file: how the app fits together, what the platform handles, and what the AI leaves alone, typically sign-in and keys. Claude Code, Cursor and Codex can all read a file like that, so you don't have to explain it again every time.
Your own AI
The AI always runs on your own plan. It doesn't work with production data, and we don't train anything on your data. We're happy to 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. You can remove our access at any time.
The tool
Claude Code, Cursor, Codex or whatever you use. We don't need access to your account.
The decisions
What the app does, who gets which role, and which change goes out when.
How a change gets into production
- 01
You build
With the tool you know, on your computer.
- 02
The change goes to Git
With an author, a time and a description.
- 03
We review it
Permissions, work with data, anything that could open a door that should stay shut.
- 04
Deployment and report
The platform deploys it and you get a report of what we checked.
When isn't Fabrika for you?
We'd rather say it up front than at the end of a call.
- The app is a public service for thousands of customers, with payments and sign-up open to anyone on the internet. Fabrika is built for company apps used by your people and a few outsiders.
- You have your own developers or IT who can run the app, review changes and look after access. Then it's enough to move the repository, the database and the hosting onto company accounts and switch on access protection with your host.
- One person uses the app for themselves and nothing important depends on it.
- Whoever builds needs to deploy to production on their own, without review. On Fabrika every change goes through us.
- Your IT requires Azure or your own servers, or SAML-only sign-in. Fabrika runs on Cloudflare or Zerops, or on AWS by arrangement, and connects company accounts through OIDC (Google, Microsoft, Okta).
- You only want the code checked once and will run the app yourselves. Then a one-off audit is the cheaper route.
Wouldn't moving it to a company Vercel account do?
It's often a good first step: the repository, the hosting and the database belong to the company, not to one person. That takes care of a good part of what happens when the author leaves.
The rest stays as it was. Every app still handles sign-in and roles on its own, the keys are managed by whoever has access to the settings, and whatever someone pushes goes live. Fabrika holds these things in one place for all your apps, and 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, and anyone with access to the repository can see it. During the takeover the keys are issued again by each service (database, payments, AI) and the new values go into the cloud. Through the platform 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 much, as long as it's just you. Once colleagues' work depends on it, three things matter: anyone the link was forwarded to knows the address, the account and the card are yours so the app stands and falls with you, and changes go out without review. On Fabrika the app has no public address, and the only way in is through company sign-in.
Deploying takes us days. Do we have to learn DevOps?
No. Deployment is ready in the platform: a change goes from Git and, after our review, gets deployed. We set up the cloud account and the platform when Fabrika is set up, 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 too. We'll set up Git and show you how it works, the rules for the AI in the repository keep it away from what it shouldn't touch, and we go through every change before it's deployed. If something isn't right, we'll tell you what and why.
Our database is on Supabase, Neon or Railway. What happens to it?
The data comes with the app into your cloud account. With Supabase we decide together whether to move elsewhere, run Supabase in your account, or leave it where it is, because Supabase often holds sign-in and files as well as tables. For other databases we'll tell you the route once we've seen the code.
Does the AI have to see our production data?
No. The AI builds, it doesn't operate: it works on the code and the brief, not on production data. It runs on your own plan, and we don't train anything on your data. More for IT: Security.
What do the takeover and running it cost?
Three parts. You pay Cloudflare, Zerops or AWS directly for the servers, by actual usage. The takeover is a one-off, sized mostly by where and how the data and sign-in live today. Then there's a monthly fee for operations and review, based on the number of apps, 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?
The repository and the cloud account are in the company's name, and we handle operations and change review. A colleague, a developer or we can carry on with it. Access goes with the company account: once it's closed, that person can't sign in through the platform. 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 the app; changes just 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 on it. For IT we've written up what the platform handles, how a change gets into production and the answers to a typical security questionnaire: Security.
Send us a link to the repository.
Half an hour and access to the repository is enough. 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. If it doesn't, we'll say so plainly.