Vibe Coding is Cheap, Show Me The Demo: How I Code with Playwright UI as My Co-Pilot

The Evolution of My Development Philosophy

Throughout my career—first as an engineer, then as a product manager—I practiced what I called "Demo-Driven Development." This approach stemmed from a core belief that shaped my entire career: our work is only done when the user says so. We're not producing code—we're solving problems. This user-centric philosophy meant every sprint was planned around the next demo where I tried to show how we were solving a user's problem, every backlog item was prioritized by its demo impact, and every feature was built with the end presentation in mind. The demo wasn't just a showcase—it was the north star that guided all development decisions.

Now, as a solo founder building MicroSaaS products, I've pushed this philosophy to its logical extreme. I'm no longer just the product manager planning demos; I'm the developer, QA engineer, designer, and marketer all rolled into one. This reality has forced me to evolve my approach into what I now call Show Me The Demo Development.

Why Solo Founders Can't Afford Bugs

When you're building alone, every bug is a crisis. There's no QA team to catch regressions, no dedicated support team to handle customer complaints, and no development team to quickly patch issues. If I ship a broken feature, I'm the one who has to drop everything to fix it. As a solo founder building multiple products, I can't afford that kind of disruption.

This constraint led me to a crucial realization: the scenarios I need for product demos are exactly the scenarios I need for regression testing. Why write tests separately when the demo flow IS the test?

This becomes even more critical when working with AI agents to modify your code. While AI is incredibly capable of writing code, it can also break existing functionality in unexpected ways and unexpected places. Without solid regression guardrails around the process, you'll find yourself running in circles, fixing one thing while unknowingly breaking another. Believe me, I've been there a few times in the last month alone.

Enter Show Me The Demo Development

We're living in the era of vibe coding, where developers rely on AI to generate code without reviewing the output. Vibe coding—the practice of letting AI write code based on rough intentions and good vibes—has made code generation effortless but verification crucial. When AI can generate endless code based on intentions alone, the old saying "talk is cheap, show me the code" has evolved into "vibe coding is cheap, show me the demo." Proving your software actually works has become more important than just writing it. Show Me The Demo Development embraces this vibe coding reality by making working demonstrations the foundation of your development process.

Just as Infrastructure-as-Code (IaC) revolutionized DevOps by treating infrastructure as versioned, testable code, Show Me The Demo Development treats your product demonstrations as first-class development artifacts. Like Configuration-as-Code (CaC) ensures consistent environments, and Policy-as-Code (PaC) codifies business rules, this methodology codifies your user scenarios.

Show Me The Demo Development is built on a simple premise: every feature starts as a Playwright test that demonstrates the complete user scenario. Unlike Behavior-Driven Development (BDD) which focuses on creating business-readable specifications for stakeholder communication, Show Me The Demo Development creates visual, interactive demonstrations that can be directly shown to customers and prospects. While BDD helps teams align on requirements, Show Me The Demo Development creates actual sales materials—though it's especially powerful for solo founders.

My Show Me The Demo Workflow

Here's how I actually work:

1. Open Playwright UI alongside my code editor
2. Write the complete scenario flow - codifying what the user does and the expected outcomes as my specifications
3. Run the scenario in Playwright UI to see which parts fail
4. Implement the functionality (often with AI assistance) to make the scenario pass
5. Refine the scenario with more detailed checks and edge cases as needed

It's like TDD, but instead of unit tests, I'm building complete user journeys. The Playwright UI becomes my real-time feedback loop, showing me exactly what the user will experience.

You can even point an AI agent to run the tests via command line and ask them to fix failing tests. Just watch carefully that they don't change the demo scenario code to make tests pass—the scenarios are your specifications and should remain unchanged.

But What About the Test Pyramid?

I know what you're thinking: "This violates the Test Pyramid! E2E tests are slow and brittle. You should be running fast unit tests during development, not heavy browser automation."

You're absolutely right about traditional E2E testing. But Show Me The Demo Development isn't traditional E2E testing—it's specification-driven development that happens to use browser automation. The key difference is that I've developed several techniques to make these tests run fast enough for real-time development feedback.

I'm not abandoning unit tests entirely, but for solo founders building B2B SaaS products, the demo scenarios ARE the most critical tests. When your entire business model depends on live customer demonstrations, ensuring those scenarios work perfectly is more valuable than having 100% unit test coverage on utility functions.

I'll be sharing my specific techniques for fast Playwright development workflows in an upcoming blog post. Subscribe to my RSS feed to get notified when it's published—these optimizations are crucial for making this approach practical.

A Real Example: Building GitHub Actions One-Click Analytics

When building Cimatic (my GitHub Actions analytics platform), I started with this scenario:

• Left side: The test scenario and the implementation open in Vim
• Right side top: Playwright UI, with the browser window showing the scenario
• Right side Bottom: AI agent CLI and a terminal showing logs from services

This visual demonstrates the core concept: writing the demo scenario first, then building the product to make the scenario pass.

The Magic of Incremental Development

With Playwright UI open, I can run just the first few lines, see the page load (or fail), then code the /analyze route. Run again, see the form appear, then implement the form handling. Each step builds on the previous one, and I always know exactly what the user experience looks like.

This approach has several unexpected benefits:

From Test to Demo Video in Minutes

Here's an unexpected bonus I discovered: once my scenario test is working, creating a demo video becomes trivial. Just like Documentation-as-Code keeps docs in sync with code, my demos stay perfectly synchronized with actual functionality. I just:

1. Record the Playwright test execution using screen recording
2. Add voiceover explaining what's happening
3. Edit for pacing and add captions

The result is a polished product demo that shows real functionality, not mockups or staged data. Customers see exactly what they'll get.

Conclusion

As a solo founder, I can't afford to build features that don't work, create demos that don't convert, or waste time on separate testing infrastructure. Show Me The Demo Development solves all three problems with a single approach.

Working this way feels incredibly productive because I don't need to manually click through the same demo flow for the 82nd time while coding—this alone is life-changing! Every change is instantly visible and testable, I'm building sales materials as I code, and regressions are caught immediately instead of in production.

Like how Security-as-Code embeds security into every development step, Show Me The Demo Development embeds customer validation into every feature. Every line of code I write serves multiple purposes: it implements the feature, tests the user experience, and prepares the demo. This isn't just efficient—it's essential for competing against well-funded teams while working alone.

The next time you're building a feature, try opening Playwright UI alongside your editor. Write the scenario first, then make it real. You might find, like I did, that your best development tool was hiding in your testing toolkit all along.

Want to see Show Me The Demo Development in action? I'm documenting my journey building multiple MicroSaaS products using this approach. Follow along as I build Cimatic (GitHub Actions analytics), and other products using Show Me The Demo Development.