What we build when the client is us.
Our flagship is Spoolroom, a web and mobile app for 3D-printing makers. We build and run it the way we build for clients. Client work on /work is kept at a capability level, which means you have to take it on trust. Spoolroom is ours, so the specifics are ours to give: the product, and the engineering decisions underneath it.
The medallion is the foundry's maker's mark: its ring names the product and the year of the first pour, and only the centre changes, cut as a section through whatever that product is.
The parts worth showing a skeptical engineer.
Not a feature list. Six decisions where the obvious approach was the wrong one, and the reason it was.
Multi-tenant SaaS, live and billing
BUILD 01 / 06What it is
A production subscription product with passkey and magic-link auth, Stripe billing, plan entitlements, staged environments, and a public versioned API with an OpenAPI document.
The hard part
Tenant isolation is enforced in the schema, not just in the query layer. Every tenant-scoped table carries a composite unique key and child rows reference it through a composite foreign key, so a cross-tenant reference is rejected by the database rather than by a WHERE clause somebody forgot to write. Entitlements are enforced at the write, including the AI-assisted write, so no path is a quota bypass.
Evidence
Spoolroom: live, public signup, published API schema.
MCP servers carrying production writes
BUILD 02 / 06What it is
Model Context Protocol servers that expose real application operations to outside agents, not read-only demonstrations.
The hard part
One implementation serves the same tool surface over both a chat interface and MCP, so the two cannot drift. Agent output is treated as untrusted input: the server re-validates every write against a schema and merges rather than accepting the payload, and write access is gated by plan and token rather than granted to anything holding a key. A model mistake or a hostile client is not a data-integrity event.
Evidence
Two products in production, Spoolroom one of them.
Telemetry from equipment on a customer's network
BUILD 03 / 06What it is
A daemon that runs on a customer's own network beside their hardware, speaks several vendor protocols, and streams job telemetry and health to the cloud service.
The hard part
It is outbound only. Nothing reaches into the customer's network and no port is opened, because asking a customer to forward a port is asking them to say no. It speaks WebSocket and HTTP to one hardware family and on-device MQTT to others, normalizes them to a single ingest contract, and then solves the interesting problem: attributing a finished job to the specific physical material it consumed, which the hardware does not report.
Evidence
Spoolroom's printer connection: shipping and versioned, with health reporting and connection limits by plan.
A native shell over a live web application
BUILD 04 / 06What it is
An iOS application wrapping a continuously deployed web app, with a documented contract between the two codebases.
The hard part
The shell loads the live site instead of bundling a web build, which is the opposite of the framework's own recommendation, and it is right here for one reason: the session cookie, the passkey relying-party binding, and the service worker all belong to a single origin. A bundled build would be a second origin with none of them. Old shells are retired by a server-side minimum-version check rather than by hoping people update, and the list of domains allowed inside the web view is verified in CI so it cannot silently drift.
Evidence
Spoolroom for iOS, shipping against the live service.
Release discipline across nine repositories
BUILD 05 / 06What it is
Shared CI as a small internal library: composite actions and reusable workflows consumed by nine repositories, every cross-repository reference pinned to a commit SHA, with deploy and status notification into one operations channel.
The hard part
Composite actions are preferred over reusable workflows wherever possible, because an action runs as a step inside a job that already exists while a reusable workflow queues a separate job and blocks the caller's graph. That is the usual reason shared CI feels like it slows everyone down. The failure mode worth knowing about is that a broken reusable-workflow reference does not fail the run, it never starts one, so the pull request reports no check at all and looks green. Detecting silent absence, not only failure, is part of the setup.
Evidence
Nine repositories, one shared source, every reference pinned.
The assistant on this page
BUILD 06 / 06What it is
The chat assistant on this site is ours, built the way we build them for clients.
The hard part
It runs against an evaluation suite on a mock provider, so the tests are deterministic and cost nothing to run on every change. Secret redaction and graceful behavior when a downstream service is unavailable are tested as properties rather than assumed. The page enforces a strict content security policy, so the interaction code is served as static modules with no inline script.
Evidence
Open the widget. The eval suite runs in this repository's CI.