Vibe Coding Is Real. It's Just Not What They're Selling You.

TL;DR

• Vibe coding is a real and powerful way to build, but the "ship a SaaS in a weekend" framing is doing people a disservice.
• The hardest part isn't writing code. It's knowing what to build when you can build almost anything.
• Ten weeks in, no customers yet, launch days away. Building this has been worth it regardless of what happens next.

---

My son was born in November. A week later, I was made redundant from my director role at Cotality (CoreLogic Australia), where I'd spent nine years running a $70M P&L.

The obvious move was to job hunt. Update LinkedIn, activate the network, start the process. I have the background for it: nine years of enterprise product leadership across an eight-product portfolio, 4,000+ enterprise seats, Tier 1 bank relationships.

I took the time. Family first. A newborn has a way of resetting priorities fast. But somewhere in the sleep-deprived weeks of December and January, a question started crowding out the job hunt: what if this was the moment to find out whether I actually believed what I'd been saying about AI and solo building?

I'd been arguing for the last year, in product reviews, in strategy documents, in conversations with other product leaders, that one person with the right AI tools could build what used to require a team. That the economics of software development had shifted. That the moat had moved from code to domain knowledge.

Saying it from inside an enterprise organisation is one thing. Proving it is another.

At the end of January I started building OpenChair — a booking and business management platform for beauty and wellness businesses. Ten weeks later, it's ready to launch. AI woven through the entire stack, native mobile apps, a multi-tenant architecture I built solo. Mostly between 8pm and 2am, and during daycare hours.

Vibe coding made this possible. And the way people talk about vibe coding on the internet is almost completely wrong.

What Vibe Coding Actually Is

Vibe coding, at least as I experience it, is the practice of building in a state of genuine creative flow with AI as your pairing partner. You're not writing every line. You're directing, correcting, decomposing problems, catching the things the model gets wrong, and holding the architectural vision in your head while the code moves fast underneath you. It's more like conducting than typing.

When it works, it feels like nothing else I've encountered in just over ten years of working in and around software. Ideas become working software in hours instead of weeks. That's real. That's worth saying plainly.

That's the real version. What's being sold is something else. "I built a SaaS in 72 hours." "Zero coding experience, $10k MRR." The implication is that AI tools have made software trivially easy to produce, and anyone who doesn't have a shipped product by Monday is just not trying. That's demo-ware with a Stripe integration.

But it is not easy. And it is not fast in the way people mean when they say fast.

The Paralysis Nobody Talks About

The hardest thing about building with AI tools isn't the technical complexity. It's the decision surface.

When you can build almost anything in a reasonable amount of time, the question "what should I build next?" becomes genuinely destabilising. There are no forcing functions. No sprint ceremonies, no stakeholder sign-off, no roadmap committee. Just you, a chat interface, and an infinite possibility space.

In the first two weeks, I built a full AI-generated business intelligence module with narrative summaries, a client preference engine that learned from booking history, and a styling recommendation feature. All of it worked. None of it was what a salon owner needed on day one.

I knew this. I'd been doing product work for just over ten years. I still did it, because the AI made it effortless and effortless feels like progress.

What I was actually doing was avoiding the harder problem. Building the BI module didn't require me to sit with the unglamorous reality that most independent salons just need a reliable booking system that doesn't double-book, sends decent reminders, and doesn't take 20 minutes to learn. That problem is less interesting to build. The AI could handle it fine. I just didn't want to start there.

Each session I'd open with good intentions and end an hour later with something technically impressive that had moved me no closer to a product a real salon could use. I had to build discipline around this the hard way. I wrote about the overbuilding trap in detail. The short version: speed creates its own trap. You can build yourself into a corner faster than ever before.

What pulled me out of it was treating every session like a product decision, not a coding session. What is the one thing that moves the needle for a salon owner today? Not this week. Today. That single question, asked at the start of every session, made the work tractable. It also meant cutting things I'd already built, which is its own kind of discipline.

When Is Something Good Enough to Ship?

Nine years of enterprise product work trains you to expect proper QA cycles, UAT environments, change management. You develop a learned instinct for when something is ready.

Solo, at midnight, that instinct gets unreliable.

My working rule became: if I'd be embarrassed to show it to a paying customer, fix it. If I'd just be nervous, ship it. Nervousness is fine. Nervousness means you care.

The pattern I developed for deciding what makes it to launch: anything that causes data loss or a core workflow failure is a blocker. Anything that looks rough but doesn't break the experience is a ship-it. Anything I've built but decided isn't ready as a launch feature gets held back deliberately, not abandoned, just sequenced.

The AI Concierge — a voice receptionist that handles booking calls — is a good example of how that sequencing played out. I'd built it. It worked in testing. But I held it back from launch, because I wanted the core booking and management experience to be solid before layering on voice. That decision cost something; I'd spent real time on it and cutting it from launch wasn't technically required. It was the right product call. It shipped shortly after as a Pro feature, once the foundation was stable. The discipline of making that call when you're also the engineer who built the thing is harder than it sounds.

