Software & Platforms
The full domain, and the other capabilities within it.
Enterprise Software
Custom internal systems where the data model and the integration surface, not the screens, decide whether the project succeeds.
What this is
Enterprise software is the custom system that runs a process no packaged product fits: claims handling, asset registers, field operations, approvals, regulatory reporting. We model the domain with your business owners, build the services and role-based interfaces around it, and connect it to the systems that already hold your data.
The hard part is almost never the user interface. It is the data model that has to survive ten years of policy change, and the integration surface where every other system in the organisation makes assumptions about your records. Projects fail when the schema is derived from the first set of screens, because the second business unit then arrives with a case the model cannot express.
When you need it
If more than one of these is true, this is usually the right place to start.
- A core process runs on a spreadsheet that one person maintains, and nobody else can change it safely.
- Your ERP or line-of-business package needs so much customisation that upgrades have become dangerous.
- The same customer, asset or employee exists under different identifiers in four systems, and nobody agrees which one is authoritative.
- An auditor asked who changed a record and when, and the honest answer is that the system does not keep that.
What the scope covers
- Domain and data modelling with your business owners, including the cases the current process handles badly.
- Service design and API boundaries, so the system can be extended without every change reaching into the core.
- Integration with the systems of record you already run, with an explicit decision about which system owns each field.
- Role-based access, approval workflow and an append-only audit trail suitable for showing to an auditor.
- Migration of existing data, including the reconciliation report that shows what moved, what changed and what did not.
What you receive
| Deliverable | What it contains |
|---|---|
| Domain model | The entities, relationships and lifecycle rules, written down and reviewed with your business owners before implementation starts. |
| Application and services | The running system — role-based interfaces, domain services, reporting and integration adapters — in your repository and your environments. |
| Integration contracts | Documented interfaces to each connected system, with ownership of every shared field stated and agreed by the teams behind them. |
| Audit and access design | Role definitions, a permission matrix and the audit-trail specification, so the evidence an auditor asks for is produced by the system rather than assembled by hand. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Cycle time for the process the system runs, measured on your own records before and after, using one definition of start and finish.
- Data quality checks — duplicate identifiers, orphaned records, failed reconciliations — reported continuously rather than at year end.
- Integration error and retry rates per interface, so a silently failing feed is visible on the day it breaks.
Questions we are asked
Should we build this or buy a product?
Buy when your process is genuinely standard and a package will not need heavy customisation to fit it. Build when the process is the differentiator, or when configuring the package has already grown into a codebase you maintain without any of the benefits of owning one. If a product exists that would do the job, we will say so early rather than bill for the alternative.
How do you avoid building another system nobody wants to use?
By modelling with the people who do the work, not only the people who sponsor the project, and by shipping a usable slice early enough that criticism arrives while it is still cheap to act on. We also insist on knowing what the current spreadsheet does that the new system must keep doing. That list is usually where adoption is won or lost.
Can it integrate with our ERP and in-house systems?
Yes, through whatever they expose — APIs, message queues, database views or file exchange — within what your licence permits. The technical connection is rarely the difficult part. Agreeing which system owns each field, and what happens when two of them disagree, is the work that decides whether the integration holds.
What happens to the data we already have?
It gets profiled before it gets migrated. Expect to find duplicates, missing mandatory fields, and records that violate rules the old system never enforced. We migrate in stages with a reconciliation report at each stage, and we agree in advance what will be corrected, what will be carried across as it stands, and what will be left behind.
How do you handle change requests during the build?
With a written change process and a visible backlog, because a system like this always uncovers requirements nobody knew at the start. What we do not do is absorb scope silently and let the schedule drift. Each accepted change carries its cost and its effect on the sequence, stated before it is accepted.
Who can maintain this afterwards?
Your team, if you want to. That is a design constraint we take seriously, and it shapes the stack, the documentation and how much cleverness we allow into the code. Handover includes a walkthrough, the decision records and a period of supervised ownership. Where you would rather not staff it, our managed services model covers it under an agreed scope.
Continue reading
API & Integration
API and integration engineering: contract-first design, gateway and broker configuration, idempotency and retry handling, tracing and per-consumer analytics.
SaaS Products
Multi-tenant SaaS engineering where tenancy, metering, entitlements and progressive release are design decisions taken before the first enterprise customer.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.