Sugartown: The Platform Is the Portfolio

Challenge

A portfolio that only claims senior platform competence is a liability. I wanted the opposite: a site where the architecture is the argument. The old Sugartown was a WordPress blog, every post one big HTML blob in a single field, tags freeform, no line between content and the theme rendering it. That is the exact legacy shape enterprise teams pay to escape. So I rebuilt it as a headless, structured-content platform on Sanity and React: platform-agnostic by design, governed by a single design-token graph, and operated by a caucus of AI agents under explicit guardrails. The bar was simple. Nothing on the site should be a thing I could only describe. It had to be built, in the repo, or already tested.

Outcomes

Risk of vendor lock-in: Vendor agnostic architecture

AI governance: AI drafts, a human always approves

Content architecture: Structured pieces, not one big blob

Taxonomy: One system, no duplicate tags

The Platform Is a Fig

And then the fig has kept her secret long enough. So it explodes, and you see through the fissure the scarlet. - D.H. Lawrence, "Figs" (1923)

A fig is not really a fruit. It is an inverted flower: the bloom grows inward, and the hundreds of tiny crunchy bits you eat are the flowers themselves, turned outside in. Cut one open and the entire operation is just sitting there in cross-section, every seed on display, which is either the most honest thing in the produce aisle or the most unsettling, depending on how closely you look.

Most portfolios hide their figs. You get the polished outcome and the confident summary, and the actual insides, the content model, the token graph, the governance, the wiring, stay sealed under the skin. Sugartown is built the other way around. The platform is the fig turned inside out, and the seeds are the point: the schema, the validators, the adapter layer, the AI guardrails, the daily stats pipeline are the visible surface, not the thing hidden behind it. You are meant to see the seeds. And if running a portfolio this way sounds slightly unhinged, so does a fruit that can only be pollinated by a wasp that crawls inside and dies there, and the fig has been closing that deal for tens of millions of years.

Overview

Sugartown is my portfolio, my design system, and my knowledge graph, rebuilt from a WordPress blog into a headless content platform I own end to end. I set the architecture, wrote the conventions, and made the modeling calls; a caucus of AI agents built the components, the migration scripts, and the validators against those requirements. Two decisions define it: build it so no vendor is load-bearing, and govern the AI doing the building so nothing ships on vibes.

Challenge

The old site treated content as presentation, not data. Every post body was a single HTML blob, the exact anti-pattern headless architecture exists to kill; Sugartown's own term for the fix is breaking the blob. Color and spacing values lived wherever a stylesheet happened to need them, so there was no way to retheme or audit. Nothing proved the system could survive a change of CMS or host, and nothing separated AI-drafted copy from human-authored work. For a portfolio, the cost was simple: the site described competence instead of demonstrating it.

My Role

As Principal Product Manager and Platform Architect, I directed the build and made the calls the platform is built on:

• Set the content model: 23 document types, 11 composable section blocks, rich text as Portable Text.
• Made agnosticism a requirement, not an aspiration: scoped a proof of concept to migrate the content model and schema, not just the UI, to a second CMS and host.
• Defined the taxonomy contract: five primitives on one name field, plus the blocking pre-flight gate.
• Owned the token architecture: one source, generated not edited, a locked core and a themeable tier.
• Designed the AI operating model: the caucus, the guardrails, and the human adjudication and publish gates.

The caucus wrote the components, scripts, and validators. I wrote the requirements they were built against and reviewed every output.

Process

Model first. Before any component, the content model. I decided what a page is: an ordered array of typed blocks, not a body field. That decision is why the site is composable and portable at all.

Migrate off WordPress. Old content moved into Sanity, and the legacy document IDs still carry the wp prefix, the receipt that this was a real migration. The HTML blobs became structured Portable Text. In one pass, 26 tables trapped inside those blobs were migrated into structured tables by a script I pointed Claude Code at, not hand-fixed.

Test the real lock-in fear, not the easy one. A design system rendering on a second CMS is the expected result; a content model and schema surviving the move unchanged is the actual test, since schema rework is what makes CMS migrations expensive. I scoped a proof of concept to stand the whole system up on a second CMS (Contentful) and host (Vercel), and see what broke. Both held: zero component changes, and the same schema powered the new app with no rebuild. What broke was the packaging, two gaps the monorepo had hidden since day one, found and fixed by the first real external consumer. The verdict: 15 decision records, shipped live.

Govern the AI layer. I made the guardrails structural, not cultural: a write gate that stops any un-approved content write, anti-slop rules, an aiDisclosure field in the schema, a human-publishes rule, and a deterministic release pipeline that produces the same artifacts no matter which agent runs it. One governance point for everything the caucus touches.

Close the loop. A daily pipeline collects field and lab performance, design-system metrics, and repo signals, and commits them back as build-time data the site renders.

Key Outcomes

• Content model and schema portability proven, not just the design system: one schema, two CMSs, two hosts, zero rebuild.
• An AI operating model that is safe by construction: the caucus runs the work, guardrails gate it, a human adjudicates and publishes.
• A page is composed from typed blocks, not a WYSIWYG. 656 design tokens from one source, zero raw hex, enforced on every commit.
• Five taxonomy primitives on one field behind a dedup gate, no sprawl.
• Content modeled for machine consumption: retrieval summaries and FAQ structured data emitted automatically.

Reflection

The unglamorous decision, modeling content before building a single component, is the one that paid for everything else. It is why the design system survived a change of CMS and host with no component edits, and it is why the AI agents can move fast without moving dangerously: when content is data and every decision has a gate, an agent has nothing to improvise. The version of this I would have shipped two years ago would have started with the pretty homepage and called the vendor-agnostic part future work. Building it in the correct order is boring right up until it is the reason the thing holds.

Key Questions

How do you avoid vendor lock-in when you build on a specific CMS?

Bex draws a distinction most vendor-lock-in conversations miss: a portable design system is the easy half, a portable content model is the hard half, since schema rework is what actually makes a CMS migration expensive. That's the actual promise behind MACH architecture: if the data layer survives a vendor switch, the UI layer was always going to. She tested both by standing the whole system up on a second CMS and host in a dedicated proof of concept, and both held: zero component changes, and the same schema powered the new app unchanged. The only things that broke were two packaging gaps, which she found and fixed rather than papered over. Her position: agnosticism is worthless as a claim and valuable only as a tested fact.

How do you make AI-run engineering and content work safe?

She makes the guardrails structural, not a matter of trust. On Sugartown a caucus of AI agents runs product, engineering, and design work, but every AI-touched change routes through one governance layer: a write gate requiring human approval, anti-slop rules, schema-level disclosure, and a deterministic release pipeline that produces identical artifacts regardless of which agent runs it. A human adjudicates every architectural decision and publishes. Speed comes from the model doing the work; safety comes from it having nothing to improvise.

How do you decide between a vendor CMS and building custom?

Bex models the content first, then lets the model pick the tool. For Sugartown she chose Sanity, a structured-content product on a managed backend, over hand-rolling storage, because the value was in the content model and the governance around it, not in reinventing a content database. Her rule: narrow scope can justify a purpose-built tool, but a full from-scratch content backend is the option to stay skeptical of unless the scope genuinely demands it.

How do you keep a design system from drifting as it grows?

She makes drift structurally impossible instead of relying on discipline. Sugartown's tokens live in one source file that generates every stylesheet, so there is no second copy to update by hand. A pre-commit validator fails the build on any raw color value, and a mirror check blocks the two generated copies from diverging. The core token tier is locked; themes override only the semantic layer, which is what let the same tokens drive a second-platform app unchanged.