Therum OS

After fifteen years building inside content systems, we started building a new one.

The web's largest CMS runs roughly forty-three percent of the internet. The mental model that powers it (content types, taxonomies, hooks, capabilities) is genuinely good. It's universal. Every modern CMS, headless or otherwise, is a re-implementation of these same primitives.

The implementation, though, is stuck somewhere around 2010.

Therum OS is the answer to one question: what if the model survived the rewrite? Not "leave WordPress." Not "go headless." Replace what's dated, keep what's right, and ship it as something a designer-engineer with fifteen years of practice would actually want to live inside.

The insight was invisible to anyone without that context. Agencies see WordPress as a client tool, not a platform to dissect. Headless developers want to escape the model entirely. WordPress core contributors carry backwards compatibility for forty-three percent of the internet, surgical layer replacement isn’t an option for them. Fifteen years inside the system is what lets you see exactly which layers are worth saving. That is the only path to this answer.

We've spent the last decade-plus building inside, around, and against content systems, for the National Park Service, for the boutique studio we ran in parallel through college, for the agency we led at Productive Machine. Same pattern across all of it:

The pattern repeats every install. Plugins solve narrow problems with broad performance costs. Settings live in a flat key-value bucket called wp_options . WP-cron fires on every uncached request. jQuery is threaded through every screen. The admin UI hasn't been seriously redesigned since the early 2010s.

The market response so far has been to leave: headless CMSes, Next.js + Sanity, Astro + MDX. Each loses the editor, the plugin ecosystem, the universality. We trade a dated implementation for a thinner one and call it progress.

There is no "post-WordPress" yet. Just opinions on what to abandon.

Left: a stock 2026 wp-admin dashboard, WordPress News widget, Quick Draft, At a Glance, twenty-two sidebar items, no grouping. Right: the same install with Therum OS active, curated chrome, single Welcome line, four metrics that matter, sales chart, recent activity, edit-sidebar button. Same data. Same install. Different operating layer.

Stock WordPress: 22 sidebar items · News widget · Quick Draft · At a Glance · Therum OS · v1.9.44: Welcome line · 4 live metrics · activity feed · quick actions

Same WordPress install. Therum OS is the layer between you and the chrome.

Therum OS rests on a single design move: separate the model from the implementation. The model is what users, plugins, and content portability rely on. The implementation is everything underneath. Replace the second; preserve the first.

Concretely, that means a stack with four layers, each independently swappable, each speaking the same vocabulary as today's WordPress so the ecosystem above doesn't notice:

The contract: WordPress's mental model survives untouched. Plugins still hook. Users still write. register_post_type still works. The implementation, layer by layer, becomes ours.

Start with the first surface. The login is what every operator sees before anything else, it has to read as the OS, not as a CMS the OS happens to wrap. From there, the supporting modules, sidebar, search, cards, themes, kebab. The dashboard itself lives full-bleed at the end of this track.

Every surface in the frame above pairs its wireframe with the surface that shipped, and each note below names what to try in the live demo at the end of this track. The wireframes are the actual ones we drew at each stage, same fidelity we'd hand to a client, not after-the-fact illustrations. Each was a real day-of-design artifact: drawn in code, exported as SVG, fed to Bricks to render the original case study on bamleon.me. Toggle the tabs.

Login · the first surface · The default wp-login.php is a 2008-era form branded for WordPress.org. We replaced it end-to-end, same token vocabulary as the admin chrome you'll see next. Live admin · the login surface, gundam-nu light · form is live, submission disabled.

Sidebar · full · compact · icon-only · edit-mode · collapsed · Same rail, five contexts. One operator, multiple modes. Live admin · click sections to collapse, drag-arrange, toggle light/dark.

Search · idle · typing · arrow-nav · empty · full · From "filter the visible items" to "command palette across nav, content, settings, themes, shortcuts." Live admin · type ⌘K or click the search bar.

Cards · hero · card · compact · bare · magazine · Same renderer, five layout presets. Layout posture is one token. Live admin · filter, sort, search, view toggle, kebab menus, all live.

Themes · one token registry, many presets · Six tokens drive every preset. Switching is a body-class toggle. No reload. Live admin · Settings › Appearance, switch themes, density, glass.

Kebab menu · closed · open · hover · submenu · destructive · The most-touched control in the cards admin earns its behavior. Live admin · hover a card and click … to open the kebab.

