We take on software that has to be correct under load and stay changeable afterwards. Most of our work is backend and infrastructure, and a large share of it touches money. Buy it as a delivered project, or as engineers embedded in your own team.
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.
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.
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.