How technology is selected
The main criterion is who will maintain the system in five years. A technically defensible choice that nobody available can support is a worse outcome than a good-enough choice with a deep hiring pool and existing team familiarity.
Beyond that, the problem domain decides. Long-lived transactional systems maintained by larger teams benefit from Java’s static typing and mature enterprise frameworks. Data-oriented work belongs in Python, where the ecosystem has no equivalent. Interactive interfaces with substantial client-side state justify React; content-led pages generally do not.
| Application type | Usual choice | Reason |
|---|---|---|
| Core transactional systems | Java | Type safety at scale, mature frameworks |
| Data processing and analytics | Python | Ecosystem has no equivalent |
| Interactive dashboards and tools | React | Client-side state justifies the complexity |
| Content-led pages | Server-rendered | Indexable, faster, fewer dependencies |
| Integration and automation | Python or Java | Follows existing team skills |
What is included by default
Source in version control the client owns, automated tests covering the paths that matter, written documentation of architecture and deployment, and a handover that assumes someone else will maintain the code.
These are stated explicitly because they are the items most often descoped under time pressure, and their absence is what makes a system expensive to own two years later.
- Source in a client-owned repository from day one
- Automated tests on core paths, run in a build pipeline
- Architecture, deployment and configuration documentation
- Dependency inventory with known vulnerabilities recorded
- Handover session and defined support window after release
Modernisation of existing systems
Modernisation work starts with an assessment of what the system does, what depends on it and what its actual failure modes are, because the pressure to rewrite is often stronger than the evidence for it.
Where a rewrite is justified, incremental replacement is preferred over a single cutover: the existing system continues while functionality moves across in defined pieces, so the business is never waiting on a big-bang release.
Integration work
Integration between business applications is scoped around timeliness and volume rather than technology preference. A nightly file transfer is appropriate for data consumed the next morning, and real-time messaging for the same requirement adds complexity nobody benefits from.
Error handling and reconciliation are designed as part of the work rather than added afterwards, because interfaces that fail silently are the normal outcome when they are not.