Building software is expensive. Buying software is constraining. The right call depends on where your advantage lives.
The decision in one sentence
If the workflow is the product, build. If the workflow is commodity plumbing, buy.
Three paths
1. Buy / configure
Use existing SaaS (CRM, project tools, portals) and configure.
Best when: needs are standard, team is small, learning speed beats uniqueness.
2. Assemble (no-code / low-code)
Connect tools with Zapier, Make, Airtable, Retool, etc.
Best when: internal ops tools, prototypes, or validating demand before engineering investment.
3. Build custom MVP
Engineer a proper multi-tenant application.
Best when: differentiation, data model complexity, or long-term product ownership justify it.
| Factor | Buy | Assemble | Build |
|---|---|---|---|
| Time to first users | Days | Days–weeks | Weeks–months |
| Fit to unique workflow | Low–medium | Medium | High |
| Ownership of UX & data | Low | Medium | High |
| Long-term cost control | Subscription risk | Tool sprawl risk | Engineering ownership |
| Scalability ceiling | Vendor limits | Integration fragility | Your architecture |
A practical scoring model
Score each factor 1–5 for your situation:
- Differentiation — Is this workflow how you win deals?
- Complexity — Do generic tools force daily workarounds?
- Compliance — Do you need audit logs, residency, or custom access?
- Frequency — Will teams use this daily for years?
- Monetization — Will this become a paid product?
Heuristic: average ≥ 4 → lean build. Average ≤ 2 → buy. Middle → assemble to learn, then decide.
What a real SaaS MVP includes
Minimum viable usually means:
- Auth + organization tenancy
- One core object workflow (create → update → complete)
- Admin visibility
- Billing or manual invoicing path
- Basic email notifications
- Error monitoring and backups
It does not require: AI features, mobile apps, public APIs, or five user roles on day one.
Cost reality
| Approach | Typical first 90 days |
|---|---|
| Buy | Low cash, ongoing seats |
| Assemble | Low–medium, brittle ops |
| Build MVP | Higher cash, owned asset |
Treat build cost as buying an option on a productized business — not as a website redesign.
Pros
- +Build: full control of UX, data, and roadmap
- +Buy: fastest path to operational coverage
- +Assemble: cheapest way to test demand
Cons
- −Build: higher upfront cost and ownership burden
- −Buy: vendor lock-in and workflow compromise
- −Assemble: fragile glue that breaks under growth
Step-by-step decision process
Write the core job-to-be-done
One sentence: who does what, how often, and what “done” means.
Map mandatory constraints
Compliance, integrations, offline needs, languages, and data residency.
Pressure-test off-the-shelf options
Timebox 3–5 days configuring the best existing tool. Document every workaround.
Estimate assemble vs build
If workarounds exceed ~20% of weekly time, custom usually wins within a year.
Define MVP scope as a workflow, not a feature list
One happy path. Everything else is backlog.
FAQ
FAQ
Should I build or buy a SaaS MVP?+
Build when the workflow is your differentiator and off-the-shelf tools force painful workarounds. Buy when the problem is commodity and speed-to-market matters more than uniqueness.
How long should a SaaS MVP take?+
A focused SaaS MVP with one core workflow, auth, and billing usually takes 4–12 weeks with an experienced product engineering team — longer if integrations or compliance dominate.
Related resources
What Is a Client Portal? Definition, Architecture, and When You Need One
A clear definition of client portals, how they differ from websites and SaaS products, and the architecture decisions that matter for secure B2B delivery.
EngineeringSaaS MVP Tech Stack — A Pragmatic Default for 2026
A battle-tested default stack for SaaS MVPs — frontend, backend, auth, data, billing, and observability — with guidance on when to deviate.
Newsletter
Product notes, not noise.
Occasional frameworks on portals, SaaS MVPs, and automation. No agency spam.