Two Contracts to Sign Before You Build Your Next Tool

I’ve lost count of how many times I’ve said “this tool will take me a weekend.”

Then I add one more feature. Then I decide the interface needs work. Then I rewrite a chunk of code because I found a “better” way. Holy cow, three months later I’m still polishing something that was supposed to take two weeks. 😃

And sometimes it’s worse. I finally ship it, and… crickets. Hardly anyone cares.

If you build and sell software, AutoHotkey scripts, AI tools, or any digital product, those are the two mistakes that cost the most time and money:

• Not finishing what you start.
• Building something nobody wants.

The good news? Both can be fixed with two simple contracts. One for proving demand, one for delivering the product. Have you ever been bitten by either one? Yeah, me too. Let’s fix it.

Prefer to watch? Here’s the video version:

The Double Trap of Independence: Why Your App Got Zero Users After Launch 📉

The YouTuber Who Hired Himself

When you work for someone else, you have deadlines, expectations, and consequences. When you work for yourself, all of that quietly becomes optional.

I recently watched a video from a creator who solved this in a clever way. He wrote and signed an employment contract with himself and his YouTube channel. Specific deliverables. Specific deadlines. Specific consequences for missing them.

He even hung the signed contract on his wall so he had to look at it every day.

It worked. He built a consistent schedule and published week after week.

But here’s the thing. His video also pointed at a bigger problem, and it’s the one I think tool builders get wrong the most.

Cool Idea Is Not the Same as Demand

Here’s how it usually goes. We get an idea. We think it’s clever. We can see exactly how much time it would save people.

So we spend weeks building it. Then we release it and discover hardly anyone is interested.

Why? Because we confused the value we saw in the idea with the demand that actually exists.

The YouTuber ran into the same thing. He made videos on topics that interested him, and the results were all over the map. Some pulled big audiences. Others barely got views.

The fix wasn’t “work harder.” It was pay attention to what people actually respond to. Software is no different. Don’t pick what to build based on how cool or technically interesting it is. First find out if enough people are already looking for a solution.

Three Tool Ideas: Which Would You Build?

Say you have three ideas for Windows automation tools:

• Tool A saves a user five minutes a day, but only a handful of people have the problem.
• Tool B fixes an annoying problem thousands of people search for every month.
• Tool C is technically fascinating, but most people don’t know they have the problem it solves.

Tool B is the best place to start. Not because A and C are bad, but because B has evidence of existing demand.

It’s MUCH easier to sell someone a fix for a problem they’re already trying to solve than to convince them they should care about one they’ve never thought about.

Five Ways to Check Demand Before You Code

• Search for the problem. Google, YouTube, Reddit, forums, and communities. Are people asking for a fix? Write down the exact words they use.
• Look at existing solutions. Are people paying for competitors? Complaining about price, limits, or missing features? Competition is often a sign of demand (though it doesn’t guarantee room for you).
• Check search interest. Keyword tools give you rough volume. The numbers are imperfect, and searches don’t prove anyone will pay, but they’re a useful signal.
• Talk to potential customers. How do they handle it today? How often does it happen? What does it cost them in time or money?
• Test the offer first. A simple landing page, a demo, or a mockup. Do people sign up or ask to pay? A compliment is weak evidence. A purchase is strong evidence.

The goal isn’t to prove your idea is brilliant. It’s to find out if enough people want it.

Contract #1: The Demand Contract

This is where I’d take the YouTuber’s idea one step further. Before you sign a contract to build something, sign one to validate the market. Here’s an example:

Those numbers are just examples. A niche business tool might have a small but very valuable audience. A consumer utility might need thousands of users. Set thresholds that fit your market and pricing.

The most important part: set the criteria BEFORE you see the results. Otherwise it’s way too easy to talk yourself into believing weak evidence proves your favorite idea is a winner. (Ask me how I know. 😊)

Do the Math on the Opportunity

Even when people want a tool, that doesn’t automatically make it worth building.

Say 2,000 people a month search for a related fix. Sounds great. But ask:

• How many of them are actually your target customers?
• How many could realistically find your product?
• How many would try it, and how many would pay?
• What price would they consider fair?
• How much time will development, support, maintenance, and marketing take?

You don’t need a perfect forecast. You need a reasonable estimate so you can compare ideas.

A small group of businesses happy to pay $200 can beat a huge crowd that expects everything free. And don’t forget distribution. A great product nobody finds is still a tough business.

Contract #2: The Delivery Contract

Once the idea passes the demand test, sign the second contract. It doesn’t need to be legally binding. It needs to be specific enough that you can’t fool yourself into thinking you’re done when you’re not.

• The deliverable: exactly what gets finished. Not “work on the new tool,” but “release a working version that does these three things.”
• The deadline: a specific date and time. “Sometime next month” isn’t a deadline.
• The scope: what version one will and WON’T include.
• The success criteria: how you’ll know it’s ready to release.
• The consequences: what happens if you miss the deadline.

One caution: don’t make the deadline so aggressive that you ship something insecure or unreliable. The goal is accountability, not recklessness.

Consequences That Actually Sting

If missing the deadline costs you nothing, it’s just another promise to yourself you can ignore. Pick one (or more) of these:

• Financial: donate $100 to a cause you don’t particularly love. That one hurts. 😃
• Social: announce your release date publicly, or have a colleague check in every week.
• Priority: no new projects until this one is finished or formally canceled.
• Scope: when time runs short, cut nonessential features instead of moving the deadline.
• Decision: if the demand test fails, stop investing, even if you’ve already put in hours.

I really like that last one. We keep working on projects because we’ve already sunk so much effort into them. But time already spent is gone. It shouldn’t decide whether you spend more.

The contract is there to help you make better decisions, not to force you to finish every idea you’ve ever had.

Keep Version One Small

Once you know people want it, fight the urge to build every feature you can dream up. Version one should solve the core problem well enough for real customers to use it. Customers will tell you what to add next.

Finished Isn’t the Same as Successful

For a commercial tool, finishing the code is just one milestone. You also need to know if it’s doing its job as a business. Depending on the product, track things like:

• Qualified leads
• Downloads and installs
• Users who actually use the core feature
• Free-to-paid conversions
• Revenue and profit
• Retention and repeat purchases
• Time saved or problems solved for customers

A finished product with no customers isn’t a successful launch. It’s a completed development project.

Set a date to review the numbers. If they’re short, figure out whether the problem is the product, the audience, the price, or the marketing before you change anything.

My Tool Opportunity Scorecard

Here’s how I’d put this into practice. Before any development starts, score every idea on:

Then set up two gates: a demand gate and a release gate. An idea doesn’t move forward until it passes the first one, and development doesn’t drag on forever after it passes the second.

The Bottom Line

Before you sink serious time into your next tool, make two commitments:

1. Prove people want it. Research the problem, estimate the market, and test the offer. Your enthusiasm isn’t evidence.
2. Commit to shipping it on a date. Write down the scope, the deadline, what “done” means, and what happens if you miss.

Then follow through.

The goal isn’t to build as many tools as possible. It’s to build the RIGHT tools and get them into customers’ hands. Your time is limited, so spend it solving problems people are already motivated to pay to fix.

Because the most expensive mistake an independent tool builder can make is spending a month building something that a day of research would have told you nobody wanted. 🚀

How about you? Have you ever built something you loved that nobody else cared about? I’d love to hear about it.