← Insights

Engineering · January 27, 2022 · 6 min read

Monorepos for Multi-App Programme Suites

Large programme platforms rarely need one mega-frontend. They need shared packages, domain backends, and a way for new engineers to run the right slice locally.

monorepodxdockerarchitecture

Humanitarian and public-sector suites accumulate portals: programme management, partner reporting, audits, offline collect, logistics. Separate git repos without shared packaging create UI drift and onboarding pain.

A monorepo with workspaces, shared UI packages, and Compose profiles lets domains stay separate while delivery stays coherent.

The goal is not purity. The goal is that a new contributor can run “just the apps they touch” before lunch.

Share UI, not domain models

Design-system packages reduce duplicated components. Domain APIs should remain bounded — shared buttons are good; shared god-models are not.

Profiles beat giant default stacks

Docker Compose profiles (or equivalent) keep full-suite reality available without forcing every laptop to boot every service.

Document the happy path for the two or three most common contributor personas.

Offline and last-mile are products

Field constraints deserve dedicated clients and sync contracts. Treating them as “the same portal with a checkbox” usually fails in connectivity-hostile environments.

Takeaways

  • Monorepos shine when many apps share UX DNA.
  • Compose profiles are a delivery feature.
  • Keep domain backends independent even when front packages are shared.

Let's talk

Ready to build something that lasts?

Partner with a senior engineering team that designs, ships and operates software businesses rely on for years.

Get in touch