Software engineering
Software engineered
around the business
New applications, platforms and internal software — or an engineered layer around the systems a company already runs. Usually both.
What gets built
Software, not deliverables.
A working application with the services, data model and permissions behind it — and a way to deploy and run it. Not a prototype, and not a team rented by the month.
New software
Built from the ground up.
- Custom applications
- Business applications
- Web applications
- SaaS platforms
- Internal operational tools
System evolution
Extended, not replaced.
- Legacy modernisation
- New interfaces over existing software
- Service layers around what runs
- Added capability without a rebuild
Backend & data
Data models outlive interfaces.
- APIs and services
- Databases and data models
- Business logic
- Authentication and permissions
- Logging and audit trails
Connected software
Interfaces are designed, not assumed.
- ERP and CRM
- Third-party APIs
- Cloud services
- File and data exchange
- Integration layers
Working with what exists
Most companies do not need everything replaced.
There is usually a database that is fine, an ERP nobody is going to change, and a process that works until it reaches software written for a different decade. The useful engineering question is which part of that actually has to be rebuilt — which is often none of it.
What already runs
ERP · databases · legacy applications · files · third-party APIs
The engineered layer
services · APIs · validation · business logic · access control · audit
What people actually use
web application · internal tool · platform · workflow
The same shape covers a new product built on an existing operational database, an internal tool that has to write back into an ERP, and a legacy application given a modern interface without touching what sits behind it. These are engineering patterns, not client case studies.
Where intelligence fits
A component, not the premise.
Automation, retrieval, computer vision, language models — engineered into an application at the point where they do something a rule cannot, with their output validated like any other input. A model added to software that was not going to work anyway does not make it work.
How the work starts
Scoped from the process, not from a wishlist.
- 01
One process, one system
Examined as performed rather than as documented, with the systems it touches named.
- 02
What should exist
Architecture, data model, and what to leave alone. Sometimes the answer is that less should be built.
- 03
Engineered
Built, reviewed and tested against something other than production.
- 04
Run
Deployment, access, logging and a route for changes after handover.
The languages, databases and platforms behind this, and the practices that keep it running after handover, are set out under technology & engineering.
A process, a system,
a problem or a product idea.
Bring one of them. We work out what should be built — and what should not — with the engineers who would do the work.