Architecture · · 2 min read
Shipping an enterprise MVP without painting yourself into a corner
How to build the smallest thing that proves value to an enterprise client, with the seams in the right places so success doesn’t force a rewrite.
As a senior developer I led the development of a complete MVP for an enterprise client on Angular, Spring Boot, PostgreSQL and Docker. Enterprise MVPs sit in an awkward spot. The client wants speed and a demo that wins budget. They also expect it to become the real system if it works. Build too little and it collapses under success; build too much and it never ships.
Here’s how I navigate that tension.
Minimum viable, not minimum possible
“Viable” for an enterprise includes things a consumer MVP can skip: authentication that fits their identity setup, basic audit trails, role-based access, and data handling their security team will sign off on. Leave those out and your MVP never gets past procurement, however good the demo is. Everything else is negotiable.
Choose boring, proven technology
The stack was chosen for delivery speed and longevity, not novelty:
- Angular for a structured, opinionated frontend that a larger team could later extend consistently.
- Spring Boot for a mature backend ecosystem the client’s own engineers could support.
- PostgreSQL because a relational model with real constraints catches mistakes early, and it scales further than most MVPs will ever need.
- Docker so every environment — laptop, CI, staging, production — ran the same thing.
An MVP is the wrong place to learn a new framework on the client’s budget.
Should an MVP start with microservices?
I don’t start MVPs with microservices. A well-structured monolith with clear internal module boundaries ships faster, is easier to debug, and can be split later along those same boundaries if scale or team structure demands it. Most never need to be split. The ones that do are glad the seams were there.
Put the seams where change is likely
You can’t make everything flexible, so be deliberate:
- Integrations behind interfaces. Enterprise clients always change the systems you integrate with. Adapters make that a local change.
- Configuration over code for anything the business will want to tweak — thresholds, workflows, feature flags.
- Schema migrations from day one. Versioned migrations make the database evolvable instead of fragile.
Ruthless scope, visible progress
Weekly demos of working software did more for client confidence than any status report. They also made scope conversations concrete: it’s easier to say “not yet” to a feature when the client can see what they already have.
The lesson I carried forward
The best MVP architecture is the one you don’t have to apologise for six months later.
That instinct — build small, but put the seams where the future will need them — shaped every system I’ve led since, and it’s exactly how we approach FinMoon AI today.