Therum OS defaults to the open web-font stack, Inter for UI, Inter Tight for display, JetBrains Mono for kickers/code/numerics, loaded once, cached aggressively. Every theme can override by registering its own font stack in Therum_Themes::presets() ; users override per-theme via the Settings » Appearance panel. The tokens stay the same; only the family changes.

Performance was non-negotiable. WordPress’s reputation for sluggishness isn’t a perception problem, it’s an architecture problem. Therum OS treats it that way. Defenses run in three layers, each targeting a root cause rather than a symptom:

Therum OS got from concept to v1.9.44 in one focused week. Not a side project across 18 months. A sprint, paired with Claude Code, sitting on top of fifteen years of WordPress fluency. The version stamps below are the actual git tags as the work shipped.

The mu-plugin stack · 18 active

Every pill above is a real folder under /wp-content/mu-plugins/ . Remove any one, that layer reverts to stock WordPress. Reversible by design.

One week. Claude Code as a partner. Fifteen years of WordPress as the floor.

Therum OS isn't an 18-month side project. It's what happens when you take real fluency in a system, the kind that comes from a decade-plus building inside it, and pair it with an AI partner that doesn't get tired. We knew which hooks to filter, which options were brittle, which plugins shipped half-broken admin pages. Claude Code wrote the scaffolding, ran the tests, traced the fatals. We made the calls.

Three working principles held the week together:

Mu-plugins, not a fork. Every replacement is a drop-in folder under /wp-content/mu-plugins/ . If anything Therum-specific breaks, removing the file restores stock WordPress. No bridges to burn.

Compatibility above purity. Plugins that hook into admin_menu still work. Plugins that filter the_content still work. Therum OS layers over WordPress, never breaks through it.

AI-paired, not AI-written. Claude is in the loop for architecture review, mu-plugin scaffolding, debugging fatal traces, even the SVG wireframes you scrolled past. The thinking is ours. The typing speed is shared.

Three signals confirmed the thesis before external validation was possible. First: eight ecosystem plugins ran without modification from day one, the compatibility contract held immediately. Second: the sprint shipped v1.9.44 in seven days. If the model-first architecture had been wrong, that number would be v0.3. Third: bamleon.me, where this case study was first published, was a Therum OS install. The builder is the first production user, and the system documented the case study using the same converter that lives in the repo.

At 1.9.44 bamleon.me ran WordPress 6.9.4 / PHP 8.2.29 / MySQL 8.0 / Bricks 2.x, managed from the same dashboard. On 17 September 2026 it moved to 2.0, and WordPress came off the box.

The next two milestones move Therum OS from "WordPress with better chrome" to "an OS that happens to compile to WordPress."

Twelve months from now: WordPress is the compatibility shim. The loadbearing parts are ours. Bricks still composes. Plugins still work. Users still write. The model survived the rewrite.

Everything in this track is real, working, and shipped. Above is the full Therum OS admin embedded in the page, the experience file that ships with the release, a replica of the live shell, not a screenshot, not a video. Sidebar is live, dashboard is live, the sub-pages route, theme toggle flips light/dark, kebab menus open.

Therum OS · v1.9.44 · the full admin, from the experience file.

Open in a full window ↗

The plan at 1.9.44 was a headless dashboard over WordPress. What shipped went further. 1.9.44 became the last release you install on WordPress, and 2.0 is a literal one to one port of it onto a stack the studio owns end to end: the 1.9.44 zip read in full, split into twelve sections and rebuilt section by section. WordPress stays only as a hidden engine behind the WooPayments rail.

Fastify with Prisma 7 over PostgreSQL and Redis behind it, on Node 22, serving the public site and the /api surface from one process. A BullMQ worker drains imports and runs the schedulers: backups, catalog sync, outbound webhooks, email, the membership and lifecycle sweeps. The operator console is Next.js 16 at /tos-admin, bound to localhost behind nginx. The builder is built to static and served by the backend at /builder/.

Four disciplines hold across the codebase and are enforced by tests rather than by care. Every route parses its input with Zod before it touches the database. Every error leaves in one shape: code, message, field, details. Every counter and every limit is an atomic conditional update, never a check followed by a write. Every money path is audited as if hostile before it is called done.

