Engineering, grouped by the problem it solves.

Starting points are published on the pricing section of the home page, in the currency and rates that apply where you are — automation and internal tools at the low end, a first working version of a product in the middle, ongoing engineering as a monthly amount. Those are floors rather than quotes: what your project costs depends on scope, and we agree a fixed price against a written scope before you commit to anything. Everything is negotiable — if your budget is below them, say so and we will tell you honestly what is possible within it rather than pad the number or turn the conversation down.

A small automation or internal tool can be one to two weeks. A first working version of a product starts around four weeks and grows with scope — a larger platform is closer to three months. We break the work into short cycles with something usable at the end of each, so you are never waiting months to find out whether it is going the right way.

You do, completely, including the repository, the infrastructure configuration and the documentation. We hand over accounts in your name rather than ours. There is no licence, no lock-in, and nothing that stops another engineer picking it up.

That is a normal place to start and a good reason to talk early. Working out the right shape of a solution is the first thing we do anyway. Often the honest answer is that you need less software than you thought, or a different thing entirely, and we would rather tell you that than sell you the wrong build.

Your choice. We can hand over completely, stay on for a fixed monthly amount covering fixes, security updates and small changes, or return for defined pieces of work as you need them. Nothing is a locked contract, and nothing in the codebase depends on us staying.

Yes. Most of the work is remote regardless of location, and we are used to running projects across time zones with written updates and a running environment you can check any time rather than status meetings.

Often, yes. We start with a short review of the existing code and infrastructure and tell you honestly whether it is worth continuing or whether rebuilding a part of it will cost less than maintaining it. Inheriting a system is normal work, not a special case.

Tell us the number. A smaller budget usually means doing less rather than doing it worse — one workflow instead of five, one platform instead of two, the part that pays for itself first. We would rather scope something real to your budget than turn the conversation down or quietly cut corners to hit a figure.

Yes, before any detailed discussion if you prefer. We do not share client information, publish client names without permission, or use your project as a case study unless you have agreed to it.