sys-high-medium-low

name	sys:high-medium-low
description	Define three scope tiers for any project -- LOW (minimum proof of concept), HIGH (dream version), and MEDIUM (best balance of value and cost) -- to make smarter build decisions and avoid over-engineering.
argument-hint	[optional: feature or project to scope]

High-Medium-Low

From Save Your Startup by Rick Manelius (Chapter 10) Original framework by Rick Manelius

"Can you get 90% there for 10% -- or 1% or 0.1% -- of the cost?"

Why This Matters

Founders and builders have a dangerous habit: they describe "done" at one fidelity level and then build at another. Someone says "we need e-commerce" and the team jumps to a six-month ERP integration when a PayPal button would have answered the real question in five minutes.

The problem is not ambition. The problem is skipping the question: what is the cheapest way to learn if this matters?

Here is the key insight:

"If I triple the time from one month to one quarter, do I triple the value? You probably won't."

Value and cost do not scale linearly. The first 10% of effort often delivers 80% of the value. This exercise forces you to see that clearly before you commit.

How This Works

We will define three tiers of scope for your project, then compare the value-to-cost ratio at each level. By the end, you will know exactly where to start and why.

But first -- a bias check.

Phase 0 -- Notice Your Bias

Before we scope anything, I need to ask:

• When you imagine this project "done," where does your mind go first? (The quick-and-dirty version? The dream version? Somewhere in the middle?)
• Do you tend to over-build or under-build? (Be honest.)
• Has your team been burned before by scoping too high or too low?

Everyone gravitates toward one end of the spectrum. Knowing your default helps us compensate. If you always think big, we will spend extra time on LOW. If you always think small, we will push on HIGH.

Phase 1 -- Paint Done on Your Initial Target

Before we split into tiers, tell me what you are building. Do not filter or optimize yet.

I will ask you:

• What is the project or feature?
• Who is it for?
• What does "done" look like in your head right now?
• Why does this matter? What happens if you do not build it?

This gives us a starting point. Now we will stretch it in both directions.

Phase 2 -- Define LOW

The minimum proof of concept. Aim for a one-day to one-week build.

LOW is not "bad." LOW is "what is the cheapest, fastest way to test whether this idea has legs?"

I will ask you:

• What is the single most important thing this needs to do?
• What is the absolute minimum someone would need to see to give you useful feedback?
• Can you fake any of it? (Manual processes behind the scenes, mockups, wizard-of-oz, spreadsheets?)
• What tools already exist that get you 80% there with zero custom code?
• How long would this take? One day? One week?
• What do you learn from LOW that you cannot learn without building it?

Example -- e-commerce LOW: "Five minutes. A PayPal button on a landing page. We learn if anyone will actually pay."

Phase 3 -- Define HIGH

The dream version. The north star. One to two years, everything perfect.

HIGH is not the plan. HIGH is the vision -- what would this look like if time, money, and talent were unlimited?

I will ask you:

• If you had unlimited resources and two years, what would you build?
• What features, integrations, and polish would the dream version have?
• What would make a user say "this is the best version of this I have ever seen"?
• What would make this a competitive moat?
• How long would HIGH actually take? What would it cost?

Example -- e-commerce HIGH: "A thousand hours. Full-blown commerce platform with inventory management, ERP integrations, subscription billing, recommendation engine, and multi-currency support."

Phase 4 -- Define MEDIUM

Return to the middle. The best balance of value and cost.

Now that you can see both ends, MEDIUM becomes much clearer. It is not "half of HIGH." It is the version that delivers the most value per unit of effort.

I will ask you:

• Looking at LOW and HIGH, what is missing from LOW that would meaningfully increase value?
• What parts of HIGH are nice-to-have versus need-to-have?
• What is the smallest version that you would be comfortable showing to customers or stakeholders?
• How long would MEDIUM take? Weeks? A month? A quarter?
• What does MEDIUM let you learn that LOW does not?

MEDIUM is where most teams should start building. But you can only define a good MEDIUM after you have honestly looked at both extremes.

Phase 5 -- Compare

What is the value-to-cost ratio at each tier?

Now we lay them side by side:

Tier	Time	Cost	Value Delivered	Value per Unit of Cost
LOW	?	?	?	?
MEDIUM	?	?	?	?
HIGH	?	?	?	?

I will ask you:

• Where is the steepest value curve? (Where do you get the most value for the least cost?)
• Where does the curve flatten? (Where does additional investment stop paying off?)
• What is the risk at each tier? (LOW risks learning nothing useful. HIGH risks building something nobody wants.)
• Which tier should you start with, and what would trigger you to move to the next?

Getting Started

Let's scope your project. Tell me:

1. What are you building? (A feature, a product, a process -- anything.)
2. What is driving this? (Customer demand? Internal need? A hunch? An investor request?)
3. What is your gut instinct on timeline? (Do not overthink it. Just say a number.)

I will walk you through each tier and push you to be honest about where the real value lives.

Ground Rules

• LOW is not lazy. It is strategic. The goal is learning, not shipping.
• HIGH is not the plan. It is the compass. You probably will not build all of it.
• MEDIUM is not a compromise. It is the sweet spot where value and cost make sense.
• Be honest about what you actually know versus what you are assuming.
• "We might need that someday" is not a reason to build it now.

Output

By the end, you will have:

• Three clearly defined scope tiers with specific deliverables for each
• Time and cost estimates for LOW, MEDIUM, and HIGH
• A value-to-cost comparison showing where effort pays off and where it stops
• A recommended starting point with clear criteria for when to level up
• The confidence that you are building the right amount of the right thing