Enterprise MVP, end to end: from the first workshop to production
The map for a seven-part series: how I take an enterprise MVP from requirements gathering through architecture, database design, development, CI/CD and deployment on Google Cloud, and the artefact each phase must leave behind.
Series · Part 1 of 7Enterprise MVP, end to end
- Enterprise MVP, end to end: from the first workshop to production
- Requirements gathering for an enterprise MVP: what to ask, what to write down
- Architecture design for an enterprise MVP: C4 diagrams, a modular monolith and the seams that matter
- Database design for an enterprise MVP: from domain model to the first PostgreSQL migration
- Developing an enterprise MVP with Flask and React: structure, workflow and tests
- CI/CD for an enterprise MVP: GitHub to Cloud Build to Cloud Deploy
- GKE or Cloud Run? Choosing where an enterprise MVP runs, and the go-live checklist
On this page · 6 sections
Most writing about software delivery covers one phase in isolation: how to gather requirements, how to design a schema, how to set up a pipeline. The hard part of leading a delivery is the hand-offs between phases, where a decision made in week one quietly sets the cost of week ten.
This series walks through one enterprise MVP from the first stakeholder workshop to a production deployment, phase by phase, with the artefacts I expect each phase to produce. It’s the process I’ve refined over a decade of shipping systems for enterprise clients and, more recently, as a founder.
A note on the example
The project in this series is illustrative. It’s modelled on the kind of enterprise MVPs I’ve led, but the domain, names and numbers are invented so I can show complete schemas, code and pipelines without exposing anyone’s system. Where I state an opinion, it’s mine and comes from real projects. Where I show a config file, it’s a working pattern rather than a copy of a client’s.
The project: a supplier onboarding portal
A mid-size manufacturer onboards a few hundred new suppliers a year. Today it runs on email, spreadsheets and a shared drive:
- Procurement invites a supplier and chases them for documents.
- The supplier emails tax registrations, bank details, certifications and insurance certificates.
- Compliance checks the documents; finance verifies the bank account.
- Someone types the approved supplier into the ERP by hand.
Onboarding takes three to six weeks, nobody can say where a given supplier is stuck, and the audit team can’t prove who approved what. The MVP replaces that with a portal: suppliers fill in a guided application, reviewers approve or reject each step, every action is audited, and approved suppliers sync to the ERP automatically.
It’s a good teaching example because it touches everything an enterprise MVP has to get right: single sign-on, role-based access, an audit trail, document storage, a workflow with states, and an integration with a system you don’t control.
What are the phases of an enterprise MVP?
Six phases, each ending with an artefact that someone other than the author signs off:
| Phase | Artefact | Signed off by |
|---|---|---|
| Requirements | Scope document: user stories, acceptance criteria, non-functional requirements, what is out of scope | Business sponsor, security, IT |
| Architecture | C4 context and container diagrams, a handful of architecture decision records (ADRs) | Client architecture board or CTO |
| Database design | Entity-relationship diagram, data dictionary, first versioned migration | Tech lead, data owner |
| Development | A demoable build every week, an OpenAPI contract, a test suite that runs on every pull request | Product owner at each demo |
| CI/CD | A pipeline that takes a merged commit to a staging environment with no manual steps | Tech lead, client IT operations |
| Deployment | Runtime decision, runbook, go-live checklist | Client IT operations, security |
The phases overlap; this isn’t waterfall. Development feeds back into requirements every week, and the pipeline is built in the first sprint rather than the last. But the artefacts are sequential: you can’t meaningfully design the schema before you know the entities, and you can’t choose a runtime before you know the availability and latency targets.
How long does an enterprise MVP take?
For a system this size, with a team of four to six engineers, my planning shape is 10–12 weeks:
- Weeks 1–2: discovery. Workshops, process mapping, the scope document.
- Week 3: architecture and data design. Diagrams, ADRs, schema, and the first deploy of an empty app to a real environment.
- Weeks 3–10: build. Weekly increments, each demoed to the client on a staging environment.
- Weeks 9–12: hardening and go-live. Security review, load test, data migration from the spreadsheets, user acceptance testing, cut-over.
The single most useful scheduling decision is deploying something to a production-like environment in week three. Every week after that, “deployment” is a non-event instead of a project.
Why Flask, React and PostgreSQL on Google Cloud?
Choose boring, proven technology for an MVP. This stack is boring in the best way:
- Python Flask for the API. It’s small, explicit, and easy for the client’s own team to own after hand-over. Its Blueprints map cleanly onto the modules of a modular monolith.
- React for the frontend. It’s the safest hiring bet in most markets and has a mature component ecosystem for forms-heavy enterprise UIs.
- PostgreSQL for the data. Real constraints, transactions,
jsonbwhere flexibility is genuinely needed, and it scales far beyond what an MVP will ask of it. - Google Cloud: Cloud SQL, Cloud Run, Cloud Storage, Secret Manager, and a delivery pipeline of GitHub → Cloud Build → Cloud Deploy.
None of these choices is clever, and that’s the point. An MVP is the wrong place to learn a new framework on the client’s budget.
The series
- The map (this post): phases, artefacts, timeline.
- Requirements gathering: stakeholders, workshops, user stories, and the non-functional requirements that drive everything after.
- Architecture design: C4 diagrams, a modular monolith in Flask, integration seams, and decision records.
- Database design: from domain to ERD, PostgreSQL modelling choices, audit trails, and migrations from day one.
- Development: repo layout, contract-first APIs, the approval workflow in code, and how we test.
- CI/CD: GitHub → Cloud Build → Cloud Deploy, with approvals, migrations and rollbacks.
- Deployment: how to choose between Cloud Run and GKE, and the go-live checklist.
If you want the shorter version of the philosophy behind all of this, start with Shipping an enterprise MVP without painting yourself into a corner.
Every phase should leave behind something a stranger could pick up and continue from.