The Engine Room

If you build 10 websites for 10 clients, the traditional agency approach is to build 10 separate islands.

• Client A needs a booking flow. Build it.
• Client B needs a booking flow. Build it again.
• Client C needs... well, you get the idea.

At Free Beer Studio, we apply the DRY principle — Don't Repeat Yourself — to the entire business model, not just the code.

The Vision vs. The Reality

When I first wrote about the Engine concept, I described a grid of microservices: Auth-as-a-Service, Billing-as-a-Service, Content-as-a-Service. Clean abstractions. Each client project plugging into a central grid like a house connecting to a power plant.

That vision was real, but the architecture to support it wasn't built yet. I was describing a destination, not a current state. The honest version is more interesting.

What We Actually Built

The Engine exists, but it's made of specific working systems, not abstract service layers.

Supabase is the database backbone. One fresh PostgreSQL project, no legacy complexity, shared across FBS internal systems. When the booking system stores a session, it goes to Supabase. When the quoting pipeline tracks a proposal, it goes to Supabase.

The booking system is live on freebeer.ai. Five session types — a free 30-minute First Round, a 1-hour Follow-up Deep Dive, and three larger consulting blocks — all wired to Google Calendar with Google OAuth for admin access. No third-party booking tool. Custom emails, custom confirmation flows, our brand throughout.

The quoting pipeline runs from form submission through AI-assisted proposal generation through Stripe. Three payment checkpoints: 50% deposit, milestone, final. The pipeline lives in an admin dashboard at /admin/quotes. Attio CRM tracks everything after that.

Resend handles transactional email across all of it.

Why This Matters More Than the Original Vision

The service-grid vision was elegant but abstract. What we built instead is less elegant but actually deployed.

And here's the useful thing: the booking system we built for FBS is a template for clients who need booking. The quoting pipeline is a template for clients who sell services. The Supabase schema we're developing for FBS internal use is the same schema we'd build for a service business client.

We're still not building the same website twice. We're just doing it by dogfooding real systems first, then deploying the same patterns for clients.

The Future: Agentic Coders

This part of the original vision still holds. Once the shared systems are mature, we can deploy autonomous agents to build on top of them. Tell me "Client X needs a booking flow," and I instantiate the booking module, skin it to their brand, configure their session types, and deploy it.

That's the direction.

For now, I have some API routes to finish.

The cleanest architecture in the world means nothing if it's not shipped. We ship the specific. The elegant follows.