From Claude Prototype to Production App: 6 Governed Steps

After moving enough AI-made prototypes into production to know exactly where they break, I can tell you the build is the easy part. Here's how to go from Claude prototype to production app, step by step, without handing it back to engineering.

What you'll need before starting

You don't need an engineering team for this. You do need a few things in place:

• A working Claude Code prototype. It should run on your machine and do the core thing you built it for. Everything here assumes a build that already works and moves it forward from there; nothing in these steps repairs a prototype that's still broken.

• A Superblocks account. A free 14-day trial gets you Clark by Superblocks, import, and role-based permissions, which covers Steps 1, 2, 4, and 5.
  
  The security agents in Step 3, the SSO, in-your-cloud deployment, and audit logging in Step 6 run on the Enterprise plan (see Superblocks pricing). If you're taking an app all the way to production, book a demo and Superblocks will set you up.

• A list of what your app connects to. Know which systems it touches, whether that's your database, a tool like Salesforce or Slack, or an internal service.
  
  Set these up as integrations in Superblocks before you import. Clark uses them to rewire your app's connections as it comes across, and imports go smoother when they're already there.

• Whoever owns access at your company. For anything headed to production, loop in the person who handles logins and permissions. One short conversation now saves a mess later.

Time required: Plan for an afternoon. The import itself takes minutes. The bulk of your time goes into connecting your systems and setting who can see what.

How to take a Claude prototype to production, step by step

The path from Claude Code to production follows the same six moves. Each one closes a hole that a plain prototype leaves wide open. It gives the app the home, login, permissions, and safety review it never had, plus a way to maintain it once people depend on it.

Step 1: Get your Claude Code prototype ready to move

Before you move anything, get the app into a clean, working state on your machine. Run it one last time and click through the core flow, checking that the main job works end to end. Whatever state the prototype is in travels with it, so an app full of loose ends on your machine lands as an app full of loose ends in Superblocks. You can leave the edge cases rough, but a once-over on the core flow saves you cleanup later.

It also helps to have a context file, a plain-language record of the pages, data, and external services your app touches. If you kept one while building, you already have what you need; if you didn't, take five minutes to write one now, since it saves you from guessing the steps ahead.

Pro tip: When you're ready, Superblocks gives you an export prompt to paste into Claude Code. Before you zip the project, leave out node_modules, .git, and any dist or build folders. They're rebuilt on the other side, and they'll make the upload fail.

Step 2: Import your app into Superblocks

Import gets your app off your desktop. In Superblocks, click Import, follow the prompts to upload your app, and let Clark do the work (the full walkthrough lives in the Superblocks docs).

Your screens and the logic behind them come across, so you're not rebuilding from scratch. A handful of components land looking slightly different from how they did on your machine, and each one is editable as soon as the import finishes.

The import respects your standards too. If your company has already defined its design system rules, coding standards, and terminology in Organization Knowledge, Clark follows those on every app it builds.

Here's what Clark swaps out as it brings your app over:

This is the step Northflank and other deploy guides skip. They assume you already have clean, deploy-ready code. Import takes your prototype exactly as it is, something that works but was never meant to leave your laptop.

You can also do this without leaving Claude. Superblocks has a Builder MCP that connects the platform directly to Claude.

Once it's set up, you ask in plain language: "Import this app into Superblocks, connect it to our Postgres database, and send me the editor link." Clark asks clarifying questions in the same thread, builds, and sends back a link.

Publishing works the same way, and the same security checks run either way.

Pro tip: How much Clark asks of you scales with the app. A small one mostly imports itself, while an app wired into several systems prompts you for a few decisions as it works through each connection.

Step 3: Run a safety check before anything goes live

A prototype carries risks you can't see by looking at it. Superblocks catches them at the point where it counts, right when you try to publish.

When you hit publish, three things run automatically against the exact build that would ship. Static analysis looks for hardcoded passwords and keys, and for injection-prone code.

The other two go deeper. The Security Agent reads your whole app the way a security engineer would, following data across pages and APIs to catch what pattern-matching misses, like an endpoint with no permission check or an API that returns personal data it shouldn't.

Policy Agents add your company's own rules on top. They check the app against what your IT team wrote, like which systems are approved to store patient data.

You see the results in a publish readiness checklist. Anything marked blocking stops the deploy until it's resolved.

Clearing a finding takes only a few clicks, though the platform won't let you wave one through. For most findings, you click "Fix with Clark," Clark rewrites the code, and a fresh scan must pass before publish unblocks. Clark can't clear its own findings, so a working fix has to land first.

One detail worth knowing: the Security Agent itself runs on Claude, following Anthropic's open-source Claude Code security review approach.

This matters more with AI-built apps than with hand-written ones. The OWASP Top 10 for 2025 ranks broken access control as the number one risk in web apps and supply chain problems at number three.

Those are the exact risks a rushed prototype carries. AI writes fast, and it inherits them unless someone checks.

Pro tip: Treat whatever the checklist flags as a to-do list. Clearing it now beats explaining a leak later.

