Application Engineering

When the existing architecture cannot absorb the next requirement, when the runtime is unsupported, or when the engineering team can no longer maintain the codebase. Otherwise: refactor. Most rewrites that get proposed should have been strangler-fig migrations — we keep the original system running, route new functionality through a new architecture, and migrate bounded contexts one at a time. The pattern of "full rewrite that quietly turns into a programme failure" is well-attested across the industry; we have rescued enough of them to be cautious.

The mix matches the estate. React (often via Next.js with the App Router) is our default for new frontend work. .NET / ASP.NET Core and Java Spring Boot are the back-end defaults, chosen against the existing stack. Python comes in for data and AI-adjacent services. Mobile is React Native or Expo for cross-platform; native Swift or Kotlin when the workload demands it. We do not have a stack preference we drag into every engagement; we have a quality bar.

Yes — including offline-capable field applications, which is a common shape in our regulatory and inspection work. React Native for cross-platform, native when latency or device capability requires it, and the back-end synchronisation patterns that let field teams operate without connectivity. We have shipped mobile platforms for government inspection workflows that handle gaps of days between syncs.

A focused application replacement is six to twelve months. A modernisation programme that touches multiple systems usually runs eighteen to thirty months in phases. The slow part is rarely engineering — it is data migration validation, user training, change management, and the parallel operation period. We design the timeline to make that visible up front rather than discovering it in month nine.

Yes. We start with an architecture and code-quality audit, distinguish what is salvageable from what needs to be replaced, and produce a remediation plan with a defined cutover horizon. Programme rescue is one of our most common engagement types — see our advisory practice for the standalone version of this work.

WCAG 2.1 AA is the default target for citizen-facing and government applications; Core Web Vitals budgets (LCP, CLS, INP) are enforced in the build pipeline, not measured post-launch. Both are designed in from the first sprint. Retrofitting accessibility at the end of a programme is more expensive than designing for it from the start; the industry has known this for a long time and continues to ignore it.