Turning a Vibe-Coded MVP Into a SOC-2-Ready App

The email arrives on a Tuesday. The prospect you have been chasing for four months forwards their vendor security questionnaire. Somewhere around question thirty-one you find it. "Please attach your most recent SOC-2 Type II report." You search your Drive. You search your Notion. The answer is no, there is no such report, because three months ago your product was still a Figma screenshot and now it is a Lovable-scaffolded React app on top of a Supabase project you set up in an afternoon.

You google SOC-2. The first result quotes sixty thousand dollars and twelve months. The second sells you a consultant. The third is a Reddit thread where a founder says they spent a hundred and twenty thousand and would never do it again. You close the tab and tell your cofounder the deal is dead.

It is not dead. SOC-2 for a vibe-coded MVP is a real piece of work, but the numbers everyone quotes are from a different universe, and the version your prospect actually needs is probably smaller, cheaper, and faster than the version you are reading about. This article walks through what SOC-2 means, what it costs for a startup with one product and five customers, the specific technical gaps we find on almost every AI-built MVP when we take on a readiness engagement, and how to move from terrified to report-in-hand in under three months.

What SOC-2 Actually Is, Briefly

SOC-2 is not a certification. It is an attestation report issued by a licensed CPA firm, describing how your company handles customer data against a framework called the Trust Services Criteria. The framework has five categories. Security is mandatory. Availability, Processing Integrity, Confidentiality, and Privacy are optional additions to the scope. Almost every B2B SaaS startup starts with Security plus Availability plus Confidentiality, which lands at roughly sixty controls the auditor will want to see evidence for.

The single distinction that changes everything in this conversation is Type I versus Type II. A Type I report is a point-in-time snapshot. The auditor confirms, as of a specific date, that your controls are designed correctly and appear to be in place. It takes four to eight weeks. A Type II report covers an observation period, typically three to six months at minimum, during which the auditor tests that your controls actually operated effectively over time. Type II is what enterprise procurement teams really want. Type I is what almost every enterprise procurement team will accept to unblock a first deal, on the condition that you commit in writing to delivering Type II within roughly twelve months.

This distinction is load-bearing. If you do not understand it, you will quote yourself six months and forty thousand dollars when the actual ask is six weeks and twenty thousand. You will also sign an MSA promising a Type II report in ninety days, which is physically impossible, because the observation window alone is longer than that.

The Customer Probably Accepts Type I

When your enterprise prospect says "SOC-2" they are almost never insisting on Type II on day one. They are insisting on evidence that a serious security program exists. The three things that usually satisfy procurement on a first deal are, in order of strength: a completed Type I report, a signed engagement letter from an auditor confirming Type I work is in progress with a committed delivery date, or a thoroughly answered security questionnaire plus a written security overview document plus a public-facing trust page. The right move the day that questionnaire hits your inbox is to reply within twenty-four hours saying you are mid-way through Type I with a target date of whatever your target date is, and to attach a security overview and a signed NDA-gated trust summary. In almost every deal we have helped close this way, procurement has granted a conditional pass and moved on.

What you should not do is panic and promise Type II in thirty days. That is not a thing. When procurement pushes back, the correct pushback is to explain the difference. Most security reviewers on the other side already know it and will respect you for knowing it too.

The Automation Layer That Changed the Math

Five years ago, preparing for a SOC-2 audit meant spreadsheets, screenshots, and a compliance consultant living in your Slack for six months billing by the hour. Today there is a category of tools, of which Vanta, Drata, and Secureframe are the best known, that automates most of the evidence gathering. You connect your AWS or GCP account, your GitHub organization, your identity provider, your HRIS, your MDM, and the platform continuously pulls evidence and maps it to the Trust Services Criteria. You get a live dashboard showing which controls are passing and which are failing, template policies you can edit and sign inside the tool, and a single clean package you hand to the auditor when the time comes.

For a startup, this is the difference between a realistic weekend project across six weeks and an unrealistic fantasy. The tools cost somewhere between ten and twenty-five thousand dollars per year depending on vendor, company size, and how hard you negotiate. Newer entrants like Sprinto, Thoropass, Oneleet, and Delve sometimes bundle the auditor relationship and come in meaningfully cheaper. The specific choice matters less than the decision to use one. Do not try to do this on a Notion doc and a folder of screenshots. You will burn a hundred founder hours you do not have and the auditor will reject half of your evidence anyway because it is undated or unsigned or taken from the wrong system.

