User fit
Does the choice support the tasks, access needs and environments of the people using it?
Technology
Choose for fit. Engineer for change.
Our default is the least complex technology that can meet the required security, scale, usability and operating model.
Selection principles
A technology decision is an operating-model decision.
Features and familiarity matter, but they are not enough. We examine who will use, own, secure, support and eventually change the choice.
System fit
Can it work with the existing data, identity, integration and security boundaries?
Operating fit
Can the responsible team deploy, observe, support and change it with confidence?
Exit path
Can the organisation evolve or replace it without an unreasonable dependency or migration cost?
Technology ecosystem
A practical toolkit, not a prescribed stack.
These technologies describe the ecosystem in which we can shape delivery. The final choice follows the service context, constraints and skills of the team that will own it.
Web and product
Accessible interfaces and maintainable product foundations.
- TypeScript
- React
- Next.js
- Angular
- HTML
- CSS
- Tailwind CSS
Backend and integration
Services and interfaces shaped around domain and ownership boundaries.
- C#
- .NET
- Node.js
- Python
- REST
- Event-driven systems
Data
Data stores and analytical capabilities chosen for the access pattern.
- PostgreSQL
- SQL Server
- Redis
- Search
- Analytics
Cloud and delivery
Repeatable Azure environments with observable delivery paths.
- Microsoft Azure
- Bicep
- GitHub Actions
- Azure DevOps
- OpenTelemetry
Mobile
Native and cross-platform delivery matched to device requirements.
- Swift
- Kotlin
- React Native
- App Store
- Google Play
Quality and design
Product decisions supported by testing, accessibility and design evidence.
- Playwright
- Vitest
- xUnit
- Figma
- WCAG 2.2
Product and technology names identify relevant tools and ecosystems; they do not imply vendor partnership, endorsement or a prescribed architecture.
Modernisation sequence
Change the system without losing the service.
Modernisation is managed as a sequence of operational decisions, not a single platform switch.
- 01
Map the estate
Understand users, service boundaries, dependencies, data and operational risk.
- 02
Choose the seams
Identify where change can be isolated and where interfaces need to become explicit.
- 03
Move in increments
Deliver reviewable slices with rollback, migration and coexistence considered.
- 04
Observe and improve
Use service evidence to refine cost, reliability, performance and supportability.
Cross-cutting requirements
Quality is part of the architecture.
A technically valid system can still fail its users or operators. These concerns are considered with the design, not reserved for the release gate.
Accessibility
Semantic interfaces, keyboard use, focus, contrast and assisted-technology needs.
Security
Threats, identity, data handling, dependencies and secure operating boundaries.
Observability
Useful telemetry, service health, failure signals and ownership of operational response.
Changeability
Clear seams, automated checks, migration paths and reviewable deployment increments.
Start with clarity
Make the next technology decision explainable.
Bring the service context, the current estate and the constraint. We’ll help identify a practical route forward.