The Magic Launcher Paradigm: Addendum 14

Gap-Driven Development: The Missing Design Primitive

The Missing Question

Every design meeting starts with solutions. Features. Integrations. Roadmaps.

Nobody asks: "What's the gap?"

What Is A Gap Statement?

A gap statement identifies what's actually missing. Not what would be nice. Not what competitors have. What's MISSING.

Good gap statements:

• "I can't extract sections from text files" MLQuickpage
• "PowerShell adds null bytes to my CSV" MLNonull
• "I want minesweeper right now" MLSweeper
• "No terminal pet exists" MLPet

Bad gap statements:

• "Users need a better experience" Better how? What gap?
• "We need modern features" Which gap do they close?
• "Competitors have X" Is X filling a gap or creating one?

The Papering Problem

Most software doesn't close gaps. It papers over them.

Papering: Adding layers on top of problems instead of solving them.

Example - The Notification Gap:

• Gap: "I miss important messages"
• Solution: Notifications
• Papering: Priority notifications
• More papering: Notification settings
• More: Notification schedules
• More: AI-powered notification filtering
• Result: Now you miss important messages AND spend time managing notifications

The gap never closed. It just got wallpaper.

Real-World Papering

Kubernetes:

• Original gap: "Deploy containers consistently"
• Papering: Service mesh (to manage the services)
• More papering: Helm (to manage the configs)
• More: Operators (to manage Helm)
• More: GitOps (to manage operators)
• Result: Need a team to manage the gap-closing tool

JIRA:

• Original gap: "Track issues"
• Papering: Workflows, sprints, epics, stories
• More papering: Custom fields, schemes, permissions
• Result: Finding an issue takes 10 clicks

Slack:

• Original gap: "Team chat"
• Papering: Threads, reactions, apps, workflows
• More papering: Huddles, canvas, AI summaries
• Result: Communication is now harder

Gap-Driven Development Process

1. Identify the gap (one sentence max)

2. Verify it's real (not invented or aspirational)

3. Define minimum closure (what makes the gap gone?)

4. Build only that

5. Stop

That's it. That's the entire methodology.

The Stop Sign

The hardest part is step 5: STOP.

How to know when to stop:

• Gap statement satisfied? Stop.
• Adding features beyond the gap? Stop.
• Creating new gaps? Stop.
• Papering over something? Stop.

Examples from ML-Extras

MLTimer:

• Gap: "Visual countdown that runs a command"
• Built: Visual countdown that runs a command
• Stopped: No scheduling, no multiple timers, no history

MLView:

• Gap: "View images in terminal environments"
• Built: Image viewer with one useful filter
• Stopped: No editing, no library, no sharing

MLSticky:

• Gap: "Persistent notes for a system or user"
• Built: Append-only text file with timestamps
• Stopped: No editing, no tags, no search

Each tool stops exactly when its gap closes.

The Feature Request Test

When someone asks for a feature:

1. "What gap does this close?"

2. "Is it the same gap as our gap statement?"

3. If no: "That's a different tool"

4. If yes: "Does the gap already closed?"

5. If yes: "Then we're done"

Anti-Patterns

The Moving Gap:

• "We need chat" "We need threaded chat" "We need AI chat"
• The gap keeps moving because it was never defined

The Invented Gap:

• "Users need gamification"
• Nobody asked for this. You invented a gap to fill

The Meta Gap:

• "We need to manage our gap-closing tool"
• Your solution created new gaps

The Competitive Gap:

• "Competitor has feature X"
• That's their gap (or papering), not yours

Why Gaps Get Papered Instead of Closed

1. Unclear gap definition - Can't close what you can't define

2. Scope creep - Today's feature is tomorrow's platform

3. Job security - Closed gaps don't need teams

4. Marketing - "New features!" sells; "Still works!" doesn't

5. Misaligned incentives - Promoted for adding, not removing

The Magic Launcher Example

Gap: "I want to click and launch things"

What we DIDN'T add:

• User accounts (not part of the gap)
• Cloud sync (not part of the gap)
• Analytics (not part of the gap)
• Plugins (not part of the gap)
• Themes beyond basic (not part of the gap)

What we added:

• Click detection
• Launch capability
• Visual organization

Gap closed. Development stopped.

Gap Statements for Teams

In design meetings, require:

1. Written gap statement (one sentence)

2. Evidence the gap exists (user complaints, observed behavior)

3. Definition of closure (when is it closed?)

4. List of non-gaps (what we're NOT solving)

Template:

Gap: [Users cannot X]
Evidence: [Observed/reported by Y]
Closure: [Users can X via Z]
Non-gaps: [We are not solving A, B, C]

The Composition Solution

Instead of papering, compose:

Bad (papering):

• Chat app adds file sharing, video, screen share, AI...

Good (composition):

• Chat app does chat
• File sharing app shares files
• Pipe them together

Each tool closes ONE gap completely.

The Economic Argument

Papering costs:

• Endless development
• Growing complexity
• Increasing maintenance
• User confusion
• Technical debt

Gap-closing saves:

• Development stops when gap closes
• Maintenance is minimal
• Users understand it
• No debt if it works

The User Argument

Users don't want features. They want gaps closed.

• "I want to edit text" not "I want AI-powered collaborative cloud-native editing"
• "I want to track issues" not "I want agile transformation platform"
• "I want to launch programs" not "I want an application lifecycle manager"

The Developer Argument

Developers prefer:

• Clear requirements (gap statements)
• Defined success (gap closed)
• Permission to stop (gap closed = done)
• Simple maintenance (less paper = less problems)

Case Study: The Terminal Gap

Gap: "I can't see what my script is outputting"

Solution A (papering):

• Add logging framework
• Add log levels
• Add log rotation
• Add log analysis
• Add log shipping
• Result: Now need to manage logs

Solution B (gap-closing):

• echo "doing thing"
• Gap closed

The Test Suite

Before building, ask:

1. Can I state the gap in one sentence?

2. Can I define when it's closed?

3. Am I solving THIS gap or creating others?

4. Will my solution need its own solutions?

5. Can I compose existing tools instead?

If any answer concerns you, you're about to paper.

Conclusion

Gap-Driven Development isn't a methodology. It's a question: "What's the gap?"

If you can't answer in one sentence, you don't understand the problem.

If your solution creates new gaps, you're papering.

If you keep adding after the gap closes, you've become the problem.

The discipline isn't in what you build. It's in what you don't.

---

"Every feature is either closing a gap or creating one. There is no middle ground."

Remember: The next time someone says "We need to add...", ask "What gap does that close?" Watch the room go silent. That silence is the sound of papering being prevented.