One Production Platform, One Cross-Vertical Test

TL;DR

• I led OpenChair, a production vertical SaaS platform for beauty and wellness, from market discovery into paid use
• I used OpenTradie, a separate prototype for trades and contractors, to test which infrastructure patterns transferred and which product assumptions did not
• The economics have inverted: what once required a 15-person team and $2M seed round can now be prototyped and shipped by a focused AI-augmented builder with modest cloud infrastructure costs

---

I keep hearing the same objection from enterprise product leaders: "Sure, AI helps you prototype faster. But production software? With billing, multi-tenancy, compliance, mobile apps? That still requires a team."

That assumption is weakening. I know because I built the whole stack.

OpenChair is a production SaaS platform for beauty and wellness venues. It includes native mobile apps, billing and payments, multi-tenant data controls, booking and communication workflows, and bounded AI features. Paying operators use it in recurring weekly work, and it recorded more than 1,000 booking creations in a recent month. Voice reception was prototyped but not shipped.

It was not a prototype. Not an MVP with a landing page and a waitlist. It was production software with real billing, real data isolation and real App Store deployment. The kind of platform that, three years ago, would have required a full-stack engineering team, a designer, a DevOps person and a QA lead.

And then, to test whether this was repeatable or just a one-time effort, I started building OpenTradie: an AI-first operating system for trade businesses. Different vertical. Different operational patterns. Same approach. The core architecture transferred. The domain-specific features (crew dispatch, job costing, quote generation) were net new, but the chassis held.

The thesis isn't "AI makes development faster." That's obvious and boring. The thesis is that AI has fundamentally changed the economics of vertical SaaS, and most people haven't processed what that means.

How have the economics of building vertical SaaS changed?

Building a vertical SaaS product used to follow a predictable formula. Raise $1.5M to $3M. Hire 8 to 15 people. Spend 12 to 18 months building v1. Pray for product-market fit before the money runs out.

The cost structure was dominated by labour. Engineers, designers, QA, DevOps. Salaries, benefits, management overhead. A senior full-stack engineer in Sydney runs $180K+ fully loaded. Multiply by the team size and the timeline, and you're burning $80K to $150K per month before a single customer pays you anything.

Now run the same calculation with AI-augmented full-stack development. Cloud infrastructure: ~$200/month. AI inference via OpenRouter with prompt caching: negligible at pre-scale volumes (90% cost reduction through caching). App Store developer accounts: $100/year each. Stripe fees: percentage of revenue, so zero until you earn.

The monthly burn for a production vertical SaaS platform is under $500. Not $50,000. Not $150,000. Under $500.

That changes who can build software, what software gets built, and which markets are worth targeting. Verticals that were "too small" for funded product development (beauty salons, trade contractors, local services) suddenly make economic sense when the build cost drops by two orders of magnitude.

The vertical SaaS chassis

The first build is the hardest. You're solving infrastructure problems (multi-tenancy, billing, AI orchestration, mobile deployment) and domain problems (scheduling, client management, service catalogues) simultaneously. Every decision is a first decision.

The second build reveals what's reusable.

OpenChair's infrastructure stack transferred cleanly to OpenTradie. tRPC with end-to-end type safety across 63+ routers. Supabase with aggressive row-level security for multi-tenant isolation. OpenRouter for multi-model orchestration across six LLMs (Claude Sonnet, Claude Haiku, GPT-4o Mini, Gemini). Stripe for billing, Connect for marketplace payments, Terminal for point-of-sale. The Vercel AI SDK for streaming responses.

This is the reusable vertical SaaS chassis. Authentication, multi-tenancy, billing, AI orchestration, real-time sync, mobile deployment pipeline. Once you've built it once, a new vertical is roughly 30% to 40% chassis reuse and 60% to 70% domain-specific features.

That 60% to 70% is where the product decisions live. For OpenChair: appointment scheduling with overlapping bookings, client history with preference tracking, product inventory, and vision-based style recommendations. For OpenTradie: crew dispatch with travel time calculation, job costing, quote generation, and equipment tracking. Same AI infrastructure, completely different product logic.

Beauty and wellness is appointment-based, individual-client focused, preference-driven. Trades are job-based, crew-dispatched, multi-site, urgency-driven. The operational patterns couldn't be more different. The fact that the same chassis supports both is what makes the model repeatable.

The voice prototype: where vertical depth became obvious

