thaitype Slim Down — Cut Scope, Keep Scale
Take a plan or design that's grown too big and cut it down to one increment — the smallest step that delivers value and doesn't block future growth.
Make it work before make it great — but never paint yourself into a corner.
When to Use
- When a plan or design feels over-engineered
- When user says "this is too much", "what do I actually need first?", "MVP"
- Any time scope has ballooned beyond what's practical to build next
Core Principle
Cut scope, not corners. Remove features, not quality. The increment should be small but extensible — no dead-ends, no "throw it away later."
Workflow
Step 1: Read the Ground
Before cutting anything, understand what already exists:
- Read the current codebase — what's built, what patterns are in use
- Read the plan/grill result/spec that needs slimming
- Identify what's new work vs already done or partially done
Summarize in a short block:
- Current state — what exists today (2-3 lines)
- Full goal — what the plan wants to achieve
- Gap — what's missing between current state and full goal
Step 2: Identify the Core
Ask: "What is the one thing this plan must deliver to be useful?"
Draft a single sentence describing the core value. Show it to the user. This is the anchor — everything else gets judged against it.
Step 3: Sort Into Keep / Defer / Drop
Take every item from the plan and sort it:
| Criteria | |
|---|---|
| Keep | Required for the core to work. Can't ship without it. |
| Defer | Valuable but not needed yet. Design so it can be added later. |
| Drop | Nice-to-have, speculative, or solves a problem that doesn't exist yet. |
Show the table. Let the user move things around.
Rules for sorting:
- If it's only needed at 10x scale → Defer
- If it handles an edge case that hasn't happened → Defer
- If removing it doesn't break the core → Defer
- If it adds a new abstraction layer "for flexibility" → Drop unless proven needed
- If current code already handles it partially → Keep (finish, don't redo)
Step 4: Check Scalability
For each Defer item, verify:
- Does the Keep list block it from being added later?
- Does the current increment create a dead-end that forces a rewrite?
If yes → move that item back to Keep or adjust the design.
If the user asks "will this scale?" — answer honestly based on the code, not hypotheticals.
Step 5: Write the Increment
Co-write a short definition of what to build:
- Goal — one sentence
- Delivers — bullet list of Keep items
- Deferred — bullet list of Defer items (so nothing is forgotten)
- Out — what's dropped and why
- Done when — how to verify it's complete
Write to a file if the user wants. Otherwise just confirm alignment.
How to Cut (not gut)
- Respect existing code. Don't propose replacing what works. Build on it.
- Defer > Drop. Dropping feels permanent. Deferring keeps options open and the user at ease.
- Show the path. When deferring something, briefly note how the current design leaves room for it.
- Be specific. "Defer auth" is vague. "Defer OAuth — use API key for now, auth middleware interface stays the same" is actionable.
What NOT to Do
- Don't add new features while slimming down
- Don't redesign the architecture — work with what's there
- Don't say "just do an MVP" without defining what that means concretely
- Don't cut things the user already built — that's wasted work, not saved scope
- Don't assume the user wants the cheapest option — they want the smallest useful one