It's not a product. It's how we work.

We were fighting our architecture.

For years we built the way most agencies still do: WordPress with twelve plugins, a stack of SaaS tools glued together with hope, spreadsheets running operations that should have been on real software years ago.

It worked for smaller engagements. Then it kept not working for the engagements that mattered.

A membership organization needed hierarchical permissions where unit leaders could see their teams but not other teams. WordPress gave us four user roles, flat and inflexible. A client needed financial transactions that atomically updated multiple records — money moving from one account, landing in another, every change auditable, no possibility of half-completed states. WordPress gave us custom post types and crossed fingers. A training program needed courses tied to certifications tied to organizational prerequisites, with progression rules that enforced themselves. WordPress gave us a plugin ecosystem where each plugin solved 80% of the problem and fought the others that solved the rest.

The pattern was always the same. The off-the-shelf tools were built for content management, not for organizational operations. Building from scratch each time meant six-figure budgets and year-long timelines that almost no client could justify.

At some point we noticed we weren't fighting our clients' requirements. We were fighting our architecture. So we stopped fighting and built our own foundation — not to sell, to use.

Twenty-three packages, by domain.

Tome is composed, not monolithic. Each package handles one domain coherently, and every package has been hardened against production demands at organizational scale.

We've layered these so they share a single identity model, a single permission system, and a single audit trail. When we build for you, we're not starting from zero — and we're not assembling unrelated tools that have to be taught about each other. Every package speaks the same language.

But every project is still custom. Tome is a foundation, not a template.

Tome is production-grade, right now.

This isn't theory or unshipped code. As of today, Tome runs:

Vanguard — a 700+ member Star Citizen organization with full Milsim structure. Wings, units, squadrons, and billets. Hierarchical command with delegated authority. A training academy with prerequisite enforcement and certification awards. A double-entry financial ledger handling in-game currency and internal merits. Multi-signature governance for high-stakes administrative actions. Discord integration via a dedicated sidecar service. Real-time operational coordination. Roughly 70,000 lines of TypeScript across 85+ collections and 48 reusable access policies, built for an organization eight years in the making. The full Vanguard story is in the studies.

Wabbit's own sites and a small set of sibling deployments — every Wabbit Static and Platform build runs on Tome. The site you're reading runs on Tome. The Living Library — Wabbit's reading room, where essays, series, and the methodology pages live — runs on Tome. Every page you click through on wabbit.com is rendered by the same substrate Vanguard runs on.

6DOF Academy (in beta) — a six-degree-of-freedom flight trainer for Star Citizen and Elite Dangerous pilots, in beta with some of the game's most demanding pilots. It's not the sort of thing you'd expect to share a substrate with a financial ledger or a training certification system — which is exactly the point. The platform that handles a 700-member organization's accounting also handles WebHID input from a HOSAS rig, three.js-rendered 3D scenarios, and frame-accurate input traces. The same substrate your business would run on, put through one of the hardest internal stress-tests we've ever set ourselves.

The breadth is the point. A platform that holds up under that range is the platform your business would run on.

When we build for you on Tome, here's what changes.

Four things, in plain terms:

We're not the right shop for a simple website or a basic online store. WordPress + a designer handles those beautifully, and we'll tell you that on the call. But when your organization needs software that matches operational reality — when off-the-shelf has stopped being able to hold it — that's what Tome was built for.

Is Tome a product we sell?

Not currently. The way to benefit from Tome today is to work with us — through the Architecture Sprint into a platform build, or up the ladder from a Static engagement.

We hear the question. The reasons we haven't productized it have less to do with "we don't want to" and more to do with what productization would actually mean. A SaaS version of Tome would need a hosted multi-tenant offering, a self-serve admin, a documentation set, a support tier, a billing layer, a roadmap-driven product manager — the whole apparatus of a software company on top of an agency. We're not opposed to building that apparatus, but it would change what Wabbit is, and we'd want to be sure we wanted that change before making it.

Eventually some shape of "Tome is also a thing you can buy" may exist. A licensed-to-partner-agencies path. A vertical SaaS for community-shaped organizations. A managed-hosting option for clients who don't want to run their own infrastructure. The decisions about which (if any) of these to pursue aren't yet made.

For now: Tome is how we work. The way to use it is to hire us.

Tome is built on Next.js 16 (App Router, React Server Components), PayloadCMS 3 (MongoDB via Mongoose), TypeScript strict mode end-to-end, Better Auth for sessions, passkeys, and OAuth (with a custom payload-auth integration), TanStack Query for client-side server-state, Zustand for complex UI state, GSAP for motion, and Redis for application-level caching. Real-time collaboration runs on Yjs CRDTs with y-websocket. Media is served through Bunny CDN with per-member folder isolation. Background jobs run on BullMQ. Discord integration runs as a dedicated sidecar.

Deployment is containerized via Coolify on dedicated Hetzner hardware. Sessions are stored server-side with instant revocation. Rate limiting is fail-closed. GDPR compliance is layered into the data subject rights implementation, not bolted on. Security clearance enforcement happens at the database read layer, not the UI layer.

Twenty-three packages, all published to a private registry we run ourselves. Every Wabbit build pulls from the same source of truth.

Want to build on it?

This page is for "what is it." The "what we'd build for you" conversation lives next door, at Platform Builds — that's where we trade your operational details for a scoped plan: what the Architecture Sprint would surface, what the build would cost, what the retainer would cover.

If you've outgrown your tools and you're ready to scope what comes after, that's where to go.

See the offer → Platform Builds

Or read the full Vanguard case study →