What It Really Costs

For a first-time Type I report at a startup with under fifty employees, the honest all-in number is fifteen to forty thousand dollars of cash out, plus roughly a hundred to two hundred founder-and-engineer hours. The breakdown looks roughly like this. The compliance automation platform runs ten to twenty thousand per year. The audit firm fee for Type I runs eight to fifteen thousand, with firms like Prescient, Johanson, A-LIGN, and a dozen other SMB-focused shops clustering in the ten-thousand range for a first audit. A third-party penetration test, which the auditor will require and which is also a reasonable thing to have on its own merits, runs five to ten thousand at the SMB tier. If you bring in a fractional compliance lead or a readiness partner, add five to fifteen thousand for their engagement.

Moving from Type I to Type II later adds another ten to twenty thousand for the Type II audit itself, with essentially zero additional remediation work if you have been running the platform continuously during the observation period. The whole thing, from deciding to start to holding a Type I report, runs six to twelve weeks in practice. Type II adds the observation window, so the full journey to a first Type II report is usually six to nine months from kickoff.

These numbers are not what the legacy compliance consulting firms will quote you. They are what the modern stack costs. The reason the legacy numbers still circulate is that most of the blog posts ranking for "SOC-2 cost" were written by those same consulting firms.

The Six Technical Gaps We Find on Every AI-Built MVP

When we take on a readiness engagement for a founder who shipped their first version through Lovable, Bolt, Cursor, or some combination of the three, the same six technical gaps show up almost every time. The specifics vary, but the pattern is consistent enough that we now use it as a checklist.

The first gap is audit logging. AI code generators do not scaffold application-level audit trails, because no one asks them to. Supabase has Postgres logs and Vercel has deployment logs, but neither is a human-readable record of who did what to which record inside your product. When a customer asks "who exported our data on March fourth" you have no way to answer. The fix is an append-only events table, written to on every meaningful action, capturing actor, action, resource, timestamp, and source IP. It is a two-day piece of work done properly, a week if you have a lot of writes to retrofit.

The second gap is encryption at rest, usually not because it is missing but because the founder cannot explain it. Supabase encrypts all tiers at rest with AES-256, but the documentation link is buried, nobody on the team has read it, and the SOC-2 policy document has a blank where the encryption statement should live. S3 buckets, if you are using them directly, often have SSE-S3 or SSE-KMS turned off because it has to be set explicitly. And for truly sensitive fields like tokens, government IDs, or protected health information, column-level or envelope encryption at the application layer is usually absent, which becomes a real problem if your scope ever touches the Confidentiality or Privacy criteria.

The third gap is backups and disaster recovery. Supabase Pro does daily backups with seven-day retention by default. You have almost certainly never tested a restore. There is no written document anywhere in your company that says what your backup frequency is, what your retention period is, what your recovery point objective and recovery time objective are, or how often you will test a restore. All of this needs to become a one-page policy, and the restore test needs to actually happen, on a quarterly cadence, with a screenshot showing it completed. First-time restore tests often surface genuine problems. That is the point of them.

The fourth gap is access reviews. Right now, who has admin on your Supabase project? Who has the production OpenAI API key? Who is an owner of your GitHub organization? If the answer to any of these requires you to go check, the contractor you offboarded four months ago probably still has access. SOC-2 wants a quarterly access review, documented, signed, with any exceptions remediated. The first one takes a day and usually removes four to ten stale grants.

The fifth gap is vendor and subprocessor review. A vibe-coded MVP is a mesh of third-party services. Supabase, Vercel, OpenAI, Anthropic, Stripe, Resend, PostHog, Sentry, Cloudflare, the list goes on. Every one of them is a subprocessor handling some slice of your customer data. SOC-2 wants an inventory, a risk rating per vendor, and evidence that you review the critical ones annually, which at minimum means downloading their SOC-2 reports and confirming there are no qualifications that affect you. Most founders have never seen any of these reports.

