Enterprise Software
Systems your operation can still change in year three.
Custom platforms, integration layers and customer-facing products, architected around the seams that will move so a business change stays a configuration change.
120+
Platforms shipped
99.95%
Median uptime
8 wks
To first release
24/7
Production support
Why builds age badly
Enterprise software rarely fails at launch. It fails in year two.
The first release is the easy part. These are the decisions that determine whether the second year is cheap or catastrophic.
The business logic is welded in
Pricing rules, tax logic and approval chains hardcoded across the application. A rate change becomes a release, a release becomes a project.
- Rules duplicated across layers
- No way to change behaviour without a deploy
- Every variation forks the code path
Integrations nobody can replay
Fire-and-forget calls between systems with no idempotency and no audit. When a batch half-fails, the only recovery is a database script and hope.
- Failures discovered by the finance team
- No replay, so reconciliation is manual
- Contract changes break silently downstream
The supplier owns the knowledge
No architecture records, no tests worth the name, and the only people who understand the system bill by the day.
- Handover was a slide deck
- Test coverage too thin to change anything safely
- IP ownership discovered to be ambiguous
Capabilities
Six shapes of engagement
From the system your operation runs on to the targeted fix on one that no longer keeps up.
Core business platforms
The system your operation actually runs on — orders, claims, logistics, underwriting, scheduling. Modelled around your process, not a vendor's.
- Domain-driven design
- Role-based workflows
- Full audit trails
Integration & middleware
The connective layer between ERP, CRM, payment rails, and the three systems nobody wants to touch. Idempotent, observable, and replayable.
- Event-driven pipelines
- Legacy protocol adapters
- Contract testing
Customer-facing products
Portals, marketplaces, and self-service apps built to the same standard as the back office, with accessibility and performance budgets enforced in CI.
- WCAG 2.2 AA
- Offline-tolerant
- Sub-second interactions
Internal tooling
Admin consoles, approval queues, and operations dashboards that replace the spreadsheet a critical process is currently held together by.
- Bulk operations
- Granular permissions
- Exportable everything
Platform modernisation
Strangler-fig migrations off ageing monoliths, delivered in slices that ship to production continuously instead of a single high-risk cutover.
- Zero-downtime cutover
- Parallel-run validation
- Rollback at every step
Performance & reliability
Targeted engagements on systems that already exist but no longer keep up — profiling, query surgery, caching strategy, and capacity planning.
- Load-test harness
- SLO definition
- Cost-per-transaction modelling
How it is put together
Four layers, each with a seam where change actually happens
The architecture is organised around what we expect to move. Everything below is delivered with tests, migrations and a decision record.
Domain core
Modelled domain
Entities and invariants named the way your business names them.
Externalised rules
Pricing, tax and approval logic in configuration, versioned and testable.
Reversible migrations
Every schema change scripted forward and backward from day one.
Audit by construction
State transitions recorded as events, not reconstructed from logs.
Integration
Idempotent handlers
Every inbound message safe to deliver twice, so replay is routine.
Contract tests
Consumer-driven contracts failing the build before they fail production.
Dead-letter handling
Failed messages visible, inspectable and replayable by an operator.
Legacy adapters
Fixed-width files, SOAP and scheduled FTP wrapped behind a clean interface.
Experience
Accessibility budget
WCAG 2.2 AA checked in CI rather than audited before launch.
Performance budget
Interaction latency gated in the pipeline, not measured after complaints.
Design system
Shared components so the tenth screen costs less than the first.
Progressive enhancement
Core journeys work before JavaScript finishes loading.
Assurance
Test pyramid
Coverage gates on the domain core, contract tests at the edges.
Pipeline gates
Dependency, secret and container scanning failing the build.
Observability
OpenTelemetry and structured logging wired from the walking skeleton.
Decision records
Every significant choice written down with the alternatives rejected.
Full IP and source ownership transfers to you, including the decision records. There is nothing in the delivery you need our permission or our people to change.
Our approach
The parts that decide whether it lasts
Architecture
Built to be changed, not just built
Most enterprise software fails on its second year, not its first release. We architect around the seams that will move — pricing rules, tax logic, approval chains — so a business change is a configuration change rather than a rewrite.
- Modular monolith first, services only where the boundary is proven
- Schema migrations versioned and reversible from day one
- Business rules externalised from application code
- Architecture decision records handed over with the source
Security & compliance
Controls designed in, not bolted on
Regulated industries make up most of what we ship, so the security posture is part of the build plan rather than a pre-launch scramble. Every release passes the same automated gate.
- SSO / SAML / OIDC and fine-grained RBAC as standard
- Encryption at rest and in transit, with key rotation runbooks
- Dependency, secret, and container scanning in the pipeline
- Immutable audit logging suitable for regulatory review
Engineering practice
You can see the work every week
No status-report theatre. You get the repository, the board, the environments, and a working demo on a fixed weekly cadence from the second sprint onward.
- Trunk-based development with automated release trains
- Preview environment per pull request
- Test pyramid enforced by coverage gates, not good intentions
- Full IP and source ownership transfers to you
Build shapes
What each kind of engagement actually costs you
Not in currency — in the things that are harder to get back. Time, internal attention, and how reversible the decision is.
| Engagement | Time to first release | Your involvement | Reversibility | Best when |
|---|---|---|---|---|
| Targeted fix | 2–4 weeks | One technical contact | High — contained change | A known bottleneck on a system you keep |
| Walking skeletonUsual start | 4 weeks | Product owner, part-time | High — small sunk cost | The architecture needs proving before scale-up |
| Core platform build | 8 weeks to first release | Dedicated product owner | Medium — phased, with gates | The system is your operation |
| Modernisation | 6–10 weeks per slice | SME access per domain | High — strangler, always shippable | A monolith too critical to switch off |
| Team augmentation | Immediate | You lead, we supply capacity | High — stop any month | You have the plan and lack the hands |
Targeted fix
- Time to first release
- 2–4 weeks
- Your involvement
- One technical contact
- Reversibility
- High — contained change
- Best when
- A known bottleneck on a system you keep
Walking skeleton
Usual start- Time to first release
- 4 weeks
- Your involvement
- Product owner, part-time
- Reversibility
- High — small sunk cost
- Best when
- The architecture needs proving before scale-up
Core platform build
- Time to first release
- 8 weeks to first release
- Your involvement
- Dedicated product owner
- Reversibility
- Medium — phased, with gates
- Best when
- The system is your operation
Modernisation
- Time to first release
- 6–10 weeks per slice
- Your involvement
- SME access per domain
- Reversibility
- High — strangler, always shippable
- Best when
- A monolith too critical to switch off
Team augmentation
- Time to first release
- Immediate
- Your involvement
- You lead, we supply capacity
- Reversibility
- High — stop any month
- Best when
- You have the plan and lack the hands
Delivery
From first conversation to production
Scope is negotiable at every boundary. Quality and the release date are not.
- 01
Week 1–2
Discovery and architecture
We map the current process end to end, agree the success metrics, and produce a costed architecture with the risky assumptions identified up front.
- 02
Week 3–4
Walking skeleton
A thin slice through every layer — auth, data, integration, deployment — running in your environment. It proves the architecture before we scale the team onto it.
- 03
Week 5 onward
Iterative delivery
Two-week increments, each ending in a production-ready release and a demo. Scope is negotiable at every boundary; quality and the release date are not.
- 04
Launch
Cutover and hypercare
Parallel run, data migration rehearsals, and a rollback plan we have actually executed in staging. Then 90 days of hypercare with the team that built it.
- 05
Ongoing
Support and evolution
An SLA-backed support retainer, or a clean handover to your own engineers — including onboarding sessions and the architecture decision record set.
What you get
What transfers to you, and when
All of it, throughout. There is no final handover event because there is nothing being withheld until one.
From week one
- Repository in your organisation, not ours
- CI/CD pipelines and preview environments
- Board access and a weekly working demo
- Architecture decision records as they are made
At each release
- Production-ready increment behind a feature flag
- Test suite with coverage gates enforced
- Runbook updates for anything operable
- Migration scripted forward and backward
At launch
- Rollback plan executed in staging, not theorised
- Data migration rehearsed against production-scale volumes
- Onboarding sessions recorded for your engineers
- Full IP assignment and dependency licence audit
Toolchain
Boring technology, deliberately
We choose tools your next engineer can already hire for. Novelty goes in the parts of the system where it earns its keep.
Application
TypeScript, .NET, Java, Python, Go. React and Next.js on the front end, React Native where mobile earns its place.
Data
PostgreSQL and SQL Server as defaults, Redis for the hot path, Kafka where ordering and replay genuinely matter.
Platform
AWS, Azure, or GCP with infrastructure as code. Kubernetes when the workload justifies it, managed services when it does not.
Assurance
OpenTelemetry, structured logging, synthetic monitoring, and error budgets agreed with you before launch.
Engagement models
Three ways to work with the build team
Most clients start with a skeleton, because it is the cheapest way to find out whether the architecture and the working relationship both hold.
Architecture sprint
Fixed fee
Two weeks, quoted up front
A costed architecture, a risk register and an honest build estimate. Yours whoever builds it.
- Process mapped end to end
- Costed architecture with alternatives considered
- Risky assumptions identified and ranked
- Build estimate with a stated confidence range
Build team
Project
Two-week increments, gated
A cross-functional team shipping production-ready increments on a fixed cadence.
- Working demo every two weeks
- Scope negotiable at each boundary
- Repository and IP yours from day one
- 90 days hypercare after launch
Support and evolution
Retainer
Monthly, SLA-backed
Ongoing support and feature delivery from engineers who know the codebase.
- Named team with an agreed response SLA
- Security patching and dependency currency
- Feature delivery from an agreed backlog
- Exit to your own engineers whenever you choose
Questions
What people ask before they commission a build
Mostly about ownership, estimates and what happens when the estimate turns out to be wrong.
Ownership and risk
Who owns the code?
You do, from the first commit. The repository lives in your organisation, not ours, and the contract assigns IP as work is delivered rather than on final payment. We also run a dependency licence audit before launch so you know exactly what you are shipping and under which terms.
What happens when the estimate is wrong?
It gets renegotiated at the next two-week boundary, in the open. We hold quality and the release date fixed and treat scope as the variable, which means the conversation is 'what ships in this release' rather than 'how much more will this cost'. Estimates come with a stated confidence range for exactly this reason.
Can our own engineers work alongside your team?
Yes, and it is our preferred arrangement. Mixed teams transfer capability as the work happens rather than at a handover event, and your engineers know things about the business that would otherwise take us months to learn. The practice standards apply to everyone equally.
Delivery
Why a walking skeleton before the real build?
Because it is the cheapest way to be wrong. A thin slice through auth, data, integration and deployment proves the architecture, the environment access and the working relationship in four weeks. If any of the three is a problem, four weeks is a much better time to discover it than four months.
Do you work from a specification?
We would rather have the problem. A detailed specification written before anyone has seen working software usually encodes assumptions that the first release disproves. Send us the process, the constraints and the success metric, and the specification emerges from increments you have actually used.
What if we want to stop?
You can, at any two-week boundary. Everything delivered up to that point is in your repository, deployable, tested and documented. That is the point of shipping production-ready increments rather than integrating everything at the end.
Tell us what the system has to do.
Send the problem, not a specification. We will come back with an architecture, a cost range, and the risks worth worrying about.