Everyone Is Vibe Coding Apps. Now What?

Ten hours of manual file-moving work dropped to about ten minutes.

For the people on that team, that meant nearly ten hours of tedious, error-prone friction erased from their work week. But for me, the most striking part wasn't just the time saved—it was how we got there. The application itself had been vibe-coded in a couple of days during a hackathon, and getting that prototype into a secure, production-ready state took another two days of engineering work.

Now that everyone can create a convincing prototype, how do we turn the worthwhile ones into applications people can depend on?

The most interesting question about vibe coding isn't what happens during the demo. The screens look good, the workflow makes sense, and the business users are excited because someone built in forty-eight hours what used to take weeks just to explain. Then comes the inevitable friction: If it only took two days to build the app, why would it take months to put it into production?

I found myself dealing with exactly that situation. Our hackathons were producing useful proofs of concept, and product managers were spinning up their own applications. We had a growing collection of ideas people could see, click through, and discuss. We also needed a repeatable way to turn the worthwhile ones into secure, stable applications that fit our enterprise ecosystem without starting from scratch every time.

Using more than twenty years of development experience alongside several years of working with AI for software engineering, I built a process to bridge that gap. For the applications I have taken through it, the engineering work has ranged from a single day to a week, depending heavily on the quality of the starting prototype and how much enterprise scaffolding was already in place.

That experience fundamentally changed how I think about requirements gathering, architecture, and the work developers do after someone says, “I already built the app.”

How Hackathons Became Requirements Workshops

We started bringing business stakeholders into hackathons to map out real operational bottlenecks. Sometimes they arrived with an idea sketched on a whiteboard. Sometimes they arrived with a solution they had already vibe-coded over the weekend using a generative tool.

Instead of treating requirements documents as our primary output, we started treating the working prototype as the requirements document itself.

The prototype captured the proposed workflow, the general functionality, and the look and feel the business wanted. Stakeholders could react to something concrete. Instead of arguing over abstract specifications or getting lost in terminology, they could point to a screen and explain why a specific field was missing, why an approval step belonged elsewhere, or why an apparently simple task actually involved three different team members working across systems.

We established clear boundaries early on. POCs could not connect directly to live company data. They did not implement real authentication. They frequently included shortcuts designed to make demonstrations smoother, such as hardcoded user role switches or sample data reset buttons.

Those shortcuts were intentional. We were exploring an idea, and we wanted the conversation to stay focused on a single question: Does this workflow actually solve the problem?

Many of the POCs did exactly that. They made messy operational problems easy to understand and exposed flaws in our initial assumptions. Product managers began contributing prototypes regularly, feeding a healthy backlog of ideas. We had made it exceptionally easy to express an idea as software, which meant we urgently needed a disciplined way to decide which ideas deserved to become real applications.

Deciding What Is Worth Building

My first rule is simple: the problem and proposed solution must justify the engineering investment.

How much time does the current process consume? How often does it happen? How many people are affected? Would the application genuinely reduce errors or remove an especially frustrating part of someone’s job? And critically, who will own it after delivery?

The true cost includes more than just initial development. Hosting, ongoing support, maintenance, security patches, and future feature requests all belong in the decision.

There is always an exception: sometimes a project is just interesting, and curiosity is a valid reason for a personal experiment. But for enterprise work, an investment needs a clear operational justification. A prototype can also earn its keep without ever becoming a standalone application. Sometimes it reveals a minor enhancement we can patch directly into an existing system, or it proves that a simpler automation is all we actually need.

Choosing the Production Platform

Once an idea clears the value threshold, I review technical fit.

Most of our POCs were lightweight React or HTML web applications, with the occasional Python utility. Our enterprise standard for web applications, however, is .NET, Blazor, SQL Server, and deployment to Azure.

The prototype's technology was ideal for rapid discovery. The production technology needed to fit our actual users, security posture, data layers, and the team responsible for maintaining it long-term. Generally, these solutions fell into three architectural buckets:

