Central Portal Shell
The same micro-frontend idea as the employee portal, four years later, for a different set of users — built to host AI features before they scatter.
- Duration:
- 2026
- Role:
- Lead Engineer
- At:
- Macquarie
Problem
The problem
Operations leadership work across a spread of separate applications, and a growing set of AI features is arriving that needs somewhere coherent to live.
Without a shell, every new capability lands as another destination to learn. That is tolerable for one application and corrosive by the fifth, and it is worst for the AI features, which get delivered as scattered one-offs bolted to whichever system prompted them rather than as part of how these people actually work.
Challenge
What made it hard
I had built this before. That is an advantage and a trap.
The advantage is knowing the pattern works. The trap is that the first build’s assumptions are invisible until they break, and the one that broke immediately was appearance. The earlier shell fused composition with a single shared component library. That library was how consistency was enforced, which felt like the architecture’s strength right up until the shell needed to serve users in a part of the organisation with its own in-house design system.
The two design systems will converge eventually. Building as though they already had would have been faster and wrong. The second constraint is subtraction: the first shell accumulated moving pieces that cost more in delivery and maintenance than they returned.
Architecture
How it is put together
A Single-spa shell owning routing, identity, policy and composition, and deliberately not owning appearance. Angular micro-frontends against that part of the organisation’s in-house design system, Python APIs, on Kubernetes. Post Trade lands here as a tenant in future, alongside the existing applications and the AI features being built for them.
Tradeoffs
What we chose, and what it cost
We chose
An appearance-agnostic shell. Composition, routing, identity and policy are guaranteed by the shell; the design system belongs to whoever owns that part of the organisation. The shell becomes reusable instead of married to one audience.
We gave up
The single shared component library that made the earlier portal consistent, and with it some enforced-by-construction consistency. Two design systems means duplicated effort until they converge. We also gave up capability by design: fewer moving pieces means fewer things the shell does for you.
Outcome
What changed
In progress
current work — no measured results yet
Design intent, not a measured result.
Lessons learned
What this changed
Anything left to convention drifts and anything enforced at a boundary holds. But what you enforce at that boundary determines how far the boundary travels. Enforce composition, identity and policy and the shell serves anyone. Enforce appearance as well and it serves exactly one audience.
The version of that I could not have written in 2021: the strength of the first design was indistinguishable from its limitation until something needed to move.
Read alongside