Software Engineering
Most businesses do not need another application — they need the six they already run to behave like a single system. We design and build products end to end, and the API layer that lets them talk to each other without a nightly spreadsheet export holding everything together.
A senior engineer replies within 24 hours — not a sales rep.
Integration happens overnight, by file
A scheduled job exports a CSV, drops it somewhere, and something else picks it up in the morning. When it fails, nobody finds out until a customer does. Half your business processes now run on a delay measured in hours, and the reason is a decision made years ago to connect two systems the quickest way available at the time.
Nobody owns the space between the systems
The CRM has an owner. The finance system has an owner. The logic that decides what happens when a deal closes — which record is created where, in what order, and what to do when step three fails — belongs to nobody, lives partly in a Zapier flow and partly in a stored procedure, and has never been tested as a whole.
The same customer exists four times
Different identifiers in each system, no agreed source of truth, and a reconciliation process that is really a person with a spreadsheet. Every report needs a caveat, every merge is manual, and the question of how many active customers you have takes a day to answer and still gets challenged in the meeting.
Each problem got its own tool
A subscription for scheduling, another for approvals, another for quoting, each solving one department's problem and none of them aware of the others. The individual purchases were all defensible. The result is a stack where the integration burden and the licence spend have both quietly outgrown what building the thing properly would have cost.
The interesting decisions in this kind of project are about boundaries: what is one system and what is two, which side owns each piece of data, and what the contract between them looks like. Get those right and the code is straightforward. Get them wrong and no amount of good code rescues it.
We map the whole landscape before proposing anything
Every system in play, what data each one owns, where records are duplicated, and which processes cross boundaries. This usually surfaces two or three integrations nobody remembered existed and one system everyone assumed was retired. You get that map regardless of what we go on to build.
One source of truth per piece of data, decided explicitly
For every important entity — customer, order, product, invoice — we name which system owns it and how the others receive changes. It sounds obvious until you try to write it down for a real organisation. Doing it up front is what stops the duplicate-record problem from being rebuilt inside the new system.
Contracts published before the code that uses them
Interfaces between systems are agreed and documented as an OpenAPI or GraphQL schema first, so teams can build in parallel against a shared agreement and integrate without a discovery phase. Versioning is planned from the start, because the expensive kind of breaking change is the one you discover from a partner's support ticket.
Failure treated as a normal state, not an exception
External systems go down, rate limit you, and occasionally return success while doing nothing. We build integrations with retries, idempotency keys, dead-letter queues and a visible reconciliation view, so a failed sync is something your operations team can see and replay rather than a silent gap discovered at month end.
Pick the piece you need, or bring us the problem and we'll tell you which applies.
Browser-based products — portals, internal platforms, marketplaces, dashboards — with architecture, performance and security handled up front. There is a full page on how we approach these builds.
For the process that no off-the-shelf product models properly, and where the workarounds have become the system. Our dedicated page covers how we scope and phase this work.
A subscription product is an application plus tenancy, billing, onboarding and the instrumentation that explains churn. We build all of it — see the dedicated page for how.
Two distinct jobs that people bundle together: building APIs that your own apps, partners and customers consume, and connecting to systems written by someone else whose behaviour you cannot control. The first is a design problem, the second is mostly a failure-handling problem, and both are where multi-system projects usually come unstuck. It also covers putting a documented API in front of a legacy application so new products can be built without touching its internals.
Chosen to fit the problem — not because it's what we used last time.
Product engineering
APIs & contracts
Data & messaging
Platform & observability
Every stage ends with something in your hands — not a status update.
System and data mapping
We chart the systems you run, the data each holds, the integrations already in place and the processes that cross between them. Alongside that we work out what the software actually has to achieve commercially, because scope arguments are easier when the objective is written down.
You get: A system landscape diagram, a data ownership matrix, and a shortlist of options with an indicative cost against each.
Domain model and interface design
We model the core entities and the rules that govern them, then draw the service boundaries and specify the contracts between them. Where third parties are involved, we test their APIs early — vendor documentation and vendor behaviour diverge more often than anyone plans for.
You get: A domain model, service boundary definitions, published API specifications, and findings from hands-on testing of third-party APIs.
Build against running contracts
Two-week sprints with a deployed environment throughout. Integrations get built against sandboxes with fault injection, so we see what happens when a dependency times out or returns a partial response before your customers do.
You get: A staging environment updated each sprint, automated contract and integration tests, and code in your repository from day one.
Cutover and operational ownership
Data migration rehearsed until reconciliation is clean, a phased switchover with a rollback path, then the monitoring and runbooks that let your team operate it. We stay close through the first full business cycle, since month-end is when integration assumptions get properly tested.
You get: Production release, reconciliation reports, monitoring dashboards and alerting, and operational runbooks with handover sessions.
Logistics
Order, warehouse and carrier systems joined into one flow, with tracking events reconciled across providers instead of chased by email.
Finance
Platforms connecting to banking, payment and KYC providers, where idempotency and a complete audit trail matter more than throughput.
Healthcare
Clinical and administrative systems integrated with careful attention to access control, consent and the record-keeping a reviewer will ask to see.
Retail & e-commerce
Storefront, inventory, fulfilment and accounting kept in agreement, so an oversell or a pricing discrepancy is caught in minutes rather than at reconciliation.
Manufacturing
Production, procurement and quality systems connected to shop-floor data, giving planners numbers that reflect the current shift.
Professional services
Quoting, delivery, timesheets and billing running as one process, replacing the handoffs between four tools that a growing firm has outgrown.
Real products, in production, with real users on them.
Buy whenever a product covers the process closely enough, and we have talked clients out of builds on exactly that basis. Building is the right call when the process is genuinely how you compete, when the integration and licence burden of the tools you would otherwise assemble exceeds the build cost, or when no vendor will give you the data access you need. We work that comparison during mapping and show you the numbers behind the recommendation.
Third-party APIs, almost every time. Documentation that describes an older version, rate limits nobody mentioned, sandbox environments that behave differently to production, and vendor support cycles measured in weeks. We test the real APIs during design rather than assuming the docs, and we build the timeline around the slowest external dependency instead of the fastest internal one.
Yes, and it is usually the only responsible approach. New capability goes live area by area, with the existing systems continuing to serve everything else and data kept in sync across the transition. That period costs a little more than a straight cutover because two things run at once, and it buys away the risk that decides whether these projects succeed.
A short paid discovery produces the system map, the domain model and a scope we can price firmly for the first phase, with an informed range for what follows. We would rather do that than quote a whole multi-system programme from a first call, because the estimate would be built on assumptions about integrations we have not yet touched. You keep the discovery output whether or not you continue with us.
You do, entirely, from the first commit — repository, API specifications, infrastructure definitions and deployment pipeline all live in your accounts. Nothing runs on infrastructure we control unless you have asked us to host it, and in that case it is still your cloud account. There is nothing in the arrangement designed to make leaving difficult.
Most clients keep a monthly engagement covering monitoring, integration upkeep and a stream of iteration work, because integrations break for reasons outside your control — a vendor deprecates an endpoint, a certificate expires, a partner changes a payload. If you would rather run it in-house, we hand over documented code, runbooks and dashboards, and spend time getting your engineers comfortable operating it.
Tell us which systems you run, where the manual handoffs are, and what the business needs the software to do. A senior engineer replies within one business day with an approach and an honest range.