The sixth gap is incident response. If a former contractor's GitHub token is leaked tomorrow and someone pushes a malicious migration that exfiltrates your users table, what happens in the first hour? In the first day? Who calls customers? Who calls the lawyer? The answer on day zero of a readiness engagement is always "I don't know, we would figure it out." The fix is a two-page incident response plan, roles named, a simple severity matrix, a communication tree, and a tabletop exercise run once a year where the team walks through a realistic scenario. Auditors love tabletop exercise notes.

A bonus gap that often shows up alongside these six is the absence of change management in the code itself. The solo founder pushes directly to main from the Lovable deploy button. SOC-2 wants peer review of production changes and documented approval. Branch protection with required pull request reviews is the technical fix, and if you genuinely have no second person, a fractional CTO or a technical advisor can act as the reviewer for compliance purposes. It takes an hour to configure and changes the shape of your engineering practice in useful ways that go beyond the audit.

The Policy Layer

Beyond the technical work, SOC-2 wants fifteen to twenty written policies. Information Security, Access Control, Acceptable Use, Data Classification, Encryption, Incident Response, Business Continuity, Vendor Management, Change Management, SDLC, Risk Assessment, Data Retention, Password, Backup, Logging and Monitoring, and a few others depending on scope. This is the part that feels most intimidating and is actually the easiest. Vanta and Drata and Secureframe all ship template libraries that cover every one of these, pre-mapped to the criteria. Your job is to read each one, edit it so it describes what your company actually does rather than what the template imagines, sign it, and set it to auto-remind you to review it annually. A solid weekend with focus will get through the entire stack.

Do not copy-paste the templates without editing. Auditors read these, and a policy that says "the CISO will approve access requests" when you have no CISO and no access request process will get flagged. Write what is real. If what is real is thin, make it a little thicker, but keep it honest.

A Realistic Timeline

A first Type I engagement for a vibe-coded MVP, done correctly, runs six to ten weeks. Week one is scoping, auditor selection, and platform setup. Weeks two and three are the technical remediation sprint, where the audit log, encryption documentation, backup policy and restore test, access audit, vendor inventory, and incident response runbook all land. Weeks three and four are policy finalization and signing. Weeks four and five are evidence collection running in the background while the team continues to ship product. Weeks six through eight are the audit itself, with the auditor requesting evidence, the founder providing it through the platform, and the report being drafted and reviewed. Week ten, in a good engagement, is the Type I report landing in your inbox and being attached to the prospect's security questionnaire.

If your observation period for Type II starts the day the Type I controls are in place, you are roughly four to five months from the earliest possible Type II report date at that point. That is the answer to the "when do we get Type II" question on the customer call, and it is a good answer to have ready.

How WitsCode Runs the Readiness Sprint

When we take on a SOC-2 readiness engagement, we run a fixed four-to-six-week sprint designed to land everything except the audit itself, and to hand the audit-ready package to the CPA firm with confidence. The sprint has a technical track and a compliance track running in parallel. On the technical side, we build the audit log table and instrumentation, document the encryption posture across your data stores, write the backup policy and run the first restore test with the team watching, run the access audit and remove the stale grants, build the vendor inventory from your actual SaaS spend, and write the incident response runbook with a tabletop exercise scheduled. On the compliance side, we stand up your chosen automation platform, wire every connector, customize the policy templates to your reality, and introduce you to two or three auditor firms whose pricing and posture fit a startup of your size.

At the end of the sprint you have a platform showing green on sixty controls, signed policies, a scheduled auditor, and a technical baseline that will carry you through Type II without drama. We stay on retainer through the Type I audit to handle questions the auditor surfaces and to keep the evidence platform clean during the observation window.

The honest pitch is this. You can do all of this yourself. It will take you two to three months of calendar time during which your product will not ship much, you will burn a lot of focus, and you will second-guess the half of it you do not have clean intuitions for. Or you can hire a team that has done it a dozen times, ship the remediation in four weeks, and get back to the product while the paperwork runs on rails.

Either way, your prospect is waiting for an answer. The answer is not "we don't have SOC-2." The answer is "we are mid-Type I with a target date of June first, here is our security overview, and here is our completed questionnaire." That answer keeps the deal alive. Everything in this article is how you earn the right to say it.

-> Book a SOC-2 readiness assessment with WitsCode