A case study on how building individual client websites for local Fort Wayne businesses revealed that the real product was never the sites — it was the managed services control plane underneath them.

The Platform Under the Websites

There’s a moment in most platform stories where the builder realizes they aren’t making what they thought they were making. For Syntaxis, that moment arrived during a settings page design session. I was researching how Vercel, GitHub, Linear, and Stripe handle organizational permissions — RBAC tiers, team switching, workspace inheritance — and trying to figure out which pattern to adopt. None of them fit. The reason none of them fit is that Syntaxis isn’t a collaborative SaaS product. It never was.

It’s a managed services platform. And recognizing that changed everything downstream.

The starting position

The work started simple enough: local businesses in Fort Wayne needed websites. Mama Mia’s Pizza needed an online menu. Sarah’s Snake Shop needed a storefront. Witching Hour needed a brand presence. World Aid Runners needed a landing page for their mission. Each one got an Astro site, a GitHub repo, a Vercel project, and a custom domain. Standard freelance web work.

But from the beginning, every site was deployed under the same Vercel team. Every repo followed the same conventions. Every deployment pipeline used the same patterns. The “freelance projects” were already behaving like tenants in a platform — I just hadn’t named it yet.

The KB — Syntaxis itself, running on VerbosAI — was always the orchestration layer. Architecture decisions, deployment logs, credential rotation schedules, incident records. All the operational knowledge lived in one place, even as the client sites multiplied. That’s not a portfolio. That’s a control plane.

The reframe

ADR-017 made it explicit. Syntaxis is not a tool that multiple users collaborate inside of. It’s a platform with exactly two authority tiers:

The platform operator — me — has full control across all client projects. Design, deployment, DNS, credentials, infrastructure, billing. Every architectural decision, every code push, every environment variable rotation flows through the operator.

The tenant admin — the business owner — gets a scoped portal to manage their own content. Hours, menu items, contact info, announcements. They see their site and nothing else. No team dashboard, no org switching, no peer permissions. The simplicity is the feature.

This isn’t the GitHub model where you join multiple orgs and navigate between them. It’s closer to how a Webflow agency operates, or a WordPress multisite network, or a Cloudflare partner program. One operator, many tenants, clear power asymmetry by design.

The reason the SaaS RBAC patterns from Linear and Notion didn’t fit is that those products assume peer collaboration. Syntaxis assumes a service relationship. The operator builds and maintains; the client edits content and runs their business. Different relationship, different architecture.

What isolation actually looks like

Each client site is genuinely isolated:

Separate GitHub repository. Custom codebase, custom build. No monorepo, no shared source tree.
Separate Vercel project. Independent deployments, environment variables, domains, and spend thresholds.
Separate AI session context. When Claude works on Mama Mia’s, it operates within that repo alone. No cross-contamination of credentials or content between clients.

This isolation was already in place before ADR-017 named it. The architectural decision didn’t create the pattern — it recognized and codified what was already true. The four client sites, plus two personal projects and the control plane itself, all live under a single Vercel team. They share billing and team membership, but nothing else.

The data layer changes the game

Recognizing the platform model immediately raised a question: if all these businesses are tenants in a system, shouldn’t their data be queryable across that system?

Static HTML menus can’t answer “what’s selling this month.” Hardcoded business hours can’t feed an analytics dashboard. Markdown files in a repo are excellent for content ownership and versioning, but they can’t support relational queries, real-time updates, or geographic intelligence.

ADR-018 introduced Supabase — Postgres with PostGIS and row-level security — as the shared data layer. A single Supabase project serves all tenants. RLS policies enforce isolation at the database level: Mama Mia’s can never see Sarah’s Snake Shop’s data, even though they share infrastructure.

The schema covers six domains that build on each other:

The platform layer handles businesses, locations, and team members. A single business can have multiple storefronts, each with its own hours, address, and PostGIS coordinates.

The menu layer models categories, items, size variants, modifier groups, and modifiers. This is the immediate need — moving Mama Mia’s menu from static HTML into structured, editable data.

The orders layer tracks what actually sells. Even basic order tracking — manual entry, no POS integration yet — gives a small business owner data they’ve never had: which items move, which sit, what the real revenue breakdown looks like.

The supplier layer connects restaurants to local farms and food producers. A farmer growing heirloom tomatoes becomes discoverable by every pizza shop in the county. This isn’t theoretical — Fort Wayne has a real local food ecosystem that lacks infrastructure.

The geography layer uses PostGIS to power spatial queries. What competitors are within a two-mile radius? What cuisines are underrepresented in a given neighborhood? Where’s the gap in the market?

The analytics layer uses materialized views to pre-compute insights. Daily revenue by item, modifier popularity trends, delivery-vs-carryout ratios over time. Refreshed nightly by scheduled functions.

None of this is possible with static sites and markdown files alone. The database doesn’t replace the content-in-repo model — it supplements it. Blog posts and announcements stay in markdown. Menus, orders, and analytics live in Postgres. Both coexist.

The real product thesis

The trajectory, stated plainly:

It started as “I build websites for local businesses.”

It became “I operate a managed web services platform for local businesses.”

It’s heading toward “I run a local commerce intelligence platform that gives small businesses data-driven insights, connects them with local suppliers, and lets them understand their market.”

Each layer subsumes the previous one. The websites don’t go away — they’re the surface. The platform doesn’t go away — it’s the infrastructure. The intelligence layer is what makes the whole thing defensible.

The competitive moat isn’t the code. Any developer can build an Astro site and deploy it to Vercel. The moat is the data network: every restaurant that joins makes the supplier connections richer, the market intelligence sharper, and the analytics more valuable. That’s a network effect, and it starts locally in Fort Wayne.

What’s next

The immediate work is concrete: deploy the Supabase schema, migrate Mama Mia’s menu from HTML to database, connect the Astro site to Supabase for server-rendered menu pages, and stand up the first tenant admin portal where the business owner can edit their own menu items without touching code or asking me to redeploy.

That last part is the proof point. When a restaurant owner can log into their portal, change a price or add a seasonal special, and see it live on their site within seconds — without a developer in the loop — the platform thesis is validated.

Everything after that is expansion: more clients, more data, more intelligence. The architecture supports it. The question is execution pace.

Forma sequitur functionem. The form of the platform follows the function it needs to serve. And the function turned out to be bigger than building websites.