The 48-Hour Rule

· 3 min read
executionshippingscope

I have a rule for every project: If I can’t build a working version in 48 hours, the scope is wrong.

Not “a plan.” Not “a design.” A working thing that does the core job.

This rule has saved me months. Here’s how it works.

Why 48 Hours?

Because 48 hours is long enough to build something real, but short enough that you can’t hide complexity.

If you need:

  • A user system
  • A payment integration
  • A “scalable” architecture
  • Perfect error handling

You have too much scope.

The Framework

When I start a project, I ask: What’s the smallest version that delivers value?

Not “what features should it have?” That’s the wrong question. The right question is: What job does this need to do?

Example: I needed a way to track memecoin dips. The “full” version would have:

  • User accounts
  • Price alerts
  • Historical charts
  • Portfolio tracking
  • Mobile app

The 48-hour version:

  • One script
  • One API call
  • One alert mechanism

It tracked one coin. It sent one alert type. It worked.

The Scope-Cutting Questions

  1. What happens if I delete this feature? If the answer is “nothing important,” delete it.

  2. Can a human do this part for now? Manual processes buy you time to validate.

  3. Is this for launch or for scale? Launch needs users. Scale needs optimization. Don’t optimize for users you don’t have.

  4. What’s the 20% that delivers 80% of value? Build that first. The rest is decoration.

What the 48-Hour Version Looks Like

  • No auth. Hardcode it. One user: you.
  • No database. Files work. JSON is fine.
  • No tests. You’ll rewrite it anyway.
  • No docs. The code is 200 lines. Read it.
  • No “best practices.” Best practices are for teams, not prototypes.

The Real Benefit

You learn in 2 days what takes others 2 months to figure out.

  • Does anyone want this?
  • Does the core mechanic work?
  • What’s actually hard vs. what looked hard?

You can’t learn this from planning. You learn it from shipping.

When to Break the Rule

Never for the first version.

The 48-hour rule isn’t about rushing. It’s about clarity. If you can’t make it small, you don’t understand it yet.

Once you have users? Scale as needed. But launch first.

The bottom line: Complexity is the enemy of shipping. The 48-hour rule forces you to find the simple core hiding inside your big idea.

Most projects fail because people build the big version first. Build the small version. It’ll teach you what the big version actually needs.

All articles