Enterprise software development
Enterprise systems rarely fail because the code was wrong. They fail at the seams: the integration nobody owned, the compliance evidence nobody produced, the load nobody tested for, the handover nobody wrote. For seven years we have built for organisations where those seams carry real consequences, from healthcare providers to infrastructure contractors and aviation suppliers, and we design against them from the first week rather than the last.
Where it goes wrong
None of these show up in a demo. All of them show up in year two, usually at the worst possible moment, and every one of them is cheaper to design against than to repair.
Two systems joined by a script somebody wrote once and nobody has looked at since. It works until a field changes upstream, and then a business process quietly stops working while everyone assumes somebody else owns it. We put contract tests at every boundary so a breaking change fails in CI, and we name an owner for every connection before it goes live.
The system does the right thing but cannot prove it. When an assessor asks who approved a change, what data a job touched, or why a record was deleted, the answer is a database query someone writes on the day. We make the evidence a by-product of running the system, so an audit is an export rather than a project.
Comfortable at average traffic and fragile on the single day that actually matters, whether that is open enrolment, quarter end, a product launch or a weather event. We model your real peak from your own numbers, test against it before launch, and hand you the capacity plan so you can show it internally.
The people who understood it moved on. What remains is a system the organisation is afraid to touch, so it calcifies and every change costs more than the last. Documentation written for a stranger, and architecture decisions recorded with their reasoning, are the only defence.
Where we work
Enterprise work is mostly domain knowledge. These are the industries where we have already learned what regulators, auditors and operations teams will ask for, which is time you do not have to pay us to spend.
Clinical and patient-facing systems under HIPAA, with audit trails, consent and data residency treated as architecture rather than paperwork.
Clinical scheduling, telemedicine, patient records, research data
Project, asset and workforce systems for contractors operating across sites, subcontractors and jurisdictions.
Project controls, asset registers, site reporting, subcontractor management
Configuration, compliance and supply chain systems where traceability of every part and revision is not optional.
Configuration management, traceability, supplier portals, QA workflows
Transaction, reconciliation and fraud systems that have to balance to the cent and explain themselves afterwards.
Ledgers, reconciliation, fraud scoring, reporting
High-volume messaging, routing and provisioning platforms where throughput and delivery guarantees are the product.
Messaging platforms, routing, provisioning, billing integration
Ticketing, scheduling and operations platforms that idle most of the year and then absorb an enormous spike in a single weekend.
Ticketing, scheduling, venue operations, spike capacity
Who it is for
Enterprise rigour is worth paying for when a system carries money, regulated data or operations that cannot stop. When it does not, a lighter engagement gets you there faster and for less, and we will say so.
What we build
Custom ERP and CRM systems, or the extensions and integrations around the ones you already run, so finance, operations and sales work from one set of records.
Replacing systems the business depends on but nobody dares touch, one capability at a time, with old and new running side by side until the numbers agree.
Pipelines, warehouses and reporting that give leadership one version of the numbers, fed from the operational systems rather than rebuilt by hand each month.
The systems the business genuinely runs on, designed for real load and real headcount rather than a pilot’s worth of either. Domain modelling first, then the interfaces around it.
Owned, monitored connections between systems, with contract tests so a schema change upstream is caught in CI rather than by a user.
HIPAA, SOC 2, GDPR and ISO evidence produced by the system as it runs, rather than assembled by hand in the fortnight before an audit.
SSO, role models and least-privilege access that survive a reorganisation without a rebuild, because the model reflects how the organisation actually works.
Load modelled from your own traffic, failover tested rather than assumed, and capacity that responds before anyone is paged.
Tracing, alerting and dashboards aimed at what actually breaks, with runbooks written for whoever is on call at three in the morning.
Architecture
Six rules we apply to every enterprise decision. They are unglamorous on purpose, because enterprise systems outlive the people who choose their stack.
We choose the least interesting technology that meets the requirement. Novelty is a cost your successor pays, and enterprise systems outlive the people who chose their stack.
The happy path is the easy part. We start from what happens when the dependency is down, the queue backs up, the payload is malformed or the job runs twice.
Screens are cheap to change and data models are not. We settle the domain model, the invariants and the audit requirements before anyone designs a page.
Feature flags, parallel running and staged cutover, so any change can be undone in minutes. A migration you cannot reverse is a bet, not a plan.
If an incident cannot be diagnosed from the telemetry you already collect, the system is not finished, regardless of whether it passes its tests.
Services, jobs and people get the narrowest access that lets them do their work. It is far cheaper to design in than to retrofit after a finding.
Risk
The failure mode of enterprise software is not a bad sprint. It is a two-year programme that cannot be stopped, cannot be measured and cannot be reversed. Everything below exists to make sure you are never in that position.
Capability by capability, with the old system running alongside the new one until the numbers agree. Cutover happens in slices you can stop.
For anything financial or regulated we run old and new together and reconcile the outputs, so the evidence that it works is data rather than assurance.
Progress is measured in software running in your environment against your data, reviewed at your governance cadence. Never in percentage complete on a plan.
Each phase is scoped and priced before it starts. If our estimate is wrong, that is our commercial problem, not a change request.
You can stop between phases and keep everything built so far, documented and deployable. No programme should hold you hostage.
Threat modelling, dependency and secret scanning, load and failure testing, and a written report of what we found and what we fixed.
They kept track of every detail using a centralized Gantt chart, which made it easy for everyone to follow along and stay aligned. Their project management was excellent; they consistently delivered items on time and were incredibly proactive in addressing any concerns or changes we had.
How we ship it faster
Enterprise delivery is where traditional consultancies bill the most and move the slowest, because so much of the work is specification, integration mapping, test coverage and compliance documentation. That work is well understood, time-consuming, and exactly what AI tooling drafts well. We generate the first pass and put senior engineers on the review and the architecture, which is where judgement earns its money. You get enterprise rigour without paying for an army of junior consultants. AI accelerates the work. Our engineers stay accountable for the decisions and the software that ships.
An indicative comparison, not a quote or a guarantee. Enterprise timelines depend heavily on your integrations, data, governance and approval process. We estimate every phase individually and put scope, timeline and price in writing, with a like-for-like comparison against conventional delivery, before you commit.
Compliance and procurement
We build the controls and the evidence into your system from the start. Certifying your system against a framework is your assessor’s job; our job is to make that assessment straightforward.
Protected health information, audit trails and access controls for clinical, payer and research systems.
Control evidence produced continuously by the system rather than assembled in the run-up to an audit.
Data residency, retention, subject access and deletion designed in rather than bolted on afterwards.
Cardholder data handling and scope reduction for systems that touch payments.
Vendor security questionnaires, data processing agreements and your own due-diligence process, handled as a normal part of the timeline rather than a surprise in week six.
Testing by a vendor of your choosing, with findings fixed and retested before launch, alongside our own red-team week.
Support
Response targets are written into the support agreement rather than left as aspirations, and they are met by the engineers who built the system rather than a separate support tier.
| Level | Severity | Definition | Response | Updates |
|---|---|---|---|---|
| S1 | Critical | Production down, or data at risk | 10 minutes | Hourly until resolved |
| S2 | Major | Core function degraded, no workaround | 1 hour | Every four hours |
| S3 | Minor | Defect with a workaround available | 1 business day | Daily |
| S4 | Request | Change request or question | 2 business days | On progress |
Commercial models
Enterprise engagements fail on governance more often than on engineering. We work the way your organisation already works rather than asking it to change for us.
Discovery, then each delivery phase scoped and priced before it starts. The most common model, and the one that puts estimation risk on us.
A named, senior team on a monthly engagement, embedded in your process and reporting into your governance. For continuous programmes rather than defined projects.
Multiple coordinated teams with a technical lead accountable across them, for replacements large enough to need more than one workstream.
Whichever model you choose, documentation and architecture decisions are recorded as we go, so your own team can take it over whenever you decide to.
Questions we get asked
Yes, and we expect to. Security questionnaires, data processing agreements and penetration testing by a vendor of your choosing are a normal part of our timeline rather than a surprise in week six. Tell us what your process requires at the first conversation and we will plan the engagement around it.
Both. Where your process fits a mainstream ERP or CRM, we extend and integrate the one you already run rather than replace it. Where it does not, we build the system around how you actually operate and connect it to finance, operations and reporting, so there is one set of records.
Incrementally, always. We characterise the existing behaviour with tests, stand the new capability up alongside the old one, run both in parallel while comparing outputs, then cut over a slice at a time behind a feature flag. Nothing goes live that cannot be reversed within minutes, and for financial or regulated systems we reconcile both outputs before anyone is asked to trust the new one.
From a single defined system through to multi-team replacements running over a year or more. Below roughly six weeks of work you are usually better served by a smaller firm, and we will say so. Above that, the constraint is domain fit rather than scale.
It was never only in our heads. Architecture decision records, runbooks and handover documentation are written as we build and aimed at an engineer who has never spoken to us. You can take the system in-house at any phase boundary and we will help with the transition rather than making it difficult.
We model your actual peak from your own traffic data rather than a generic benchmark, test against it before launch, and hand you the capacity plan and the results. Most clients need those numbers to convince someone internally, so they are written to be shown rather than filed.
The generated first pass is reviewed line by line by a senior engineer before it reaches your codebase, and the record of what changed and why is stronger than most conventional processes rather than weaker. For clients with data residency requirements we can restrict tooling to self-hosted models so nothing leaves your infrastructure, and we will put that in the contract.
Our own senior engineers, in-house. We do not subcontract, we do not staff programmes from a junior bench, and the people who scope your build are the people who write it and the people who answer the phone afterwards. You will meet them before you sign anything.
We give you a realistic start date at the first conversation, based on the team your programme needs. For programmes with a hard external deadline, we also tell you honestly whether it is achievable, rather than discovering it together in month four.
Related services
Related case studies
Next step
A senior engineer reads every enquiry and replies within one business day with an honest view of scope, risk and what it will take to deliver.
Certified, partnered and awarded
1/7
Discuss your project
Seven short questions. About 90 seconds. A senior engineer reads your answers before we reply. No sales sequence, no newsletter. Just a thoughtful response about what comes next.
Start here
Choose the one that comes closest.
The problem
A sentence or two is enough. Tell us what isn’t working today or what you want to make possible.
Where you are today
Choose everything that applies.
Timing
A real deadline changes how we approach the work. If there isn’t one yet, that’s useful to know too.
Scope
A range is enough. It helps us understand the right approach and team for the problem. It does not determine what we charge.
Your team
This helps us understand whether we should lead the engineering, work alongside your team, or advise your existing engineers.
Stay in touch
A senior engineer will read what you’ve shared and respond within one business day.
How would you prefer to continue?
Received
A senior engineer will review what you’ve shared and come back with the most useful next step.