Frame House Miami Platform and AI Operating System

A two-system booking platform with one source of truth, run by a seven-agent AI operating layer that documents its own work. Product ownership, full-stack build, brand system, and AI Overview optimization for a 24-set Miami production studio.

Year

2026

Scope

Product strategy, System architecture, Full-stack development, Data architecture, Brand system design, AI operating model, SEO and AIO

Timeline

Multi-phase build: 4-week core sprint, ongoing operation

Prototype Snippit

Preview

Make or Break:

The Product Was Operational Memory

The studio came with an obvious surface problem. 24 themed sets, complex booking rules, two separate web properties, and one owner who could not afford to manage data in two places. That problem was real, and it was the easy part.

The harder problem was continuity. A build like this generates decisions faster than any document keeps up with. What got decided, why, what shipped, and what got deferred. When that history lives in scattered notes, the build slows down every time someone has to reconstruct it.

So the real product was never the booking flow. It was operational memory. A system that records its own decisions as it makes them, holds one version of the truth, and stays legible to whoever opens it next. The booking platform sits on top of that. So does the marketing site. So does the AI layer that runs both.

Frame House Reserve admin dashboard showing live bookings with confirmed and cancelled states

Booking conflict resolution showing a set unavailable on a date with the next available slot offered

Mechanism 1:

One Source of Truth Across Two Systems

Problem. Frame House needed a private booking platform and a public marketing site. The owner manages availability, pricing, sets, and add-ons. Maintaining that data in two systems guarantees they drift apart, and the day they drift is the day a customer books a set that does not exist.

Mechanism. Supabase holds the canonical data. The booking platform reads and writes there directly. The marketing site never owns data. It receives a one-way sync from Supabase through Whalesync and renders for display only. Reverse sync was considered and cut. It added complexity for no operational gain in Phase 1. One login, one place to change anything, no path for the two systems to disagree.

Product expression.

Supabase as the single canonical store across 24 sets and 5 zones
One-way Supabase to Webflow sync through Whalesync, display-only marketing surface
Booking platform on Lovable, React, and TypeScript, with Stripe live and the webhook writing bookings and held times on payment success
Bi-directional availability so a held set greys the date and a booked date greys the set, with a conflict resolver that offers the next open slot, a date change, or removal
Zone and full-studio buyout layered on the same availability engine, with live discount math in the booking summary
One checkout for customer and admin bookings, gated by a payment-method selector for Stripe, Cash, Zelle, Check, or Other, instead of a second parallel component

Admin booking checkout with a payment method dropdown for Stripe Cash Zelle Check or Other

Diagram of the seven-agent AI operating layer with a Project Owner routing work to specialists

Mechanism 2:

An AI Operating Layer, Not a Pile of Prompts

Problem. One operator cannot hold backend, frontend, data, brand, marketing, and operations in their head at once and keep all of it consistent. Generic AI help does not fix this. It produces fast output with no memory and no shared standards, so every session starts over and the work drifts.

Mechanism. I built a seven-agent system. Each agent owns one domain and carries the full project context for it. Brand voice, data schema, tech stack, and decisions already made. A Project Owner agent sits above them, routes work to the right specialist, makes cross-system calls, and writes every decision back to Notion as it happens. The agents do not just produce work. They maintain the record of the work. That record is the asset.

Product expression.

Seven specialist agents covering ownership, backend, frontend, data, marketing, social, and operations
A Project Owner agent that routes tasks and resolves cross-system decisions
Notion command center with Build Log, Decision Log, Feature Tracker, and Pre-Launch Checklist
Each agent loaded with brand rules and schema so output stays consistent across sessions
A productized operating model, repeatable for the next client build rather than rebuilt each time

Notion command center showing the build log, decision log, and feature tracker

How It Works section structured for AI extraction on the Frame House Miami homepage

Mechanism 3:

Built to Be Found by AI, Not Just Google

Problem. Search is splitting. Some buyers still type into Google. A growing share ask an AI engine and read one cited answer. A studio optimized only for blue links is invisible in the place where intent is increasingly resolved.

Mechanism. The site was structured for extraction, not just ranking. Every key page opens with a definition block written the way an AI engine cites it. Entity, category, location, then the facts that matter. Structured fact lists, FAQ blocks in question and answer form, and LocalBusiness and Service schema give the engines clean data to lift. Under all of it sits a brand dictionary that fixes the studio's language so humans and models learn the same vocabulary. Sets, not rooms. Creators, not clients. Frame House, not the studio.

Product expression.

AIO definition blocks and structured fact lists on every primary page
Keyword architecture across four audiences with one primary keyword per page and no overlap
LocalBusiness and Service schema for rich results and AI citation
A brand dictionary enforcing fixed terminology across copy, captions, and metadata
FAQ blocks formatted for AI Overview extraction on the questions buyers actually ask

Outcomes & Signals

What Changed

Two live properties running from one source of truth: a booking platform at book.framehousemiami.com and a marketing site at framehousemiami.com.
24 sets and 5 zones on a single availability and pricing engine, with Stripe live and a webhook writing bookings on payment success.
A bi-directional availability engine that prevents double bookings before checkout, plus zone and full-studio buyout on the same logic.
One checkout for customer and admin bookings, gated by a payment-method selector, instead of two parallel components to maintain.
A seven-agent AI operating model that documents its own decisions in Notion and repeats for the next client build.
A complete brand and AIO system: brand dictionary, four-audience keyword architecture, schema markup, and extraction-ready page structure.
Operational memory held in one place, so the owner runs the studio without a second login.