The De-Scoping Algorithm: How to Define an MVP That Actually Ships

I have a directory on my hard drive called /graveyard. It is filled with half-baked Next.js repos, half-written Python scripts, and Docker containers that haven’t been spun up in three years. These projects didn't die because I couldn't code them. They died because I couldn't scope them.

As engineers, our default mode is accretion. We add. We see a problem, and we imagine a platform. We see a simple automation task, and we architect a microservices mesh. We optimize for scale before we have a single user.

This is the Scope Trap.

If you are building micro-SaaS or AI agents as a solo developer, scope creep isn't just an annoyance; it is an existential threat. If you don't ship, you don't learn. And if you don't learn, you are just practicing typing.

Over the last year, I’ve forced myself to adopt a radical de-scoping methodology. I call it the MVP Spec Template. It relies on the "Power of One."

The Definition of MVP (It’s Not What You Think)

Most people think MVP stands for "Minimum Viable Product." In practice, developers treat it as "Mediocre Version of Product." They build the full vision but do a bad job at it.

That is wrong. An MVP should be:

• Minimum: The smallest possible surface area of code.
• Viable: It actually solves the specific problem completely.
• Product: It is packaged well enough to be used by someone else without you looking over their shoulder.

To achieve this, you have to stop thinking about features and start thinking about constraints. Features are infinite. Constraints provide the friction necessary for creativity.

The Framework: 1 User, 1 Pain, 1 KPI

When I start a new automation project or micro-SaaS, I refuse to write a single line of code until I fill out this JSON object. If I can't define these three keys, I am not ready to open VS Code.

{
  "target_user": "...",
  "core_pain": "...",
  "primary_kpi": "..."
}

This looks simple. It is excruciatingly difficult to stick to.

1. One User (The "Who")

"Everyone" is not a user. "Small businesses" is not a user. Even "Developers" is too broad.

You need to narrow the aperture until the target is uncomfortable. If you are building an AI tool for writing documentation, do not build it for "Software Engineers." Build it for "Freelance Python Developers maintaining legacy codebases."

Why? Because a Freelance Python dev has different budget constraints and time pressures than a Senior Staff Engineer at Google. By narrowing the user to a singularity, you remove the need to build settings, toggles, and edge-case handling for everyone else.

2. One Pain (The "Why")

Your product should not be a Swiss Army Knife. It should be a scalpel. It solves one specific cut perfectly.

If you list three pains, you have to build three solutions. That triples your development time and increases your bug surface area exponentially. Pick the pain that is acute and frequent.

Example:
Bad Pain Definition: "Managing social media is hard."
Good Pain Definition: "Taking a long-form YouTube video and manually finding the timestamps for 3 viral shorts takes 45 minutes."

The second definition writes the spec for you. You know exactly what input you need (YouTube URL) and exactly what output is required (Timestamps). Everything else is noise.

3. One KPI (The "Success")

How do you know if the MVP worked? You need a Key Performance Indicator. But for an MVP, revenue is often a lagging indicator. You need a proxy for value.

If your tool is an automation script, the KPI might be "Time Saved per Execution." If it's a content tool, it might be "Copy/Paste Rate" (how often users actually use the output).

Focusing on one KPI prevents feature creep. If a new feature idea doesn't directly move that specific needle, it gets cut.

Case Study: The "AI Email Triager"

Let’s walk through a practical example of how de-scoping saves a project.

The Trap (What we want to build)

Idea: An AI email assistant.
Scope: Connects to Gmail and Outlook. Reads emails. Categorizes them. Drafts replies. Archives spam. Has a dashboard to view analytics. Has a mobile app for notifications. Has dark mode.

Result: 6 months of development. OAuth nightmares. Security audits. Abandoned project.

The De-Scoped MVP (The "Power of One")

Let's apply the framework.

• 1 User: Agency owners who receive inbound lead forms via email.
• 1 Pain: Missing high-value leads because they are buried in newsletter spam.
• 1 KPI: Response time to high-value leads.

The New Spec:
We don't need a dashboard. We don't need Outlook support. We don't even need to draft replies yet.

The MVP is a background cron job. It scans the last 10 emails via Gmail API. It uses an LLM to score the email from 0-10 based on "likelihood of being a high-value lead." If the score is > 8, it sends a Slack notification to the user.

That is it. No UI. No database (maybe a simple JSON file for state). No user login (hardcode the auth for the first 5 beta testers).

Build time: 1 weekend.
Value delivered: Immediate.

The De-Scoping Algorithm

When you have your feature list, apply this algorithm to every single item. Be ruthless.

1. Is this required for the "One Pain" to be solved?
   • If No -> Delete.
   • If Yes -> Go to step 2.
2. Can this be done manually by me (the developer) behind the scenes?
   • If Yes -> Do not build. (e.g., Onboarding, Password Reset, billing integration).
   • If No -> Go to step 3.
3. Is there a no-code tool that can do this part?
   • If Yes -> Connect API.
   • If No -> Write Code.

The "Wizard of Oz" MVP

The most important rule in that algorithm is #2. Do things that don't scale.

For your MVP, you don't need a Stripe integration that handles invoices, tax calculation, and tiered subscriptions. Send the user a Stripe Payment Link manually via DM. If you get tired of sending links because you have too many customers, congratulations—you have earned the right to build a billing integration.

You don't need an automated password reset flow. If a user forgets their password, they can email you, and you can change it in the database. If this happens 50 times a day, then you build the feature.

The Tech Stack Trap

De-scoping applies to your infrastructure too. I see developers spinning up Kubernetes clusters for a landing page.

For an MVP, use boring technology.

• Database: SQLite or Supabase. (Don't set up a sharded Mongo cluster).
• Backend: Next.js API routes or FastAPI. (Don't build a microservices architecture).
• Hosting: Vercel or Railway. (Don't configure AWS VPCs manually).

Your users do not care about your tech stack. They care if the pain stops. Complex stacks introduce latency to shipping. Latency kills momentum.

The 80/20 Rule of Product Development

In software, the first 80% of value comes from 20% of the features. The other 80% of features (settings, profiles, analytics, dark mode, social sharing) only add the final 20% of value.

The problem is that the final 20% of value takes 80% of the time to build. It’s the "polish." And while polish is important for a mature SaaS, it is poison for an MVP.

Your goal is not to impress other engineers on Twitter. Your goal is to solve a problem for a user. If the solution is ugly but effective, you have a business. If the solution is beautiful but solves nothing, you have a Dribbble shot.

Conclusion: Ship to Learn

Product thinking is not about having the best idea. It is about having the fastest feedback loop. The smaller your scope, the faster you ship. The faster you ship, the faster you find out if you are wrong.

Take your current idea. Cut the features in half. Then cut them in half again. Then narrow the user base to a specific niche.

That is your MVP. Build that. Ship it.