Six-application service estate

Six applications had grown up separately: a member application, library and document services, telephony, and a public information site among them. Each worked, but each was its own island — separate logins, separate release routines, and no single team holding the whole. The cost of that fragmentation lands on both sides: members re-authenticate across services that should know them, and every change is a bespoke deployment.

The tempting answer is a rewrite: one framework, one codebase, one release. It is also the answer that most often fails, because a rewrite has to reach feature parity with six systems that are all still running and all still changing before it delivers a single new thing — and the organisation has to keep paying for both estates until it does. The cheaper path is to leave working software where it is and unify only what genuinely has to be shared.

Rather than force a single framework, we treated the six as one estate maintained across two — PHP/Laravel where it already lived, React/Next.js where the surface warranted it — and unified the parts that actually need to be shared:

• A shared identity, so a member is one member across the estate.
• A common deployment path, so releasing any of the six follows the same routine.
• One team owning all six, so the applications evolve together instead of drifting apart.

Maintaining an estate you did not originally write is review-heavy by nature. The pipeline suits it: agents handle the repetitive changes that ripple across six codebases, while senior engineers hold the architecture — the identity layer and the deployment path are the decisions everything else depends on, so they stay in human hands.

Inherited code also changes what "done" means. A change is not finished when it works; it is finished when the other five applications have been checked against it, the shared identity still behaves, and the deployment path has carried it without a bespoke step. Holding that standard across an estate is unglamorous and is the entire reason six separate applications can be run by one team instead of six.

All six applications run in production as a maintained estate rather than six independent liabilities.