Step 4: Swap personal keys for proper connections

Your prototype probably connects to other tools using your own personal keys. That arrangement carries you through building on your laptop and quietly becomes a liability the moment real users depend on it.

Here, you replace those personal keys with proper business connections so that the app can access your systems on the company's terms. If you leave tomorrow, the app keeps working, and your personal access doesn't walk out the door with you.

Under the hood, this means token exchange, service accounts, or a secrets manager your company already runs, like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. You don't have to pick. IT sets up the connection once, and every app that needs it inherits the same one.

That single connection changes what the app is. It stops being yours alone and becomes a shared tool, wired to your actual database and Salesforce on connections IT has already signed off on.

Pro tip: Make a quick list of every outside tool your app touches. Walk the list one by one so nothing keeps running on a personal key by accident.

Step 5: Set who can see and do what

A working app with no permissions is a leak waiting to happen. Before you ship, decide who gets in and what each person can do.

You tie the app to your company's existing sign-in, so people log in the way they already do everywhere else. Then you set roles, so finance sees the full view, everyone else gets read-only, and an admin can edit. You draw these lines once, and they hold across the app.

Get this right, and you close the hole that turns a handy internal app into a compliance problem. You go from anyone with the link getting in to only the right people getting access.

Pro tip: Start strict. It's easier to open access up when someone asks than to claw it back after everyone already has it.

Step 6: Deploy your app to production

Now you ship, and your app finally gets a home. You deploy it properly, the way your team will use it day to day.

You pick where it runs. Most teams start on Superblocks Cloud, which Superblocks manages end to end. Regulated teams choose Hybrid or Cloud-Prem, where the platform runs inside your own AWS, GCP, or Azure account, and your data never leaves your network.

Every app is versioned by default so that you can roll back any change. If your company uses GitHub, GitLab, Bitbucket, or Azure DevOps, you can sync the app to your own repo and put changes through the same pull request review as everything else your engineers ship.

That record keeps paying off after launch. When you update the app later, you push the update through the same reviewed path rather than editing live and hoping.

That's the whole path. A Claude Code prototype that ran on one laptop is now a governed app your whole team can use. It has a home online, sits behind your company's sign-in, and records every change.

Pro tip: Ship the smallest working version to one team first. Watch them use it for a week, fix what trips them up, and then roll it out more widely. A half-finished tool in someone's hands teaches you more than another month of planning.

Why Claude Code prototypes stall before production

A Claude Code prototype does one job well. It proves the idea works, running once on your own machine. Production asks a different set of questions, and the prototype wasn't built to answer them.

Superblocks sorts those unanswered questions into five specific failures, and every one shows up whether you built the app with Claude Code, Cursor, or anything else:

• It has no home online. The app lives on your laptop and stops the second you close it, with no place to run where other people can reach it.
• Anyone with the link gets in. Your company's sign-in system doesn't know the app exists, so there's nothing between a stranger and the front door.
• Everyone sees everything. You can't give finance the full view while keeping everyone else read-only, because the app has no idea who's who.
• The AI's code went unreviewed. Nobody checked what it wrote, so passwords and keys can sit right there in the file, in plain sight.
• Nothing tracks the changes. With no history of what was edited, the next change is a guess, and the next person to touch it starts from zero.

This is the shadow AI problem, the new shadow IT. When business teams ship AI-built apps that IT can't see, the old risks return faster, leaving sensitive data with no record of what was built or who's using it.

The usual fix is to hand the prototype back to engineering. They rebuild the whole thing, which means a proper backend, a login tied to your company's accounts, permission rules, safe storage for passwords and keys, and a record of every change.

That rebuild runs into months of work for every app, by Superblocks' own plain reckoning, and a queue that long is where most prototypes quietly die before their turn ever comes. The six steps skip that rebuild entirely.

How to prototype in Claude Code so it survives production

A messy prototype becomes a messy production app. Four habits keep it clean enough to ship, and they're worth doing from your very first prompt:

• Give it a context file. Claude Code reads a file called CLAUDE.md before every prompt, so a good one is the single biggest thing you can do for quality. The team at thoughtbot leaned on theirs to keep the AI consistent across a two-week build.

• Work in small pieces. Building an entire feature in a single prompt is the fastest way to a tangled codebase, and the problem gets worse the bigger the app grows.
  After 100,000 lines, engineer Josh Anderson found that small work items survived, while big ones turned into hours of untangling.

• Ask for a plan before writing any code. Designer Abhi Chatterjee ends every handoff with one instruction: show me the folder structure before writing code.
  It's the cheapest review you'll ever run, since a bad call is one sentence to fix here and a thousand lines to unwind later.

• Review what it writes. The AI is fast and confident, and speed hides mistakes. GitHub's own research put 46% of the code in Copilot-enabled files down to the AI, so the reviewing habit isn't optional anymore.
  The thoughtbot team caught the AI writing tests that mock everything and test nothing, so a human reviewed every commit. You own the code, so you make the call.

