Services
What we do
Three kinds of work. They are not three product lines — they are three shapes of the same problem.
A system becomes expensive to change for a limited number of reasons. The internal structure has stopped supporting the changes the business needs. The connections to other systems were each built from scratch and none of them can be reused. Or the thing the business actually needs was never built, so the work happens in spreadsheets, email and people’s heads.
Everything below addresses one of those. Where a capability is missing from this page — and several are — it is because it belongs inside this work rather than beside it. The same applies to AI: it is used where it is the right technique inside the work, not sold as a reason to invent work around it.
Legacy Modernization
Make a system that still runs the business safe to change again — without the rewrite that would freeze delivery for two years.
Framework age is not a reason to modernize. Change cost is. A supported stack that is expensive to modify needs work; an old stack that absorbs change cheaply does not.
The problem
The system runs the business and has done for years. It is not failing. But a change that sounds small comes back estimated in quarters, releases are events that people schedule their weekends around, and a modification that ought to be local turns out to require edits in five places by someone who knows where all five are.
The usual proposal at this point is a rewrite. It is usually the wrong one.
What the work involves
- Finding where change cost actually accumulates
- Not everywhere. The expense is concentrated in specific places — a duplicated decision, a missing boundary, a deployment process — and the rest of the codebase is largely irrelevant to the problem. Modernizing the wrong parts is how these programmes consume budget without changing anything the business can feel.
- Creating architectural seams
- Boundaries so that the parts which change frequently can change independently of the parts that do not. This is the structural core of the work, and it is what reduces the cost of everything after it.
- Incremental replacement
- Replacing components behind a stable interface, in an order determined by what actually blocks the business, while the system stays in production the entire time.
- Deployment and release
- Pipelines, scripted and versioned database migrations, automated verification, and a rollback that takes minutes rather than hours. Frequently the single largest reduction in change cost available, because a release process that takes three hours and one specific person is a tax on every change the business ever makes.
- Infrastructure and cloud, where warranted
- On-premise to cloud, environment consistency. Where it is not warranted, we say so — a cloud migration undertaken to solve an architecture problem relocates the problem and adds a metered bill to it.
- Observability
- Structured logging, correlation across the request path, and alerting that fires on the failures that matter. Systems that fail silently are not stable; they are systems whose failures are being discovered by other people.
What changes afterward
Changes stop inheriting cost from unrelated parts of the system. Estimates become driven more by the requirement itself and less by architectural friction. Releases become smaller and safer. Rollback becomes a routine operational choice rather than an incident. The knowledge required to operate the system stops living in one person.
Engagement shape
This work starts with a Technical Systems Assessment, because the cost of diagnosing it wrong is high and the alternative is an expensive guess.
Delivery is organised in phases with fixed scope, sequenced so that each phase produces something usable on its own and the earliest phases reduce risk rather than add features. The system remains in production throughout.
Implementation engagements start at $25,000.
Systems Integration
Build the connections between systems — and the boundary around them that later integrations can reuse.
Automation is not a strategy if the underlying integration is broken. Automating a process built on connections that fail silently produces failures that are now also unattended.
The problem
Your systems do not talk to each other, so people move data between them by hand — and the business has quietly built a headcount cost around a missing connection.
Or they do talk, and it breaks. Each integration was built from scratch by whoever was available, none of them share anything, and when one fails the person who wrote it is the only one who can fix it. Failures are not announced; they are noticed, often by operations staff, sometimes by a customer.
Then a partner or a customer requires something the current design cannot do, and the estimate arrives at a number nobody expected.
What the work involves
- Integration architecture
- A defined contract for what an external system can do, with adapters implementing it per counterparty, so partner-specific formats never reach the core of your application. The first integration built this way carries the cost of establishing the boundary. Later integrations reuse that structure instead of rebuilding it inside the core application.
- APIs
- Designing and building the ones you expose, and consuming the ones you depend on — including the ones with poor documentation and unreliable sandboxes.
- Third-party and enterprise connectivity
- ERP, CRM, payment and credit providers, carriers and logistics, identity providers, and internal systems that were never designed to be integrated with.
- Data movement and synchronization
- Batch, streaming and event-driven, chosen according to what the business actually requires rather than what is fashionable. Most data does not need to move in real time, and the cases that do usually justify the cost clearly.
- Failure handling
- Idempotency, retries with sensible backoff, capture and quarantine of work that could not be processed, replay, and alerting that distinguishes a failure from a success that returned a default. This is the part that determines whether an integration works in production, and it is the part most often left out.
- Process automation
- Business processes that cross systems and currently move through people. Where a workflow requires extraction from documents, classification, routing or an assisted decision, a language model may be the right component inside it. That is a technique applied to a process problem, not a category of work in itself.
What changes afterward
A new partner can connect through an existing boundary rather than through the core application. Estimates become easier to explain because the reusable structural work is separated from partner-specific work. Integration failures announce themselves before a customer does. Manual data movement stops, along with the reconciliation work that existed because two systems disagreed. The integration layer becomes maintainable without an oral history from the person who originally built it.
Engagement shape
Where the scope is clear — a defined integration with a known counterparty — this can begin as implementation directly. Where the question is broader, or where several existing integrations are failing in ways nobody has diagnosed, it starts with an assessment.
A useful pattern to scope around: the integration the business has already committed to pays for the boundary, and gives subsequent integrations a boundary they do not have to build again. The structural work is not a separate project requiring its own justification — it is the shape the committed work takes.
Implementation engagements start at $25,000.
Custom Business Systems
Build the system the business actually needs, when the process currently runs on spreadsheets and institutional memory.
We will tell you when an off-the-shelf product is the right answer. It often is. Building software you could have bought is a decision that keeps costing money for as long as you own it.
The problem
Something the business genuinely needs does not exist as a product you can buy. Or it does, and it has been configured, extended and worked around so far past its intent that it now costs more than the right system would have.
The symptom is usually the same: a process that matters runs on spreadsheets, shared inboxes and institutional memory. It works because specific people make it work. It cannot be measured, it cannot be handed over, and it cannot scale without hiring.
What the work involves
- Establishing what the process actually is
- Most requests for a custom system are requests for a process nobody has written down. The first real work is separating what the business does from what it believes it does, and deciding which parts are genuinely differentiating and which are habit.
- Internal platforms and operational applications
- The systems a business runs on internally that no vendor sells, because they encode something specific to how this company works.
- Portals
- For customers, partners or suppliers, where the interaction currently happens over email and someone re-keys the result.
- Backend services and APIs
- Including the ones that will need to be integrated with later — designed so that integrating with them later is straightforward rather than another rebuild.
- Operational visibility
- Dashboards and reporting where they change a decision. A dashboard nobody acts on is a maintained liability.
- AI where it does work inside the system
- Extraction, classification, summarisation or assisted decisions embedded in a real workflow, with the output treated as something that can be wrong and handled accordingly. Where a deterministic rule would be cheaper and more reliable, the rule is the correct answer.
What changes afterward
The process runs in a system instead of in people’s heads, which means it can be changed without retraining everyone who performs it. The data exists in one place and can be trusted enough to make decisions from. The work becomes measurable. And the business can grow the process without growing headcount at the same rate.
Engagement shape
Discovery first, always — the requirement as initially described and the requirement as it turns out to be are rarely the same document, and building the first one is the most common way this category of project fails.
Delivery is phased, with something usable early rather than a single delivery at the end. Scope is fixed per phase.
Implementation engagements start at $25,000.
These are not separate purchases
A single system problem can cross more than one of these categories. A modernization may expose an integration boundary that needs repair. A new internal system may need to connect to existing software. An integration project may reveal that deployment friction is inflating the cost of every change.
That is the argument for working across the layers rather than forcing the problem into one specialty. The diagnosis matters more than the label: what the work is called is less important than whether it addresses the actual cause.