We take on software that has to be correct under load and stay changeable afterwards. Most of our work is backend, infrastructure and the migrations between them, and a large share of it touches money. Buy it as a delivered project or as engineers embedded in your own team — or start with a consultation that leaves you free to walk away from any vendor, us included.
APIs, data models, background processing, and the operational surface around them. Schema design and migrations treated as first-class work rather than an afterthought.
Billing, ledgers, payments and reconciliation. The domain we know best, because we operate one ourselves and carry the consequences of getting it wrong.
Operator consoles, customer-facing products, and the interfaces that make a complex system usable without lying about what it is doing.
Pipelines, environments and the infrastructure under them — defined in code, rebuildable from the repository, and owned by your team rather than by whoever remembers the console clicks.
Moving a running system — to another cloud, off a legacy platform, onto a new schema or a different payment processor — without asking your customers to notice. Every cutover ships with its rollback.
Inheriting a codebase someone else wrote, understanding it honestly, and making it safe to change. Often the most valuable thing we do.
Switch tenant and the list changes. Then ask for a row by id across the boundary — the answer is not-found, not forbidden, because the row was never in the result set to be refused.
The difference is not pedantry. A 403 tells the caller the id is real, which is all anyone needs to enumerate another tenant’s book one guess at a time.
| in_7f2a | Halden Grid | paid | $49.00 |
| in_9c41 | Ostara Foods | open | $1,299.00 |
That id is real, and it belongs to the other tenant. The answer is not-found rather than forbidden — a 403 would confirm the id exists, which is an oracle for enumerating someone else's invoices.
Lock-in is rarely a contract. It is a proprietary API threaded through the code, data in a format only one vendor reads, and infrastructure that exists only as clicks in a console. We find those, price what leaving would cost, and fix the ones worth fixing.
You get a written map of every external dependency, what it would take to leave each one, and the changes in the order we would make them — yours to act on with us or without us.
Same engineers, same standard. What differs is who holds the priorities.
We take a problem, agree what done means, and carry it there. The risk of getting the shape wrong is ours.
Engineers who work to your board and your priorities, inside your repo and your review process, holding to the engineering standard on this page while they do it.
Four stages, and we tell you which one you are in.
You describe the problem. We tell you plainly whether it is something we should take on, and what we would want to know before quoting.
A written scope with the unknowns named as unknowns. We would rather show you the risk early than discover it together at week six.
Working software in front of you throughout, not at the end. Whatever we assert about progress, you can open and check.
Either we hand it over with the context needed to own it, or we keep running it. Both are fine; being vague about which is not.
Our own product is the honest sample. Same engineering, with nobody else to blame for the decisions.