When starting a new product, the first technical decision isn't always which framework to use. Sometimes the more important question is what should actually be built first.
A proof of concept, prototype, and MVP solve different problems. Building the wrong one can mean spending weeks implementing production code before you've answered the question you actually had.
This guide breaks down the technical differences and shows how I approach the decision when building SaaS products.
The three approaches
A simple way to think about them:
| Approach | Main question | Users | Production-ready? |
|---|---|---|---|
| Proof of Concept | Can we technically build this? | Usually no | No |
| Prototype | Does this interaction/workflow make sense? | Sometimes | No |
| MVP | Will people actually use this product? | Yes | Yes, at the appropriate scope |
The important distinction is what you're trying to validate.
If you're unsure whether an external API can support your application, an MVP is probably overkill.
If the API works but you're unsure whether users understand the workflow, you probably need a prototype.
If the technology and workflow are reasonably understood and you need real-world usage data, that's where an MVP makes sense.
1. Proof of Concept: Validate the risky technology first
A PoC is a small technical experiment.
It should answer one specific question.
For example:
- Can this API process our data?
- Can we extract structured data from these PDFs?
- Can we generate useful results with this AI model?
- Can we process 10,000 records within an acceptable time?
- Can two services communicate reliably?
- Can this real-time feature work with our expected latency?
The key is to avoid building the rest of the application.
Example: testing an external API
Suppose you're building a SaaS application that depends on an external document-processing API.
Instead of immediately creating:
Next.js app
↓
Authentication
↓
PostgreSQL
↓
Dashboard
↓
Document upload
↓
API integration
↓
Results page
Start with:
Test document
↓
External API
↓
Response
↓
Console / JSON output
For example:
async function testDocumentProcessing(fileUrl) {
const response = await fetch(
"https://api.example.com/v1/process",
{
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${process.env.API_KEY}`,
},
body: JSON.stringify({
file_url: fileUrl,
}),
}
);
if (!response.ok) {
throw new Error(`API failed: ${response.status}`);
}
const result = await response.json();
console.log(result);
}
testDocumentProcessing(
"https://example.com/test-document.pdf"
);
You don't need a dashboard, database, user management, or billing system yet.
If the API cannot produce the required result, you've discovered the problem before spending days building around it.
Keep PoCs disposable
One mistake I see is turning a PoC into the beginning of the production codebase.
Don't.
A PoC is optimized for learning, not maintainability.
It's completely acceptable to have:
/poc
test-api.js
test-ai.js
test-performance.js
Once the technical risk is understood, throw it away and implement the production version properly.
2. Prototype: Validate the workflow
A prototype answers a different question:
"Does this product interaction make sense?"
You don't necessarily need a backend.
For example, imagine a SaaS application where users need to:
Upload document
↓
Review extracted information
↓
Correct errors
↓
Approve
↓
Generate result
Before implementing authentication, database models, queues, permissions, and APIs, you can build the workflow with static data.
A simple Next.js page could contain:
const document = {
customerName: "John Smith",
email: "john@example.com",
amount: 1250,
status: "Needs Review",
};
export default function ReviewPage() {
return (
<main>
<h1>Review Document</h1>
<div>
<label>Name</label>
<input defaultValue={document.customerName} />
</div>
<div>
<label>Email</label>
<input defaultValue={document.email} />
</div>
<div>
<label>Amount</label>
<input defaultValue={document.amount} />
</div>
<button>Approve</button>
</main>
);
}
There is no database here.
There doesn't need to be one.
The purpose is to test whether the workflow itself is understandable.
You can put this in front of a few target users and observe where they get confused.
That feedback is often more valuable than implementing the entire backend first.
3. MVP: Validate the complete product
An MVP is different because real users should be able to use it.
That doesn't mean building every feature.
It means building the smallest complete product that can test the core assumption.
For a SaaS product, that usually means having at least:
Authentication
↓
Core workflow
↓
Database
↓
API
↓
Basic UI
↓
Deployment
Depending on the product, you may also need:
- Payments
- File storage
- Permissions
- Background jobs
- Monitoring
- Error handling
The important distinction is:
MVP does not mean prototype with a nicer UI.
A prototype can fake data.
An MVP should handle real data and real usage.
A simple MVP architecture
For a small Next.js SaaS application, a straightforward architecture could look like this:
Browser
│
▼
Next.js
│
├── Authentication
├── UI
└── API routes
│
▼
PostgreSQL
│
├── users
├── projects
└── subscriptions
You don't need microservices just because the product is called a SaaS.
Start with a modular monolith unless there is a clear reason to split services.
For many early products, this is enough:
Next.js
PostgreSQL
Stripe
Object Storage
External APIs
The architecture can become more distributed later when the actual workload requires it.
A basic database model
Imagine an MVP where users create projects.
A minimal relational model could be:
CREATE TABLE users (
id UUID PRIMARY KEY,
email TEXT NOT NULL UNIQUE,
created_at TIMESTAMP DEFAULT NOW()
);
CREATE TABLE projects (
id UUID PRIMARY KEY,
user_id UUID NOT NULL REFERENCES users(id),
name TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'draft',
created_at TIMESTAMP DEFAULT NOW()
);
The relationship is simple:
users
│
└── projects
│
├── Project A
├── Project B
└── Project C
Don't create ten tables because you expect the product to become complex.
Model the domain you actually understand today.
You can refactor when the requirements become clearer.
A useful decision rule
Before writing production code, identify the biggest unknown.
If the unknown is technical
Build a PoC.
Example:
"Can we process these documents using this API?"
Don't build the dashboard yet.
If the unknown is UX
Build a prototype.
Example:
"Will users understand this five-step workflow?"
Don't spend time building the complete backend yet.
If the unknown is market behavior
Build an MVP.
Example:
"Will customers actually use and pay for this workflow?"
Now real users matter, so production code becomes necessary.
One more important distinction: scope vs quality
One of the most common mistakes with MVPs is interpreting "minimum" as "low quality."
These are different things.
You can have:
Small scope + good engineering
or:
Small scope + poor engineering
The first is an MVP.
The second is technical debt disguised as an MVP.
For example, if your MVP needs authentication, don't necessarily implement every possible authentication provider.
You might only support:
Email + password
But the implementation should still handle:
- Password hashing
- Session management
- Authorization
- Validation
- Error handling
- Secure cookies/tokens
- Rate limiting where appropriate
You're reducing scope, not deliberately introducing security problems.
A practical example
Suppose you're building a SaaS platform for sports academies.
You might initially imagine:
Players
Teams
Coaches
Attendance
Payments
Tournaments
Notifications
Reports
Mobile app
AI analytics
Building everything would take a long time.
Instead, identify the core workflow:
Academy
↓
Create team
↓
Add players
↓
Record attendance
↓
View attendance
That could become the MVP.
The rest can wait.
But the MVP should still have a real database, authentication, deployment, validation, and reliable CRUD operations.
Later:
MVP
↓
Payments
↓
Notifications
↓
Mobile app
↓
Analytics
Each step should be driven by what you've learned from the previous one.
Common technical mistakes
1. Building production architecture for a PoC
You don't need Kubernetes, microservices, queues, and multiple databases to answer whether an API works.
Use the simplest experiment possible.
2. Turning a prototype into production code
Prototype code often optimizes for speed of iteration.
Production code needs different concerns:
Validation
Security
Error handling
Data integrity
Observability
Testing
Deployment
Treat the prototype as disposable.
3. Building every feature before getting feedback
A feature isn't validated because you successfully implemented it.
Real users using it is the validation.
4. Using "MVP" as an excuse for bad engineering
An MVP can have a small feature set while still having a solid technical foundation.
The goal is:
Minimum viable scope, not minimum viable engineering.
So what should you build first?
Use this decision tree:
What's your biggest unknown?
│
├── Technical feasibility
│ ↓
│ PoC
│
├── User experience / workflow
│ ↓
│ Prototype
│
└── Real-world usage / demand
↓
MVP
And you don't necessarily need all three.
For a straightforward SaaS idea where the technology and workflow are already understood, going directly to an MVP may be the fastest path.
For a product built around a technically uncertain AI model or third-party API, a short PoC can save weeks.
The goal isn't to follow a fixed startup process.
The goal is to reduce the most important uncertainty before investing more engineering time.
I'm Haseeb, building SaaS products at Seebify. I write about practical product engineering, architecture, and building production-ready software.
Full write-up with the business-side reasoning: https://www.seebify.com/blog/mvp-vs-prototype-vs-proof-of-concept
Top comments (0)