Sessions and API tokens are JWTs signed with one secret the admin and the API must share; the auth middleware accepts only the admin and custom roles and fails closed. Provider credentials are AES-256-GCM encrypted at rest, passwords use scrypt with the cost stored per hash, credential-bearing query parameters are masked in request logs, and the production gate refuses to boot on placeholder secrets.

Folio: pages, posts and case studies as one Content model with canvas, markdown or HTML bodies, SEO stored per entry, a publish flow, slug lookup that serves published entries only, hooks on create and publish. The SEO engine is zero-config with fallback chains, override, then derived from the content, then the site default, a JSON-LD graph cross-referenced by id, alt text derived from a filename at read time and never written back.

Media on upload: auto-orient from EXIF then strip it, cap the long edge at 2560px, a 480px thumbnail, width and height extracted, all with sharp. The rename engine is one implementation with collision-checked names, the extension locked, the thumbnail renamed alongside, a rollback if the second rename fails, canvas references rewritten automatically. Four views, grid, masonry, metro and table; masonry sizes each tile from the image's true dimensions, which 1.9.44 never captured. The lightbox crops, rotates, flips, renames and edits alt text non-destructively with revert.

shared/therum-tokens.css is imported by the admin and the builder with zero duplication: a spacing scale named by its pixel value, semantic tokens over the raw 1.9.44 primitives so a second theme is a swap of one block, the muted contrast lifted from 2.56 to 4.76 to one, AA. Appearance is fifty controls across ten sections, saving per field, every control verified to change the rendered chrome; the Quick Controls drawer opens from the topbar on every screen with nine groups across three tabs.

The front-end dock came over from 1.9.44 and renders only for a valid session, so logged-out HTML stays byte-identical. The Base Theme is the public face: server-rendered, zero client JS, the same token values as the storefront, auto-built navigation until a stored menu overrides it. The builder is Vite 8, React 19 and Zustand: a canvas with live selectable render, a schema-driven inspector, a layers tree, a palette, undo and redo, serialisation to HTML, product lists bound to real products. The importer runs CSV dry-run by default, idempotent on vendor and source id. Extensions register through a validated manifest onto an isolated hook bus.

Real username and password login, two-factor with TOTP and backup codes, custom roles composed from seven capability bundles resolved live on every request, role management never delegable to any bundle, scoped API tokens, sign in with Google where a verified email proves identity and never authority, a thirty-day sliding session. Fifteen settings sections with zero broken saves, a 404 monitor with real redirect enforcement, backups to zip or S3 on a schedule, email and Slack notifications, a strict login gate, an onboarding wizard.

Settings, Server: fifteen audited actions that each state what they run and how to undo it, a console that parses a fixed grammar instead of running a shell, sudo on exact arguments, Host Advisor with twenty probes and twenty-five rules, and Hostinger in Nexus so the box can be restarted or snapshotted when the box is down.

Phase one, the foundation: the scaffold, the schema, fail-fast environment parsing, structured errors, JWT auth, the product slice. Phase two, commerce: orders created atomically behind a guarded inventory reservation, an idempotency key, a state machine that reserves, confirms, releases or restocks, an HMAC-SHA256 webhook verified in constant time. Both verified live against a real Postgres on 23 June 2026. Then the port of 1.9.44: the zip inventoried by eleven agents, split into twelve sections, ten built and verified in one pass against the real code; the audit found five of six settings items marked done were not, and a live bug where two-factor silently broke login.

A Studio App is a self-contained feature module: enable it in Studio and it adds its own nav entry and settings area, native, not edition-gated. Each was ported from the studio's real 1.x plugin, its engine read in full and its test file used as the spec, every divergence declared. Nexus is the first: 76 providers across AI tools, messaging and APIs, ecommerce, payments, external apps and fulfilment, in a card grid with a slide-over per provider.

A credential is AES-256-GCM encrypted at rest and only a masked preview ever reaches the browser. A tester makes a real, low-risk read against the provider's real API, proven by handing it a fake key and getting the provider's own 401 back; a provider without a tester stores and holds, labelled so. Slack, Google Drive and GitHub connect through a real OAuth authorization-code flow with a signed stateless state. Webhooks from GitHub, Stripe and Slack are signature-verified with each provider's documented scheme and rejected outright on failure. Counter's gateways resolve their secrets from here, so a gateway reads setup required until its provider is connected, and lights up the moment it is.

