Services
Framed as problems solved rather than technologies used. Each says who it suits — and who it doesn't, which saves us both a call.
Product engineering, end to end
Backend, frontend, and the AI in between — from a problem that isn't yet a specification to something running in production.
Most engagements start with a problem that hasn't been written down properly yet. Turning it into a specification is part of the work, not a prerequisite for it.
We take that through to production: the data model, the service, the interface, the deployment, and the boring parts — migrations, backups, error paths, the runbook — that decide whether it's still working in a year.
Good fit: you have a real operational problem and no team to hand it to. Poor fit: you need staff augmentation into an existing team's backlog.
AI that earns its place
Agents and LLM features where they beat the alternative — and a straight answer when they don't.
The useful question isn't "where can we add AI." It's "which decisions are currently made by a person reading unstructured information, and would a machine do it acceptably well."
Sometimes the answer is yes and the leverage is enormous. Often the honest answer is that a query, a rule, or a form would do the same job for a fraction of the cost and none of the failure modes. We'll tell you which one you have.
When it is the right tool, we build it so the model is replaceable: capabilities behind domain interfaces, structured outputs validated, spend metered, and a human in the loop wherever a mistake would be expensive. Frameworks in this space have a shelf life measured in months — the architecture has to assume that.
Good fit: a workflow with real judgement in it, and tolerance for being told it doesn't need a model.
Backends that hold up
Go and Postgres systems built so the invariants live in the database, not in whoever remembers them.
Most systems that get into trouble didn't get slow — they got uncertain. Nobody can say what states are possible, so nobody can safely change anything.
The fix is unglamorous: put the constraints where they can't be bypassed, keep the module boundaries honest, and make the migration path a first-class part of the design rather than something discovered at deploy time.
That's Go, Postgres, schema-per-module, durable jobs that survive a restart, and enough observability to answer "what happened at 3am" without guessing.
Good fit: a system that works but nobody dares touch, or a new one that will carry money or compliance.
Discovery and scoping
A short, paid engagement that turns a vague problem into a plan you could hand to anyone — including someone else.
The most expensive thing in software is building the wrong thing competently.
Discovery is a fixed-scope engagement: we interview the people who actually do the work, map what exists, and come back with a written plan — the problem stated precisely, the approach, the trade-offs we rejected and why, a phased build order, and an honest range on effort.
It stands on its own. You can hand the output to another firm, to an internal team, or back to us. That's deliberate: a plan you can only execute with its author isn't a plan, it's a hostage.
Good fit: a project big enough that guessing wrong is costly, and stakeholders who don't yet agree on what it is.
Not sure which one you need?
That's usually a sign discovery is the honest place to start.