Shared workflows with centralized data: For multi-user apps, I used Blazor Server (or server-interactive Blazor Web Apps). Enterprise single sign-on, role-based authorization, and audit logging belonged in this design from day one.
Local productivity utilities: For a tool centered on a single person's day-to-day work, I looked at Blazor Hybrid desktop applications. These applications could still call APIs and access shared data, but they shined when local file system access or hardware integration mattered.
Offline-capable workflows: For users who occasionally needed to work without an active network connection, I used Blazor WebAssembly PWAs. Offline capability requires deliberate engineering around local storage, queued synchronization, conflict resolution, and handling sensitive data securely.

These were practical choices for our specific environment. Another organization might reasonably standardize on React, Node, or Python. The core principle remains the same: the final application must fit its operating environment and be fully supportable by the team.

What We Preserve From the POC

When moving from a prototype to a production app, developers often debate whether to salvage the code or start fresh. In practice, I use a hybrid approach.

We typically preserve:

The UX layout and user journey: The visual flow, component arrangement, and interaction patterns validated by the business users.
Core business logic heuristics: The underlying calculations or state transitions mapped out during prototyping, provided they handle edge cases correctly.

We rewrite or replace:

Mock data layers: Replacing hardcoded arrays and temporary state stores with robust Entity Framework models and repository patterns.
Security boundaries: Stripping out demo conveniences like mock role switches and implementing native enterprise identity providers and policy-based authorization.
Error handling and telemetry: Adding comprehensive structured logging, try-catch resilience, and validation checks that don't matter in a throwaway demo.

A Repeatable AI Workflow

To keep conversion turnaround fast—typically between one day and one week, assuming our standard enterprise templates, authentication hooks, and shared libraries are already in place—I rely on a structured, reusable set of instructions and prompts for AI tools.

Rather than starting from scratch with generic prompts every time, our workflow uses specific instruction sets to guide the transition. A representative example of the system prompt we feed into the AI during the initial analysis phase looks like this:

You are an enterprise software architect reviewing a proof-of-concept (POC) web application. 
Analyze the provided source code and repository structure. Your output must include:
1. A clear README outlining the core application purpose, user workflows, and entry points.
2. An inventory of fully implemented behavior versus simulated or mocked behavior (e.g., hardcoded data, fake auth, bypassable buttons).
3. A list of ambiguous business rules or unaddressed edge cases that require stakeholder clarification.
4. A proposed migration plan mapping existing Razor/React views to a secure Blazor component architecture using our enterprise data access patterns.

This preparation prevents us from having to re-explain our architectural standards on every project. It preserves an essential role for human judgment: the AI inspects the code, proposes changes, and drafts tests, but I must decide whether it accurately captured the nuances of the business problem.

The Six-Step Conversion Process

Once the target platform is selected and the initial analysis is complete, I run the code through a structured engineering sequence.

Step 1: Analyze the POC: Using the prompt structure above, we separate what is real from what was simulated. A Save button in a prototype might just update a temporary JavaScript array; an approval screen might lack rules preventing invalid state transitions.
Step 2: Establish the Production Architecture: We build out the proper solution structure—business rules, data access contexts, configuration management, and authentication hooks. We also introduce a “rubber duck” review step with the AI to surface hidden assumptions before they become cemented in code.
Step 3: Run the Test-and-Fix Loop: We engage in a disciplined development loop: make a focused change, build, run tests, inspect failures, and correct the root cause. Demo conveniences like role selectors are stripped out or isolated so they never leak into production.
Step 4: Systematic Code and Security Review: Once authentication and core workflows are functional, we run automated scans and code reviews to check for dependency vulnerabilities, input validation gaps, and missing error paths.
Step 5: Smoke Testing with Realistic Permissions: We verify essential workflows using proper test accounts and realistic permissions. A workflow that only succeeds for a developer with administrator rights is not ready for prime time.
Step 6: Secondary Model Review: As a final sanity check, I run a code review using a different underlying AI model to catch any blind spots or missed edge cases before

Search This Blog

Coding With David