All articles
April 2, 20261 min read

Designing Multi-Entity Enterprise Platforms

Lessons from building investment, ERP and operations platforms that serve many business entities from one secure, auditable codebase.

System Design
PostgreSQL
Security

Enterprise platforms rarely serve a single team. They serve many entities — branches, departments, funds, plants — each with its own data, rules and permissions. Getting that foundation right early saves enormous pain later.

Model the domain, then the entity boundary

Start with a clean domain model, then decide how entities partition it. A normalised PostgreSQL schema with explicit foreign keys keeps relationships honest and reports trustworthy. Resist the urge to denormalise before you have a measured reason.

Security is a first-class concern

Two patterns I apply on every build:

  • JWT authentication with token black-listing on logout.
  • Role-based access control down to the page and action level, so the same platform safely serves operators, managers and auditors.

Layer an audit trail over master-data changes from day one. When finance or compliance asks "who changed this and when", you'll have the answer.

Make ingestion bullet-proof

Real enterprises run on spreadsheets. Validated Excel pipelines — schema checks, clear error reporting, idempotent imports — turn messy human input into reliable data without silent corruption.

Keep it reproducible

Stateless services behind a reverse proxy scale horizontally. Environment-based configuration (dev / UAT / prod) means the same artifact runs everywhere. Lock financial periods so closed data stays immutable and reports remain auditable.

These aren't flashy features — they're the quiet decisions that determine whether a platform is still maintainable years on.

Building something similar?

I help teams architect and ship enterprise software end to end.

Let's talk