Milieus: members are customers. A milieu carries a colour, a discount, a group lifetime and a member duration; membership carries its own expiry, its source, manual, link, CSV or API, and a reminder mark. The discount is applied at order creation, the largest single active milieu wins, no stacking with a coupon either, and the receipt carries its label. A daily sweep runs both timelines and fires expiring-soon reminders once. Public registration links work without auth behind a honeypot, a per-IP limit, an atomic signup cap and an approval gate, and re-registration is a strict no-op.

Cluster: one group per product, enforced by the schema, with the 1.x rules: steal a product from another group and dissolve the donor under two members, garbage-collect the list, primary is the override or else the earliest member. Merged variants are resolved at read time, one entry per colour and size with the in-stock source winning a tie, routed to the real source variants, nothing copied, so there is no sync drift and checkout posts real variant ids by construction. Drift detection names the member missing a dimension the others have.

Case Studies is the portfolio type, the fifth Studio App: its own curated nav section, a details editor for client, date, services and outcome merged on write, the client as a pill on the card, OG type article and Article JSON-LD, public pages on the Base Theme; on the store, a study already in the database appeared the moment it was switched on. Flow is email and SMS: subscribers and lists with CSV import, a block composer with a source view and test sends, campaigns by list, segment or exclusion with a live count, send now or schedule with pacing and one retry.

An open pixel and click redirects, segments over order history, automations for welcome, abandoned cart, post-purchase review and win-back, a signup popup that shows once per visitor and never on cart or checkout, a weekly send slot, a per-person frequency cap, and SMS through Twilio with STOP and START.

Six counters on 23 and 24 July 2026 from the 1.x Counter plugin's 253 files: C1 the payment gateway layer, C2 cart and checkout as one session, C3 coupons, C4 the public storefront, C5 the Square gateway and the tabbed payment-method strip, C6 receipts, refund notices and sales reports, the first three each followed by a hostile audit. Every gateway implements the same interface ported from the 1.x engine: create intent, refund, verify webhook, parse event, status for the redirect leg. Nexus is the only credential store, and no cheque method can exist in the registry, which a test enforces.

Cart and checkout are one Redis-backed session, created lazily on the first add to cart, with a 128-bit token as its only credential, never in a URL, and a sliding seven-day life. Prices are never stored; totals compute live from the catalog on every read through one pipeline with stable slots: lines, subtotal, member discount, coupon, shipping, tax, total. A coupon and a member discount never stack; a coupon is validated only inside a cart, never through a lookup route that could enumerate codes. The cart token doubles as the order's idempotency key, so a double-submitted checkout returns the same order instead of reserving stock twice.

The receipt is guarded by the order's own access token, compared in constant time; a wrong token gets a generic 404. Receipts fire on confirmed payment, fire and forget so mail can never slow a webhook acknowledgement; the sales report counts paid orders only. Shipping is chosen at checkout from hybrid vendor and zone rates; local pickup runs on named slots; the money breakdown is right on the order, the confirmation, the admin and the receipt. Wallets authorise first and the order is written inside the sheet's callback, so a dismissed sheet leaves no unpaid order. Since beta.9 card, wallet and pay later settle through the reconnected WooPayments account over a headless charge path, an intent minted on the sealed engine and confirmed in-page with Stripe.js, reversible behind one setting.

Buy now opens the checkout inside the card. Wallets first, Apple Pay and Google Pay, because they return the address themselves; then sign in, or enter your details. Two steps in the order a shopper reads them: contact and address, Continue, then the method strip and Pay. Validation runs on Continue so a missing ZIP is caught while the field is on screen, Back walks the steps instead of discarding a typed address, and the method strip is fetched only when the shopper reaches it. The full checkout is the same strip at page size, drawn as a static preview before a route existed and ported one to one from that preview and the 1.x registry.

Cards show stills; hover reveals the gallery arrows, the quantity, the colour swatches and the sizes, and plays the product's own video when it has one. A clustered product is one card: two-tone members are split-gradient swatches, every colour is bound to its own flat shot, tapping a swatch shows that colour's photo at once while the buy variant still resolves on size, and sizes sort smallest to largest everywhere. The grid honours the merchant's Columns setting and caps four, three, two, one on the way down; retailer exclusives redirect to the retailer instead of a cart.