Services — 06
Ongoing Engineering
Software is not finished when it ships. Continuous work on an existing system — new capability, dependency and security updates, performance, and fixing what the first version got wrong.
The problem
The build gets planned and budgeted. The years afterwards usually do not. Dependencies age into security problems, the person who understood the system leaves, and small changes start taking a surprisingly long time because nobody wants to touch it.
How we approach it
We start with a review that tells you honestly what state the system is in and what it will cost to keep. Then continuous, small, tested changes rather than occasional large risky ones. If a part is genuinely cheaper to replace than maintain, we will say so and show the arithmetic.
What changes
A system that stays current instead of quietly decaying, and changes that stay cheap because nothing has been allowed to rot.
The things people ask before getting in touch.
If yours is not here, ask it directly — we would rather answer than have you guess.
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.
Need ongoing engineering?
Tell us what you are dealing with. We will come back with how we would approach it, or tell you honestly if this is not the right fit.