A lot of software projects don't become difficult because the code is difficult.

They become difficult because nobody has clearly decided what the code is supposed to do.

I've seen this happen with startup products several times.

A founder starts with an idea:

"I want to build a SaaS platform for restaurants."

Then the feature list starts growing:

• Authentication

• Dashboard

• Payments

• Notifications

• Admin panel

• Analytics

• AI

• Integrations

• Mobile app

At this point, it is tempting to start designing the database and creating React components.

I think that's usually too early.

Before writing code, I want to turn the idea into something another developer can actually understand and estimate.

This is the process I use.

1. Start With the Problem, Not the Features

When someone gives me a list of features, my first question is usually:

"What problem is the product supposed to solve?"

Consider:

"I need an AI dashboard."

That doesn't tell a developer much.

A better description might be:

"Restaurant owners spend several hours every week calculating food costs manually and need a faster way to identify recipes whose margins are declining."

Now we understand the problem.

The technology is no longer driving the conversation.

The problem is.

This also helps eliminate unnecessary features.

If a feature doesn't contribute to solving the core problem, it may not belong in the first version.

1. Define One Primary User

"Everyone" isn't a useful target user.

A developer needs to understand who will actually use the product.

For example:

Target user: Independent restaurant owners with one to five locations.

Now we can ask more specific questions:

What are they trying to accomplish?

What information do they already have?

What action should they take?

What does their current workflow look like?

What is frustrating about that workflow?

The more specific the first user is, the easier it becomes to make product decisions.

1. Map the Core Workflow

This is where an idea starts becoming an actual application.

Instead of listing features, describe what the user does.

For example:

User signs up

↓

Creates a project

↓

Adds information

↓

Generates a result

↓

Reviews the result

↓

Takes action

That's much more useful to a developer than:

"Build a dashboard with AI, analytics and notifications."

The workflow tells us what the application actually needs to accomplish.

1. Find the Smallest Useful Workflow

Now comes the difficult part.

Ask:

"What is the smallest version of this workflow that can prove the product is useful?"

Imagine you're building a fitness application.

The initial idea might include:

• Personalized workouts

• Exercise tracking

• Progress charts

• Push notifications

• Voice coaching

• Social sharing

• Leaderboards

• Wearable integrations

• AI coaching

But the first useful workflow could be:

User signs up

↓

Gets today's workout

↓

Completes the workout

↓

Records the results

That's enough to test an important question:

Do users actually want this workout experience?

The other features can come later.

This is what I think an MVP should do.

It shouldn't simply be a smaller version of the final product.

It should be the smallest version that can answer an important product question.

1. Separate Features Into Three Groups

Once the core workflow is clear, I separate features into three groups.

Must Have

The product doesn't work without them.

For the fitness example:

• Authentication

• Personalized workout

• Workout screen

• Exercise tracking

• Saving workout results

Useful

They improve the experience but aren't necessary for the initial validation.

• Progress charts

• Workout history

• Push notifications

• Voice coaching

• Exercise videos

Later

They can wait until there is evidence users need them.

• Social sharing

• Leaderboards

• Wearable integrations

• Community

• Advanced analytics

This simple classification prevents the MVP from becoming the entire product roadmap.

1. Write Down What You Are NOT Building

This is one of the most useful things a developer can have before starting a project.

Don't only document what is included.

Document what is explicitly excluded.

For example:

Included:

• Email/password authentication

• Stripe subscription

• One user role

• Core dashboard

• CSV export

Not included:

• Social login

• Team accounts

• Advanced permissions

• Mobile application

• Custom reporting

The second list is important.

Without it, scope can expand silently during development.

A feature that sounds like a five-minute addition can sometimes require database changes, API changes, UI changes, testing and new edge cases.

1. Turn Features Into Testable Requirements

A feature name is usually not enough.

Take:

"Add authentication."

What does that actually mean?

Does the user need:

• Registration?

• Login?

• Logout?

• Password reset?

• Email verification?

• Protected routes?

• Session management?

• Account deletion?

Instead, write requirements that can be tested.

For example:

A user can register using an email and password.

A registered user can log in.

Unauthenticated users cannot access the dashboard.

A user can log out.

A user can reset their password.

Now there is a clear definition of what needs to work.

1. Identify External Services Before Estimating

Integrations can have a significant effect on development time.

Don't just write:

"Stripe integration."

Figure out what Stripe needs to do.

Does the application require:

• Subscriptions?

• One-time payments?

• Webhooks?

• Refunds?

• Customer portal?

• Subscription cancellation?

• Failed-payment handling?

The same applies to other services.

For example, "Add AI" could mean:

• Generate content

• Analyze user input

• Generate recommendations

• Stream responses

• Store conversation history

• Handle usage limits

"Add AI" isn't a technical requirement.

The actual behavior is.

1. Define What "Done" Means

A developer should be able to look at a requirement and determine whether it is complete.

Instead of:

"Users can create projects."

Define:

A logged-in user can create a project by entering a name and description.

The project is saved to the database.

The user can see the project in their dashboard.

The user can open the project later and edit it.

An invalid submission displays an appropriate error.

Now the requirement is much easier to implement and test.

1. Estimate After the Unknowns Are Reduced

This is where all of the previous work becomes useful.

If someone asks:

"How much will this MVP cost?"

before defining the product, the answer will contain a lot of assumptions.

But after defining:

• Problem

• Target user

• Core workflow

• Features

• Out-of-scope items

• Acceptance criteria

• Integrations

• Technical constraints

the estimate becomes much more meaningful.

The process becomes:

Problem

↓

Target user

↓

Core workflow

↓

MVP scope

↓

Technical requirements

↓

Acceptance criteria

↓

Estimate

Instead of:

Idea

↓

Random feature list

↓

Guess

The Test I Use Before Starting Development

There is one simple question I like to ask:

"Could another developer read this specification and understand what needs to be built without a one-hour meeting with the founder?"

If the answer is no, there is probably still too much ambiguity.

That doesn't mean every detail needs to be documented.

You don't need a 100-page specification.

You need enough clarity to make the important decisions before they become expensive engineering decisions.

I Built a Free Tool Around This Process

After doing this kind of scoping repeatedly, I turned the basic process into a small free MVP Scope Builder.

It guides you through:

• The problem

• Target user

• Core workflow

• In-scope features

• Out-of-scope features

• Success criteria

• Acceptance criteria

• Integrations

It then generates a structured MVP specification that can be copied or downloaded as Markdown.

You can try it here:

https://www.rahulsinghnegi.com/resources/mvp-scope-template

Final Thought

Good MVP development isn't about writing less code.

It's about making sure you're writing the right code.

The earlier you identify the core problem, narrow the first user, define the workflow and explicitly decide what you're not building, the fewer expensive assumptions you carry into development.

The goal isn't to predict everything.

It's to remove enough ambiguity that a developer can build the first useful version with confidence.

That is what good MVP scoping means to me.

title: "How I Built a SaaS MVP in 6 Weeks for Under $15K" description: "A transparent breakdown of how I built and launched a production-ready SaaS platform in 6 weeks — including the tech stack, architecture decisions, and where the money actually went." published: true tags: [saas, mvp, webdev, nextjs, startup]

Building a SaaS MVP doesn't require a $100K budget or a team of five. I know because I just did it for under $15K in six weeks.

Here's exactly how.

The Project

PeptiSync is a HealthTech SaaS platform that lets users compare real-time medication prices across vendors, manage subscriptions, and access health records — all from a single dashboard across Web, Android, and iOS.

Week 1-2: Foundation

Cost: $3,500

The first two weeks were about getting the architecture right. I started with Next.js for the web frontend, Firebase for the backend, and Flutter for mobile.

Key decisions:

• Monorepo with shared TypeScript types between web and mobile
• Firestore with indexed queries for real-time vendor pricing
• Firebase Auth with anonymous-to-authenticated upgrade flow

Week 3-4: Core Features

Cost: $6,000

This is where the product started looking real.

• User authentication with Google OAuth
• Vendor pricing database with CRUD operations
• Subscription management with Stripe integration
• Responsive web dashboard
• Basic Android and iOS shells in Flutter

The mistake I see most founders make here: they try to build every feature. I built the minimum that demonstrates value — price comparison across vendors.

Week 5-6: Polish & Launch

Cost: $4,500

• UI refinement and responsive design
• Performance optimization
• SEO setup (metadata, sitemaps, structured data)
• CI/CD pipeline with GitHub Actions
• TestFlight and Play Store internal testing
• Production deployment

The Technical Details

Architecture

Web (Next.js) → Firebase Auth → Firestore → Stripe API
Mobile (Flutter) → Firebase Auth → Firestore → Stripe API

Why Firebase Over PostgreSQL?

For an MVP, Firebase eliminated the need for a backend engineer. Cloud Functions handled Stripe webhooks, Firestore's real-time sync meant instant vendor price updates, and the auth integration was seamless.

The trade-off? Firebase is expensive at scale. The plan was always to migrate critical paths to PostgreSQL once traction was proven. Two months post-launch, that migration is in progress.

The $15K Breakdown

What I'd Do Differently

1. Start with Stripe test mode earlier. I spent a full day debugging webhooks that would have taken 30 minutes if I had set up the Stripe CLI on day one.
2. Skip iOS for the MVP launch. The App Store review process added two weeks to the timeline for negligible initial traffic.
3. Write more tests during week 1-2. Catching bugs during feature development is cheaper than fixing them in production.

The One Thing That Made the Biggest Difference

Building the pricing page and Stripe integration in week 3, not week 6. Having a way to charge money early forced me to build features that actually justified the price. If a feature didn't support the value proposition, it got cut.

I'm a technical partner for startup founders. If you're building something and want to skip the mistakes I made, let's talk.