Practiced from the first prompt, these four habits are what let a prototype arrive clean enough to move without a detour. Ignore them, and moving to production stops being a step and becomes a rescue project instead.

Common mistakes to avoid

Failed production attempts trace back to the same six avoidable errors. Watch for these:

• Shipping the prototype as-is. Treating "it works on my machine" as "it's ready" is how demos become liabilities. Until you've added login, permissions, and a safety review, a prototype becomes risky the day someone else opens it.

• Leaving personal keys in the app. Your prototype connects to other tools with your own keys, and it's easy to forget they're in there.
  Push that to production, and the app breaks the day you change your password, or worse, it hands your personal access to everyone who uses it. Swap every one for a managed business connection before you ship.

• Trusting the AI's code without reading it. Claude Code is fast, and speed hides mistakes. It will write a test that checks nothing, hardcode a secret, or switch a pattern halfway through a build.
  When close to half the code in a repo comes from AI, that's a lot of unread decisions, and each bad one becomes the new normal in the next round of AI work. Read what it writes.

• Building the whole thing in one giant prompt. Asking for a full feature at once may seem efficient, but it ends up in a tangle nobody can maintain. Big work items are where AI-built projects fall apart, so work in small pieces and commit often.

• Waiting until launch to think about who can see what. Permissions bolted on at the end are permissions done badly.
  Weak access control is the number one web app risk on the OWASP Top 10 for 2025, and it's the easiest one to design in from the start. Decide the roles before you deploy, while it's still easy.

• Treating it as a one-time build. A production app is something people will lean on for years. Decide who owns updates before you ship v1. An app with no owner rots the first time its builder moves on.

How Superblocks takes your Claude prototype to production

Everything in this guide comes down to one split. Claude Code is great at building the app. The work after that, the login, permissions, and deployment, is a separate job, and it's the part that usually sends a prototype back to engineering for months.

Superblocks handles that second job. You import the app you already built with Claude Code, and the platform covers what code generation doesn't:

• Your screens and logic come across intact. The import moves a working app forward instead of making you rebuild it.
• Automatic scans read the code for you. Exposed keys and vulnerable pieces get caught before they reach users.
• Personal keys become proper business connections. The swap happens through the tools your company has already approved, so nothing runs on your own access.
• Deployment lands inside your own cloud. The app runs on your network, behind a login and permissions tied to how your company already works, with a record of every change.

The result is an app teams use every day that IT can see. Two examples show what that looks like in production.

At one B2B healthcare company, a TPM with no engineering background built a prescription-processing queue that replaced a 20-person manual team and now handles a million prescriptions a year.

The pattern repeats in the public sector. At one NHS trust, a designer with no engineering background used Clark to build an HR platform that's replacing nearly 200 separate tools for 25,000 staff.

Both were built natively in Clark rather than imported, but they follow the same production model this guide sets up: governed apps a whole team relies on, with login, permissions, and a record of every change.

To see how the import and deployment work end-to-end, Superblocks walks through the whole prototype-to-production flow on their blog.

And if you'd rather test it on your own work, you can book a demo and bring your own prototype to try it.

Frequently asked questions

Is a Claude Code prototype safe to deploy straight to production?

No, a Claude Code prototype usually isn't safe to deploy straight to production. It ships with no login, no permissions, and unaudited code that can hide exposed keys, so it demos fine but can't safely handle live users.

Do I need an engineering team to take a Claude prototype to production?

No, you don't need a full engineering team. A platform that imports your app and handles the login, permissions, and deployment lets a single builder ship it without a rebuild, once someone has been named to own the production side going forward.

How long does it take to move a Claude Code app to production?

Moving a Claude Code app to production usually takes an afternoon. The import runs in minutes, and the rest of your time goes into connecting your systems and setting permissions. That connect-and-configure stretch is what grows when an app reaches into a dozen systems, which is why heavily integrated apps run past the afternoon.

Do I own the code Superblocks generates?

Yes, you own the code Superblocks generates. Clark writes standard React and TypeScript, and you can sync it to your own GitHub, GitLab, Bitbucket, or Azure DevOps repo and edit it there like any other codebase. No proprietary format holds it hostage, so you keep the app whether you stay on the platform or not.

What happens if a security check blocks my deploy?

If a security check blocks your deploy, the publish stops until the finding is resolved. Most findings come with a "Fix with Clark" option, where Clark rewrites the code, then a fresh scan has to pass before publish unblocks. Clark can't clear its own findings, so a real fix has to land before the app ships.

Can I import an app built in Claude Code, or only one built in Claude?

You can import both. Superblocks has separate import paths for a Claude Code repository and for a Claude app, plus a generic zip upload for code from Cursor, Windsurf, or your own editor.

Can I move my app to production without leaving Claude? 

Yes. The Superblocks Builder MCP connects Superblocks to Claude, so you can import, edit, and publish by asking in plain language, and get an editor link and a deployed link back. The same security and policy checks run whether you publish from Claude or the Superblocks editor.