Mobile applications
iOS and Android for staff in the field and for customers. Offline behaviour, store review and release management are part of the work rather than surprises after launch.
Services
Systems integration and modernisation.
Two systems that do not talk, so a person moves data between them by hand. Or an application that still works and which nobody wants to touch. Both are common, both are fixable, and neither usually needs a rewrite.
Where this usually starts
It is described one of two ways on the first call. Either "these two systems don't talk, so somebody re-keys it every day" — and that somebody is expensive, bored, and occasionally wrong. Or "this application still works but nobody wants to touch it" — which means the person who wrote it has gone, and every change is quoted with a risk premium.
What this is
Integration work is unglamorous and it is one of the most common real reasons a client calls. Very few firms list it as a service, which says more about how it is perceived than about how much of it there is. It covers connecting systems through their APIs, moving data between platforms on a schedule, migrating data from one system to another once and correctly, and removing the manual transfer step that currently sits between them.
Modernisation is the same instinct applied to an ageing application: bring it up to something maintainable without stopping the business or betting it on a rewrite. In practice that usually means putting a boundary around the old system, building new capability outside it, and moving responsibility across one piece at a time until what remains is small enough to retire quietly.
How we approach it
What we think doing this well requires.
Strangle rather than replace
Put a boundary in front of the old system, route through it, and move one capability at a time to the new implementation. Every step is shippable, reversible, and small enough that a bad week is a bad week rather than a bad quarter.
The integration is the error handling
The happy path is an afternoon's work. The value is in what happens when the other end is down, slow, rate-limiting you, returning yesterday's data, or accepting the request and silently doing nothing with it.
Idempotency, retries and replay
Every transfer can be run twice without doing damage, retried when it fails, and replayed for a past date when somebody discovers a gap. Without those three properties an integration becomes a thing people are afraid to restart.
Migrations are rehearsed
A data migration is run against a copy, checked against agreed counts and totals, and rehearsed end to end before the real one. The cutover has a written plan and a way back, decided while everybody is calm.
Document what you found
Working through an old system produces knowledge nobody currently has. That knowledge is written down as it is discovered and handed over, because the next person to open that codebase should not have to repeat the archaeology.
A straight answer
A full rewrite is usually the wrong call.
The argument for a rewrite is always the same: the old system is a mess, nobody understands it, and a clean start would be faster. The problem is that the mess is largely undocumented business logic — a decade of corrections, exceptions and regulatory adjustments that nobody wrote down because they were applied one at a time. A rewrite discards all of it and then rediscovers it, in production, one angry phone call at a time. Meanwhile the old system still needs maintaining, so you are paying for two.
It is the right call in a small number of cases, and they are recognisable: the platform is genuinely end of life and no longer receives security fixes; the system is small enough that its behaviour can actually be enumerated; the business process it encodes is being replaced anyway, so the logic inside it has no further value; or a hard external constraint — a licence ending, a compliance deadline — removes the option of incremental work. If your case is one of those, we will say so. If it is not, we will tell you that too, even though the rewrite is the larger contract.
What you get
Everything on this list is a deliverable, not an extra.
- The integration itself, with monitoring and alerting on the parts that fail quietly
- A written description of each interface: what moves, when, in what format, and what happens on failure
- Idempotent, replayable transfers with a documented way to re-run a past period
- Migration scripts, reconciliation counts, a rehearsed cutover plan and a rollback path
- Documentation of the legacy behaviour discovered along the way
- Source code in your repository, and credentials in your accounts
Fit
Whether this is us.
Most unhappy projects were mis-scoped at the start rather than badly built. It costs nothing to be straight about this now, and it saves us both a call.
Best suited to
- Somebody on the payroll spends part of every day copying data between two systems
- An application still does its job but the people who built it have gone
- You are moving off a platform and need the data to arrive intact and reconciled
- A rewrite has been proposed and you would like a second opinion from somebody who does not benefit from the answer
Probably not us if
- The other system has no API, no export, and no supplier willing to discuss it. Screen-scraping somebody else's product is fragile, and we would rather not sell you something that breaks on their next release
- You want the old system left exactly as it is while new behaviour is added to it. At some point something has to change, and pretending otherwise wastes the budget
- The decision to rewrite has already been made politically and the technical review is a formality. We would only tell you what you have decided not to hear
Related
Next to this.
AI agents and LLM features
Applied to work people currently do by hand: reading documents, sorting queues, drafting replies. Built into the software you already run, with a person approving anything that matters.
Healthcare software
Where this work goes deepest: claims and billing workflows, data exchange, reconciliation, audit trails and the formats healthcare actually runs on.
Tell us what you are trying to build.
Describe the problem in your own words. If we are not the right firm for it, we will say so.