I built an AI voice receptionist prototype on Retell AI and Twilio. It was designed to qualify callers, book appointments and hand exceptions to a human, but I did not ship it to venues.

Building a voice agent that works in a controlled test is straightforward. Meeting a production standard requires deeper work on disclosure, conversation flow, latency, authority and failure handling. That gap was one reason to keep it out of production while focusing on the core operating workflows.

The beauty prototype was structured around service selection, provider preference, availability and confirmation. The trade prototype explored urgent job enquiries, which required different classification and handoff logic. The contrast showed that shared technology does not remove the need for domain-specific product decisions.

This is where vertical AI earns its margin. A horizontal voice agent platform gives you the building blocks. A vertical implementation gives you the conversation flows, the domain vocabulary, the integration with scheduling and dispatch systems, and the fallback logic that matches how that specific industry actually operates. I've written a full voice agent playbook covering the product decisions in detail.

Multi-model orchestration is a product decision

One of the earliest architectural choices was routing across multiple LLMs rather than committing to a single provider. OpenRouter makes this operationally simple. The product decision is which model to use for which task.

Claude Sonnet handles complex generation: business intelligence narratives, growth coaching insights, detailed client communications. Claude Haiku handles high-volume, low-complexity tasks: classification, extraction, simple formatting. GPT-4o Mini and Gemini handle specific tasks where their cost-quality tradeoffs are optimal.

Prompt caching through OpenRouter reduced inference costs by 90%. That's not a rounding error. At scale, the difference between cached and uncached inference is the difference between a profitable AI feature and one that bleeds margin with every interaction. I've written about this tradeoff in the audit tax analysis.

The point isn't the specific models. Models change every quarter. The point is that building for orchestration rather than single-model dependence is a product architecture decision that determines your cost structure, your quality ceiling, and your vendor risk.

What this means for vertical SaaS

Three implications that most people haven't fully absorbed.

The addressable market for vertical SaaS just expanded massively. Verticals with 50,000 to 200,000 potential customers were too small to justify venture-funded development. They're not too small when build costs drop to hundreds of dollars per month in infrastructure. Beauty salons. Trade contractors. Yoga studios. Veterinary clinics. Dog groomers. Every underserved vertical with manual workflows and phone-based operations is now a more viable software market. The business viability framework I use to evaluate these opportunities focuses on exactly this: unit economics at the operator level, not only the venture-scale level.

The competitive moat shifts from code to domain depth. When code is a commodity, the moat moves to understanding the customer's operational reality. I can build the booking system in a week. Understanding that a hairdresser's schedule is fundamentally different from a massage therapist's schedule (overlapping appointments vs. sequential, different buffer times, different no-show patterns) requires domain knowledge that AI coding tools don't generate. Vertical depth is the moat.

The team size assumption is wrong. The default mental model is still "you need a team to build production software." That assumption shapes hiring plans, funding strategies, and competitive analysis. If your competitive analysis assumes your competitor needs $2M and 18 months to ship a competing product, but they actually need $500/month and 8 weeks, your strategic planning is dangerously wrong.

I'm not arguing that every vertical SaaS product should be built this way. The useful point is that a smaller team can now keep product strategy much closer to working software. OpenChair is the production proof point. OpenTradie was a bounded test of what transferred. What the grind actually looks like is a different story from the one usually told about AI development.

---

Frequently Asked Questions

Can an independently built product actually compete with a funded team's product?

At the feature level, yes. AI-augmented development velocity is genuinely competitive with small teams. At the go-to-market level, it depends on the vertical. Verticals where customers evaluate software through trials and word-of-mouth (local services, SMB) favour product quality over sales force size. Verticals where enterprise sales cycles dominate (healthcare, finance) still favour funded teams with dedicated sales. Choose your vertical accordingly.

What breaks first when a product scales beyond the initial builder?

Customer support and operations. The code scales fine (that's what cloud infrastructure is for). The AI features scale fine (that's what multi-model orchestration is for). What doesn't scale is responding to customer emails, handling billing disputes, debugging edge cases in production, and managing App Store review submissions simultaneously. The first hire after an independently built vertical SaaS product should be operations, not engineering.

Is the 90% prompt caching cost reduction sustainable?

It depends on your usage patterns. High cache hit rates require repeated similar queries, which is common in vertical SaaS (same types of requests, same domain vocabulary, similar document structures). If your usage patterns are highly variable, cache hit rates will be lower. Monitor your actual cache hit rate and factor uncached costs into your pricing model as a floor.