We build complete
software products, and the layer underneath them.
We take hard product ideas from scope to shipped software: interface, backend, AI, infrastructure, security and handover. When the hard part lives below the application layer, we work there too.
See the sample artifacts
Two arms, and the loop between them.
Client product work is the offer. The software we own is what keeps the engineering deep enough to be worth buying. It is one practice, not two, and the same standard applies to both.
What we build for clients
Complete product engineering for companies that need genuine depth rather than a template: scope, interface, backend, AI, infrastructure and security, owned end to end. This is the work you can buy today, and it gets the same engineering and the same standards as everything below.
What we take onWhat we own
Systems software engineered from first principles rather than layered on someone else's product: an in-house Linux-based operating system, developer platforms, and AI-assisted tooling. Owned R&D rather than something sold today, and the reason the infrastructure and security judgment on a client build is worth paying for. Every piece carries its real stage.
See the benchWhat we share
We write about the internals: how systems actually work, what we learn building an operating system, the decisions behind the tools. Not marketing dressed as blog posts. Real technical writing for people who build things.
Read the latest
Three in-house builds.
Three different kinds of system: a product surface, a data system, and an operating-system layer. Together they are the range, not a specialism.
- / 01
Keeping an authoring model and its output in agreement
A multi-tenant content platform. What the user edits and what a browser serves are two different artifacts, and holding them in agreement is the whole problem, repeated again in permissions, domains and billing.
- / 02
Turning a question into a query you can check
A natural-language analytics system. Generated SQL is untrusted code aimed at a real database, so it is validated before it runs and shown beside its result rather than hidden.
- / 03
Holding root without handing it on
A display manager, the lowest level a build reaches. It authenticates, holds root, and starts a session that must never inherit that authority, on a machine where a failure leaves no screen to debug from.
Complete products, with depth underneath.
Product engineering is the offer. The three categories under it are the depth a hard product reaches for, and the reason the work does not stop at the application layer.
Product engineering
A complete build: scope, interface, backend, integrations, deployment and handover. The whole thing, or the part of it blocking the rest.
AI and automation
Agent systems and automation that survive real use: tool boundaries, controlled context, evaluation before a change ships.
Platform and infrastructure
The runtime a product lives on: provisioning as code, CI, rollout and rollback, and failure that surfaces instead of hiding.
Security and systems depth
Access boundaries, least privilege, hardening, and the low-level debugging that starts where application logs run out.
Designed for load, failure, and rollback.
The vocabulary the work is built in, and the three failure modes it is shaped around from the start.
Systems thinking
Processes, services, resource limits and failure modes are the working vocabulary, not afterthoughts. A system is reasoned about as the moving parts it actually has.
Security by default
Hostile input is assumed, the system fails closed, and least privilege applies from the first commit. Safety is the starting position, not a hardening pass before launch.
Failure and recovery
The design accounts for what happens when a part breaks and how it comes back. Recovery is planned for, not improvised once it is already down.
- interfacewhat people touch
- servicesthe moving parts
- datastate and flow
- runtimeprocesses and limits
- infrastructurewhat it runs on
The three it is designed around
Designed to hold under load
Latency and cost budgets are set before the build, so load has a known ceiling by design instead of becoming a surprise in production.
Designed to contain a failure
Each part is given a bounded blast radius, so one thing breaking is not able to take the rest of the system with it.
Designed to be undone
Deploys are built to be reversible and environments to rebuild from source, so recovery is a rollback rather than a rescue.
From first contact to launch, one path.
The whole arc from your side: what happens before anything is committed, then how delivery runs once it is.
- 01
A call or a written brief
You start with a call if the problem is still taking shape, or a brief if the scope and constraints are already settled. Either one reaches the same person.
- 02
A scoping document
The conversation becomes a short document: the problem as understood, what will be built, what will not, and what counts as done.
- 03agreed
Agreed before anything starts
You read the scope and agree to it. Nothing is billed until that document is settled, so the commitment is yours to make.
- 04
Built in reviewable increments
Delivery runs in stages against that scope. Each increment is something you can inspect, so progress is visible instead of promised.
- 05
Launched with its reasoning
The system goes live with its runbook and the decisions behind it. You get something you can operate and hand to the next engineer without archaeology.
Lines we won't cross.
Four refusals, stated up front so you do not have to discover them later.
We won't ship a demo that cannot survive production
If it only holds together on the happy path, it is not done. The bar is a system that keeps running under real load and real input.
We won't hide the reasoning behind a decision
Every non-obvious call ships with why it was made. You never have to reverse-engineer a choice someone made and did not write down.
We won't hand your system to an unnamed subcontractor
Work is not passed to an agency or a marketplace contractor behind your back. If a piece needs a specialist, you hear it during scoping and decide.
We won't add a moving part that cannot justify itself
Every component earns its place or comes out. Nothing stays in the system because removing it would be awkward.
You talk to the people who actually understand what you're building.
Direct communication with the engineers doing the work, and no account-manager layer in between. One accountable owner stays close to scope, architecture, implementation and handover.
Tell us what you're building.
A whole product, or the part of one that is blocking the rest. A written brief or a call both work: start with the constraint that is actually hard.