Vibe-Coded MVP to Production: A Fractional CTO Case Study

A founder came to me with a problem I’m seeing more often:

He had already built the product. It had real users. But every new change was breaking something that worked before.

He didn’t need another consultant to produce a list of recommendations.

He needed someone to get into the product, understand what was happening, fix the most important problems, and help him continue building it in a better way.

That is where my work as a hands-on fractional CTO and software architect started.

This case study is published with permission. Names and identifying details have been changed.

The Product Was Already Working

Let’s call the founder John.

John is a psychotherapist with his own practice. He runs consultations, seminars, and professional training.

Existing video platforms didn’t support the workflow he wanted, so he built his own application using Claude Code and other AI development tools.

And he got surprisingly far.

The application supported video consultations, recording, transcription, scheduling, payments, and integrations with OpenAI, Google Calendar, Telegram, Todoist, Resend, and other services.

He was already using it for real consultations.

Now he wanted to make the platform available to other therapists.

But development had become painful.

“Any new change in the code breaks something somewhere else that used to work fine.”

He initially asked me to review the architecture and security and help prepare the application for multi-tenancy.

Once I got into the codebase, it became clear that an architecture review alone would not be enough.

What I Found

The technology choices themselves were reasonable:

• Vanilla JavaScript
• Supabase
• Netlify serverless functions
• PeerJS / WebRTC
• Canvas API
• more than ten external integrations

The problem was how everything had grown together.

The frontend was essentially one HTML file with more than 30,000 lines of code.

There were no clear modules or application boundaries.

State lived mostly in global variables.

Business logic was mixed directly with UI manipulation.

Supabase, localStorage, and sessionStorage were all being used to manage data.

There were no automated tests.

The application also had several security issues:

• API keys exposed in frontend code
• sensitive tokens stored in browser storage
• incomplete payment verification
• unsigned consultation access tokens
• shared-password authentication
• integration credentials stored in plain text
• almost no monitoring or useful logging

This explained why development had become unpredictable.

The product worked, but the founder had reached the point where adding features was becoming more dangerous than building them.

I Didn't Recommend a Rewrite

The easiest architectural recommendation would have been:

“We need to rewrite this.”

But that would have ignored the business reality.

John already had a working application.

He knew the product extremely well.

He was using it with real clients.

And most importantly, he wanted to continue developing it himself with AI.

So the goal wasn't to take the product away from him and spend months rebuilding it.

The goal was to make the existing product safer and give John a better engineering system for continuing to build it.

That required hands-on work.

First, We Refactored the Most Dangerous Parts

We started reducing the areas where small changes could affect the entire application.

Instead of trying to refactor 30,000 lines at once, we introduced boundaries incrementally.

We separated responsibilities around areas such as:

• authentication
• application state
• API communication
• video and recording
• external integrations
• session handling
• business logic

The goal wasn't architectural perfection.

It was predictability.

If John changed an integration, it should not unexpectedly break a consultation workflow somewhere else.

If he changed authentication, he needed to know which parts of the system were affected.

This also gave us natural places to start adding tests around business-critical functionality.

Then We Addressed Security

Before onboarding additional therapists, several security issues needed immediate attention.

We moved sensitive operations away from the client.

Secrets and credentials needed proper server-side handling.

Payment verification needed to happen in a trusted environment.

Access tokens needed proper signing and validation.

Authentication and authorization needed to support multiple independent users instead of assumptions built around a single operator.

At the same time, I started designing the multi-tenant architecture needed for the next stage of the product.

That included decisions around:

• tenant data isolation
• roles and permissions
• consultation ownership
• storage
• integrations
• configuration
• billing
• support access

The important part was doing this before more customers were added and the existing assumptions became much more expensive to change.

The AI Coding Workflow Was Part of the Architecture

There was another important part of this project.

John was going to continue writing code himself.

And he was going to continue using AI coding agents.

Telling him “don't use AI” would have solved nothing.

Instead, we needed to make the AI work inside the architecture rather than constantly inventing a new one.

So I helped configure his coding agents with project-specific instructions, skills, standards, and guardrails.