The features I shipped while nervous have mostly been fine. A few weren't, and I fixed them. The features I held back waiting for confidence were usually held back for the wrong reasons — not because they weren't ready, but because I was using "not ready" as a shield against the actual test: whether anyone cares.

Judgment is the real bottleneck, not build speed. You have to develop a clear-eyed read on your own work, and that means shipping things before you're comfortable. It also means being honest when something is actually broken versus just not beautiful.

The Grind They Don't Post About

I've built features during daycare hours and on my phone at pickup. I've shipped things at 2am and been up with a newborn at 5am. I have a notes app full of product ideas I captured at 3am and revisited later. OpenTradie, a second platform I was prototyping in parallel for trades and contractors, got its core booking flow designed on a camping trip with no WiFi, in a Markdown file.

This is not a complaint. I want to be clear about that. I chose this. But I want to be honest about what building this actually looks like, because the version being sold online is a highlight reel without the hours.

You don't switch off. Not really. The product lives in your head. You're always running a background process: what's broken, what's next, what did that competitor just release.

I watch what other platforms in this space are doing constantly. Not anxiously, but attentively. Fresha raised $100M in 2022 and has been consolidating the global market aggressively. Timely has a strong foothold in Australia and New Zealand. New entrants are building with AI. I know what they're shipping before most of their customers do, because I'm watching closely, because I have to. And when a competitor posts about a new feature, I can have a version live in fifteen minutes. That's not an exaggeration. That's the actual calculus that makes this fight worth having.

This is the part that takes more toll than the late nights. Sleep deprivation you can manage. What's harder is the persistent background radiation of competitive awareness: the knowledge that Fresha's development team is probably eighty people, that what I shipped in ten weeks they could replicate in a sprint if they decided it was worth their attention. The question of whether vertical depth is actually a moat or just a head start keeps running underneath everything else.

I believe it's a moat. The operational reality of how a hairdresser's schedule differs from a massage therapist's, the cancellation psychology specific to beauty clients, the specific compliance requirements around product retail in salon environments — that's knowledge AI coding tools don't generate. You acquire it by caring about the domain, not by being a fast builder. But I haven't proven it yet. That's what launch is for.

Is It Worth It?

Time will tell on the commercial question. OpenChair launches in the coming days. I don't have customers yet. I don't know if it will find them, or how quickly, or whether the product earns the hours. Belief isn't a business.

There's a version of this story where I say the learning was the point and the outcome is secondary. I don't entirely believe that. I built something real, and I want it to work. Not for validation. For the argument. I've been telling enterprise audiences for the last year that one person with the right AI tools can build production-grade software at a fraction of traditional cost. OpenChair is the proof point. If it struggles to find customers, that complicates the case, even if it doesn't disprove it.

The pre-launch window has its own quality. I've shipped products at companies before, things that went into the hands of millions of users. But there was always a team to absorb the anxiety, a roadmap to point at, other people whose names were also on it. This is different. There's no product team, no customer success function, no one to share the outcome with. If it works, that's mine. If it doesn't find users, that's mine too.

I was made redundant with a newborn. I'm still figuring out what comes next professionally. But I made a deliberate choice to build before anything else, and the outcome of that choice is about to become visible.

What I can say without qualification is that the experience of building it has been worth it.

In ten weeks, while being a new parent, I shipped a production multi-tenant SaaS platform with native mobile apps, multi-model AI orchestration across six LLMs, and Stripe billing, solo. That is not something I could have said three years ago. The capability shift is real. The technical architecture behind OpenChair barely scratches the surface of what it feels like to actually do it.

Standing at the edge of a launch you built yourself, knowing every screen and every API call, there's a specific quality to that feeling. No P&L responsibility ever matched it.

If You've Been Thinking About Building

Start. That's it. Not "start when you have a clear idea," not "start when you've validated the market." Just start building something real, with real constraints, for a real problem you actually understand.

The tools are good enough. They will also confuse you, hallucinate, lead you into architectural dead ends, and occasionally delete things you wanted to keep. You'll learn to work with that. The bias toward action has to come first.

Not everyone wants to be a builder. That's fine. Building at this intensity (the late nights, the context-switching, the competitive awareness, the risk of launching to silence) is not for everyone, and there's no shame in knowing it's not for you.

But if you've been sitting with the idea. If you've been thinking "I could build that" and talking yourself out of it. If you've been waiting for a better moment, a clearer vision, more certainty about the outcome.

You're not going to get those things. Clarity comes from building, not before it. The vision sharpens in contact with real work. The moment doesn't get better on its own.

The weekend-SaaS crowd will keep posting their revenue screenshots. That's fine. But if you want to build something that actually works for actual people, prepare for it to take longer, cost more attention than you expect, and be more disorienting than the demos suggest.

Also prepare for it to be one of the more satisfying things you've done.

That part they're not lying about.