From Vibe-Coded Prototype to Governed Enterprise App

The Problem With Pure Vibe Coding

You shipped an MVP with Lovable, Bolt, Base44, or Cursor in two weeks. Impressive. Now:

• A potential enterprise customer asks for your architecture diagram. You have none.
• Your SOC 2 auditor asks which controls are built into the system. You do not know.
• A new developer joins and cannot figure out why the codebase is structured the way it is — there are no ADRs, no ARCHITECTURE.md, no decision trail.
• Every new feature takes longer because the mental model of the system lives only in your head.

This tutorial shows how to audit your vibe-coded prototype and use the audit output to generate a governed replacement — without throwing away what you built.

What "Graduated" Means

A graduated app has three properties a vibe-coded prototype typically lacks:

1. An explicit architecture model — a documented representation of the system's entities, relationships, capabilities, and constraints that exists independently of the code
2. Compliance by construction — security controls, access patterns, and audit trails that are structural properties of the code, not documentation added afterward
3. Owned code — code generated deterministically from your architecture model, so you know exactly where every file came from and can regenerate it when the model changes

Step 1: Extract Your Requirements From What You Actually Built

Do not start from what you intended to build. Start from what exists.

Open your vibe-coded app and document what it actually does in 200–400 words:

• What entities exist? (Users, Organisations, Products, Orders — whatever is in your DB)
• What does each entity's main table look like? (key columns, relationships)
• What workflows exist? (register → verify → login → create X → invite member → etc.)
• What auth mechanism is in use? (sessions, JWTs, OAuth?)
• What integrations exist? (Stripe, Twilio, SendGrid, etc.)
• What compliance obligations apply? (you process payment data? → PCI. You have EU users? → GDPR.)

This is your retrospective PRD. It does not need to be perfect. Archiet will ask clarifying questions during extraction if something is ambiguous.

Step 2: Run the Architecture Audit

Go to archiet.com/audit-my-architecture.

You can either:

• Paste the retrospective PRD you wrote in Step 1
• Upload your existing spec document if you have one (PDF, DOCX, or Markdown)
• Describe your system interactively through the wizard

The audit returns a scored report covering:

• Entity completeness — are all entities represented with correct relationships?
• Auth posture — httpOnly cookies or localStorage? JWT rotation? Password reset flow?
• Multi-tenancy enforcement — are queries tenant-scoped at the ORM layer or the application layer?
• Compliance gaps — what controls are missing for SOC 2, GDPR, HIPAA, or whatever overlays apply?
• Architectural drift — does the code reflect the stated architecture, or has it diverged?

A typical vibe-coded prototype scores 40–65/100. The audit report names specific gaps: "No organization_id foreign key on the Project entity — multi-tenancy is unenforced," or "Auth tokens stored in localStorage — SOC 2 CC6.1 breach."

Step 3: Export the Blueprint as CLAUDE.md

Once you have reviewed and corrected the extracted model in the Blueprint editor:

1. Click Export → CLAUDE.md system prompt
2. This file contains the full architectural context — entities, relationships, auth strategy, compliance overlays, naming conventions — formatted as a Claude/Cursor system prompt

Drop this file into your vibe-coded codebase root (or into Cursor's context window). From now on, every AI-assisted edit to your existing codebase is architecture-aware:

• Cursor's suggestions respect your multi-tenant organization_id pattern
• New entity suggestions follow your established naming conventions
• Auth-related suggestions use httpOnly cookies, not localStorage

This lets you align your existing codebase incrementally without a full rewrite.

Step 4: Generate the Governed Replacement (Optional Full Rewrite)

If the audit reveals that the existing codebase has fundamental structural problems (common with Lovable/Bolt apps at scale), generate a clean replacement:

1. In the Blueprint editor, click Generate
2. Choose the same stack as your existing app (or migrate stacks if you want to)
3. Download the ZIP

The generated codebase matches your audited architecture exactly. Migration path:

1. Deploy the generated app alongside the existing one
2. Run the generated migrations against a copy of your production database
3. Test with the canonical demo account
4. Switch over when tests pass

The generated app ships with a PROVENANCE.md that maps every file to its architecture model element — your auditor can trace any code back to a documented decision.

Step 5: Generate the Compliance Pack

In the Blueprint editor, click Compliance → select the overlays that apply:

• SOC 2 Starter: access control logging model, audit trail, and the SOC 2 controls section of your ARCHITECTURE.md
• GDPR: DPIA populated from your actual entity model (not a template — it references your specific data types and processing purposes)
• HIPAA: PHI boundary documentation and the BAA checklist

The compliance pack is not documentation added to the side. It is generated from the same architecture model as the code — so it describes the actual system, not a hypothetical one.

Common Pitfalls

"My app is too custom to generate" — If you have complex business logic, Archiet generates the infrastructure (auth, multi-tenancy, migrations, CRUD scaffolding, integrations) and you add the custom logic on top. The infrastructure is typically 60–70% of a production codebase.

"I will lose my existing data" — The generated app's migrations are designed to run against an existing schema. If the schemas differ (they will), the migration gap analysis in the Blueprint editor shows you the delta.

"The audit score is low and I am embarrassed" — Every vibe-coded app scores low on first audit. The score is not a judgement; it is a map. Use it.

---

The architecture documentation that the audit produces is not bureaucracy. It is the fastest way to explain your system to a new developer, pass an enterprise sales process, or onboard a consultant who needs to understand the system in a day.