Applications and platforms.
Build applications around the work people need to complete. Document the interfaces, responsibilities and decisions that future changes will depend on.
Bespoke software development and systems integration
Write the software. Understand what it runs on.
Replace manual handoffs, connect applications or improve software your organisation relies on. Our software engineering experience goes back to 2011, with the platform, data and recovery considered alongside the code.
Since 2011 An interface needs a contract, not an assumption.
Talk to an engineer Start with a scoped reviewEngineering focus
01Understand the workflow
02Build and test
03Release under control
Possible applicationOptical
Connect order, stock and fulfilment records so staff can follow progress without rekeying the same information. Validate each handoff and make exceptions visible. Explore this sector.
The code is part of a larger system.
Interfaces, data ownership, deployment and recovery deserve the same attention as features. Keep the operating environment in view from the first design decision.
APIs and integration.
Define contracts, validate inputs and handle partial completion. Test timeouts, duplicated messages and dependent-service failures.
Modernisation and delivery.
Understand the existing behaviour before rewriting it. Add test coverage, automate delivery and plan incremental changes with an agreed recovery route.
The right answer may be an integration or a focused improvement rather than a complete rewrite or an AI feature.
AI-assisted modernisation
Understand the old system. Change it carefully.
Use AI to investigate an existing codebase and prepare focused changes. Keep architecture, review and release decisions with experienced engineers.
Map the code.
Explore dependencies, interfaces and important workflows. Check the generated explanation against running behaviour and the people who use the system.
Build a testable baseline.
Capture existing behaviour and identify gaps. Test changes in an isolated branch or environment, with secrets and production access restricted.
Review and release.
Inspect generated code, test for security issues and regressions, and deploy in controlled increments. Plan rollback or recovery, including how to handle data changes.
Reference architecture
Dependable integration, layer by layer.
Clear contracts, controlled retries and a recovery plan for changes that cannot simply be undone.
Interfaces
Web, mobile and API clients, each with a clear contract.
- Web
- Mobile
- Public APIs
- How it fails
- A client relies on behaviour that was never promised, and breaks when the service changes.
- What holds it
- Each interface has a published contract, versioned and tested on every release.
Application services
Business logic with a single owner for each rule.
- Services
- Validation
- Authorisation
- How it fails
- The same business rule lives in three places, and they slowly disagree.
- What holds it
- Each rule has a clear owner, with consistent validation and authorisation at the relevant boundaries.
Integration
Versioned APIs and queues, with duplicate handling designed and tested.
- Versioned APIs
- Queues
- Idempotent handlers
- How it fails
- A message is delivered twice, and an order is created twice.
- What holds it
- Versioned APIs and queues, with duplicate handling designed and tested.
Data
Schema changes under version control and tested before release.
- SQL Server
- Migrations
- Backups
- How it fails
- A schema change goes out untested and breaks a report nobody knew depended on it.
- What holds it
- Schema changes under version control, tested against representative data before release, with a backup before every migration.
Delivery
Automated tests and staged releases with an agreed recovery route.
- CI/CD
- Automated tests
- Staged releases
- How it fails
- A release cannot be undone, so a bad change stays live while a fix is written.
- What holds it
- Automated tests on each change, staged releases, and a rollback or forward-recovery plan that accounts for data changes.
Operations
Logs and metrics that show what users actually experience.
- Structured logs
- Metrics
- Alerts
- How it fails
- Monitoring shows the servers are fine while users cannot complete their work.
- What holds it
- Structured logs and metrics that measure what users actually experience, with alerts that point to a cause.
A closer look
Good questions. Straight answers.
Can you improve an existing application?
Yes. Begin with its users, architecture and constraints, then agree the most useful changes.
How does AI fit into delivery?
It can assist investigation, implementation and testing. Engineers remain responsible for architecture, review and release.
The first step
Choose the next useful change.
Start with the application, integration or manual process that is holding work up. We scope a review of its behaviour, dependencies and constraints before agreeing the next improvement or build.
What you get. A scoped change, acceptance criteria and a plan for implementation, testing and release.
Talk to an engineer