Finding the highest-leverage path before building

The most common mistake in technical work isn't bad code. It's building the wrong thing well.

I've watched developers (myself included) spend weeks optimizing a solution to a problem that didn't need solving, or building a feature that users didn't ask for, or automating a process that happens twice a year.

The fix isn't better estimation. It's better selection.

What "highest leverage" means

Leverage in this context is simple: output divided by effort. A high-leverage action produces significant results with reasonable investment. A low-leverage action produces marginal results regardless of effort.

Some examples:

• High leverage: Adding a search function to a database of 500 domain names you already own
• Low leverage: Building a custom CRM for tracking domain inquiries when email works fine
• High leverage: Automating a daily report that takes 20 minutes to generate manually
• Low leverage: Building an automated report system for a process that happens monthly

The difference isn't technical complexity. It's about whether the effort matches the actual problem.

A framework for evaluating paths

When I face a decision about where to invest time, I ask these questions:

1. What problem does this solve?

Not "what will this build?" but "what problem disappears when this is done?" If you can't name the problem clearly, you probably don't need the solution.

2. How often does this problem occur?

Daily problems justify more investment than weekly problems. Weekly problems justify more than monthly ones. This isn't about importance — it's about compounding returns.

3. What's the current cost of the problem?

Measure in time, money, or risk. If a manual process takes 10 minutes per day, that's roughly 40 hours per year. If automation takes 8 hours to build, the payback period is about 3 months. That's a reasonable investment.

4. Is there a simpler alternative?

Before building software, consider:

• Can a spreadsheet solve this?
• Can a template solve this?
• Can a one-time script solve this?
• Can an existing tool solve this?

Software is the last resort, not the first.

5. What's the opportunity cost?

Every hour spent on this project is an hour not spent on something else. What else could you accomplish? Sometimes the highest-leverage action is doing nothing and waiting for more information.

Applied to real projects

When I started Domain Ion, the initial instinct was to build a full domain marketplace. But the actual problem was understanding which domains in my portfolio were worth developing versus selling.

The highest-leverage path was building an appraisal tool backed by comparable sales data — not a marketplace. The appraisal tool answered the core question quickly. A marketplace would have been months of work for a use case that wasn't validated.

When to stop analyzing and start building

Analysis paralysis is real. Here's when I stop evaluating and start executing:

• I've identified the problem clearly
• I've checked for simpler alternatives
• The effort is reasonable relative to the expected outcome
• I can define what "done" looks like in concrete terms
• I've talked to at least one person who has this problem (or validated it myself)

If I can't define "done," I'm not ready to build.

The discipline of saying no

The hardest part of high-leverage thinking is declining opportunities. There are always more ideas than time. The skill isn't in building everything — it's in building the right things and having the discipline to leave the rest.

Not every good idea deserves your time right now. Some deserve it later. Some don't deserve it at all.