Move your product forward without breaking your customers

Two figures, both agreed before anyone writes code. The build is a written scope with dates against it, not a day rate, so anything you add later is a separate quote you approve first. Keeping it running afterwards has its own monthly figure, sized to how much we look after. Where the code is old enough that nobody inside your company can say what a part does, we sell a short paid review first, and that written review is yours whatever you decide next. The call that starts it all takes 30 minutes and costs nothing.

Almost never, and we do not open with it. A product sold for years carries behavior that particular customers depend on and that nobody wrote down. Throw it away and you rediscover all of it through angry tickets. We work in your repository, your branches and your build checks, and our changes go through the review your team already runs. Sometimes one part has to go: a record structure written for a single installation, or a platform whose supplier has stopped patching it. We price that part on its own, agree it with you first, and replace it behind the screens people already use.

First we map it: who is on what, what was customized for them, and which of those customizations can move into settings instead of staying a branch. Then the upgrade is built as steps, each one releasable and each one reversible. Data changes are practiced against a copy of a real customer database before they are run for real. The first release goes to a pilot account, gets watched through a month of normal work, then widens across the rest. The aim is an upgrade your support team can run on a Tuesday afternoon, not one that needs an engineer on a call with every account.

Narrowly, and behind a switch your account managers control. We pick two or three jobs where the rules are already written down, limit what the feature can reach to the tools those jobs need, and require a person to decide anything that moves money or changes a record a customer may have to justify to an auditor. Everything it does is recorded. Because one feature has to suit accounts with different rules, the switch is per customer, and an account that says no never sees it. Our fintech support assistant is built this way. We read its numbers every month and widen it only when they hold.

Yes. It changes what gets built, not whether we take the job. Install and update routes are designed for every environment you actually ship into, so a fix can reach an installation at a customer's site without somebody traveling there. For AI features it matters most: the model, the data and the records can all stay inside that customer's own boundary where their contract demands it. We work in your accounts rather than ours, so our access can be withdrawn at any moment, and we develop against masked or made-up records rather than real customer data.

We do, across every version it is installed on, which for a vendor is the harder half of the job. That means alerts on the environments we can see, fixes inside agreed times, and security patches applied to each release line still under support, not only the newest. Once a month you get a written report: what changed, what the numbers did and the next step. One monthly figure, sized to what we look after, and the software we run stays up. Your repositories, your cloud accounts and written instructions stay yours, so ending the arrangement costs only the notice period.