The objective was to give the AI much more context about how this particular application should be developed.

For example:

• where different types of logic should live
• how new modules should be structured
• how authentication and authorization should be handled
• how data access should work
• how integrations should be implemented
• how errors should be handled and logged
• what security rules must not be violated
• when tests should be added
• what existing patterns should be reused instead of creating new ones

Instead of every prompt effectively saying:

“Add this feature somehow.”

the coding agent now had a technical framework within which it was expected to operate.

That made a significant difference.

Giving AI Better Instructions Is Not Enough

Of course, an AGENTS.md, Claude skills, rules, or coding standards do not magically guarantee good software.

The underlying architecture still matters.

Someone still needs to make the difficult engineering decisions.

And generated code still needs review.

But once those decisions have been made, AI agents become much more useful when they have clear constraints.

For a founder who wants to remain hands-on, this is especially valuable.

The goal wasn't to make John dependent on me for every small feature.

It was the opposite.

I wanted him to be able to continue moving quickly without destroying the technical foundation every time he asked an AI agent to change something.

We Created a Development System, Not Just a Roadmap

By the end of the engagement, the outcome wasn't simply a technical audit.

We had worked on the product itself.

We had:

• identified and prioritized the biggest architecture risks
• refactored critical parts of the application
• addressed immediate security problems
• designed the direction for multi-tenancy
• established clearer boundaries inside the codebase
• introduced testing around critical flows
• improved error handling and production visibility
• documented development standards
• configured AI coding agents around those standards
• created guardrails for future AI-generated changes
• established a practical technical roadmap

Most importantly, John could continue developing his own product.

But now he was doing it on top of a much stronger foundation.

This Is What I Mean by a Hands-On Fractional CTO

For me, fractional CTO work isn't just joining calls and recommending technologies.

Sometimes the founder needs strategy.

Sometimes they need an architecture decision.

And sometimes the best way to solve a problem is to open the repository and work through it together.

In this project, my role moved between CTO, architect, and senior engineer.

I helped decide what mattered from a business perspective.

I designed how the product should evolve technically.

And I worked hands-on in the codebase to start making that transition real.

Just as importantly, I helped improve the development process around the founder so that future work — including AI-generated work — followed the same direction.

That is particularly important for small startups.

You don't always need a large engineering team.

But you do need someone who can establish the technical direction and make sure the code continues moving toward it.

The Result: The Founder Could Keep Building

The biggest result wasn't that the code suddenly became perfect.

It didn't need to.

The result was that John could keep moving forward.

He had a clearer architecture.

Critical risks were being addressed.

Multi-tenancy had a defined direction.

The codebase was becoming easier to change.

And his AI coding agents now had rules and context that helped them produce changes consistent with the product's architecture.

Instead of replacing the founder's way of working, we upgraded it.

That is often the right approach for AI-first startups.

The founder keeps the speed and flexibility that helped them build the MVP.

I add the technical experience, architecture, security, engineering standards, and guardrails needed for the product's next stage.

When This Kind of Help Makes Sense

If you've built a working MVP with Claude Code, Cursor, Codex, freelancers, or a small development team, you may eventually reach the same point.

The product works.

Customers are interested.

But you're starting to wonder:

• Is the architecture good enough?
• Is the application secure?
• Why does every change break something?
• How should we implement multi-tenancy?
• Should we refactor or rewrite?
• Are our AI coding agents producing maintainable code?
• What rules and architecture should we give them?
• How do we keep developing quickly without accumulating technical chaos?

This is exactly the stage where a hands-on fractional CTO or software architect can help.

Not by taking over your product.

And not by slowing you down with enterprise processes.

But by getting into the system with you, fixing what matters, setting the technical direction, and helping you continue building on a foundation that can support the business.

Need help turning your AI-built MVP into a production product?

I work hands-on with founders on architecture reviews, refactoring, security, multi-tenancy, AI coding workflows, engineering standards, and technical strategy.

If your MVP is working but the technical side is becoming difficult to control, book a free 30-minute call and let's look at what needs to change next.