THIOS: THE BACK OFFICE A DESIGNER BUILT

What This Is

Every other Thios case study is about a surface customers touch — the six-surface design system, the CAD that is the product, the configurator. This one is about the surfaces nobody sees: the back office that actually runs the business.

Twenty-one admin pages, across four separately-deployed sites, behind a single shared auth layer. Orders and fulfillment. Bill of materials, kits, pricing. Customers, newsletter, feedback, funnel analytics, partners. Post management. The unglamorous machinery a product line needs before it can take a single order.

Nobody Funds the Admin Panel

Internal tools are where design normally dies. Nobody funds the admin panel. It gets built by whoever has time, it looks like it, and it never gets a system — because every hour spent on a screen five people will see is an hour not spent on the storefront.

For a company of one that math is even harsher. The realistic options were: buy four SaaS tools that don't talk to each other, or run the business out of a spreadsheet and a database console. Both were genuinely on the table.

What changed is the marginal cost. The fifteenth admin page costs roughly what the third did. Once that's true, "does this deserve a UI?" stops being a budget question and becomes a judgment question — which is the kind of question a designer should be answering anyway.

What I Got Wrong First: Store Builders

I started where everyone starts — on store-builder platforms. They're built to save you exactly this work, and for the first week they do.

The problem is that they sit a layer above the tools that actually do the job. You don't get Stripe; you get the platform's idea of Stripe. You don't get the print-fulfillment API; you get the fields the platform decided to expose. That's fine while you want what everyone else wants. The moment you want something novel — a configurator that prices a custom build, a kit that resolves to a bill of materials — the abstraction that was saving you time is the thing standing in the way.

So I went direct: Stripe and Printify against their own APIs, with the admin built around them rather than around a platform's assumptions. That's a rebuild I'd rather not have paid for, but it's the call I'd make again.

It's the same shape as the decision in the flywheel story, where Onshape's API is the source rather than an exported artifact: go to the real tool, not the wrapper. The wrapper is where novelty goes to die. AI is what makes ignoring the wrapper affordable for one person — integrating two commerce APIs directly used to be a team's quarter.

Ruled Out: Being Somebody Else's Storefront

The obvious shortcut for a small hardware line is to sell through someone else's store. I ruled it out, and the distinction matters:

• Third-party services — the target. Payments, print fulfillment, and the rest are things I want to integrate, not rebuild. Stripe and Printify are the first two; the list is designed to grow.
• Third-party retailer — ruled out. I build and run the stores. The storefront is where the product decisions live — how a build is configured, what it costs, what the customer sees when it's wrong.

Outsource the plumbing, own the storefront. Handing the retail relationship to a marketplace would have removed the exact surface this whole product line is an argument about.

The Call: One Auth Layer Across Four Sites

Four admin areas live on four separately-deployed sites. The default outcome — the one you get by building each admin when you happen to need it — is four bespoke logins, four session models, and four places to remember when access has to change.

Instead there's one shared auth layer: a single email-whitelist gate that every admin area calls. One place to grant access. One place to revoke it. One mental model, whichever admin you're standing in.

The honest limitation: it's a whitelist, not a role system. For one operator that's the correct amount of machinery — roles would be ceremony with no one to apply it to. It's also the first thing that has to change the day there's a second person, and building it as a shared layer is what makes that a single replacement instead of four.

The Four Areas

The areas map to what the business does, not to how the code is laid out:

• Sell — store dashboard, order management, and print-fulfillment integration.
• Configure — bill of materials, kits, and pricing behind the 3D configurator.
• Audience — customer records, newsletter composition and delivery logs, subscriber verification, feedback, partner management, and conversion-funnel analytics.
• Publish — post management for the blog.

That grouping is a product decision. The alternative — admin screens that mirror database tables — is how internal tools end up needing a tour guide.

What AI Actually Changed

This whole back office exists because of a shift in what one person can carry. It started in late 2025 — first on OpenAI models and Cursor, then on Claude Code, which is where it lives now.

What it made cheap:

• The Nth internal tool. Twenty-one admin pages is not twenty-one times the effort of one. That's the entire reason the admin panel exists instead of a spreadsheet.
• Going direct to real APIs. Two commerce integrations, built against the actual APIs rather than a platform's abstraction of them — the thing that made every store builder a dead end.

What it did not change — and this is the part worth being precise about:

• Which twenty-one pages should exist. Nothing decided that a funnel-analytics view earned a screen and a settings page didn't.
• The auth model. One shared whitelist across four codebases is a systems call. The code was the easy half.
• What each screen is for. Scoping is still design work, and it's most of the work.

The leverage isn't that AI writes admin pages. It's that when the cost of building drops, the constraint moves to judgment — deciding what should exist, what it's for, and what holds it together. That's a designer's job description, and it's the first time it's been the binding constraint on a one-person product line.

Where This Is

Honest and early. The back office is built and it runs — but I've been heads-down on other work, and there's no revenue story here to tell yet. I'd rather say that plainly than reach for a number.

The claim this case study actually makes is about capability, not commerce: the operational layer of a four-site product business is no longer the thing that stops one person. Every internal tool that would have been cut for cost got built, to the same standard as the surfaces customers see.

The admin panel is the honest test of whether a design system is real. It's the surface with no budget, no audience, and no one to impress — which is exactly why it's usually the ugliest thing a company owns. The question isn't whether a designer can use AI. It's whether they'll take responsibility for the surfaces nobody funds.