No multi-location control
Businesses with more than one space had no way to separate hours, staff and calendar by location — the tool didn't keep up with growth.
Case Study — Product & Engineering
Marcoo — from idea to a production multi-tenant SaaS
How I designed and built, from scratch, a scheduling system for team-based businesses — multi-tenant architecture, a per-location availability engine, plans with real enforced limits, and an engineering discipline that proves every change in production before trusting it.
- Product: getmarcoo.com
- Sector: SaaS · Scheduling and operations
- Disciplines: Product · Full-stack Engineering · Multi-tenant · Billing · Security
The product
is the scheduling system I designed and built for team-based businesses — barbershops, hair salons, clinics, studios. Multi-tenant from the first schema line, built with TanStack Start, Cloudflare Workers and Supabase Postgres.
The challenge
Booking was never the hard part — operating was
Appointment-based businesses have tools to book. What's missing is running the operation: separating hours and staff once a business grows past one location, protecting against no-shows with no tooling at all, and seeing the day without opening the full calendar by hand.
No-shows with no protection
Without a booking deposit or a no-show history, a client who doesn't show up costs time and revenue with no way for the business to protect itself.
Flying blind operationally
Without a dashboard or export, the owner of an appointment-based business had no view of the day without opening the full calendar by hand.
Architecture
Five pillars, one multi-tenant system
Every layer was designed for real businesses — the database enforces the rules even when the frontend fails, not the other way around.
Multi-tenant with RLS
Every organisation isolated by Row-Level Security in Postgres — the frontend never decides what's visible, the database does.
Availability engine
Hours resolved by precedence: staff exception → staff schedule at that location → staff's general schedule → location hours → base business hours. Covered by unit tests and validated against real data before every change.
Real plans and billing
Three plans (Starter, Pro, Business) with limits — staff, SMS, features — enforced by database triggers, not just the interface.
Cost-aware communications
Asynchronous email and SMS queues, with a monthly quota per plan sized from the real per-message cost, to protect margin without cutting reminders to an active business.
Security by default
Sensitive functions run as SECURITY DEFINER with explicit session and organisation checks — never implicit trust in the client.
Execution
From the foundation to multi-location, in phases
A clear sequence, each phase proven in production before the next.
Foundation
Authentication, organisations, end-to-end Row-Level Security, internal calendar and public booking page.
Closed beta
Invite gate, waitlist and referral program — to grow with control instead of opening the floodgates.
No-show protection
Manual and online booking deposits via Stripe Connect, automatic blocking of repeat no-show clients.
Multi-location
Four successive phases — data foundation, per-location hours, location choice on public booking, calendar and dashboard filtered by location — each tested in production before the next.
Margin-safe SMS engine
Monthly quota per plan, sized from the real per-message cost, to keep the product sustainable while it grows.
Current state
In closed beta, with an architecture built to scale
No inflated business numbers: the product is in invite-only closed beta, with no commercial launch yet. What exists is a working, tested multi-tenant system, ready for its first real customers.
plans with real limits
Starter, Pro and Business — every limit enforced by a database trigger, not just the interface.
multi-location phases shipped
From the data foundation to the location-filtered dashboard, each one proven in production.
of migrations tested before applying
Production rollback-tests — never a blind schema change.
invite-only
Controlled growth ahead of commercial launch.
No business metrics (sales, paying users) because none exist yet in any meaningful way — the product is pre-commercial-launch. What's measured here is engineering maturity, not traction.
Want a system like this for your business?
If you recognise the need for a well-built product — not just a campaign or a website, but a system that holds up at scale — let's talk about the next step.
Talk about a similar project