How to validate a developer tool idea

Validation cannot prove that people will use your tool. It can only make it cheaper to discover that they will not. That distinction matters, because the goal is not confidence, it is a shorter feedback loop than "six months of building followed by silence".

Developer tools are unusually easy to validate badly. Your audience is friendly, articulate, happy to discuss technical ideas, and completely willing to tell you something is cool without ever installing it.

Separate the two risks first

Every tool idea carries two independent risks, and they need different tests.

Demand risk. Does anyone have this problem badly enough to change what they currently do? Tested by talking to people and watching what they already do.

Feasibility risk. Can it actually be built well enough to be useful, on real inputs rather than your example? Tested by writing the hard part first.

Work out which one would kill the idea faster and attack that one. For developer tools, feasibility risk is underrated: plenty of tools are obviously wanted and quietly impossible, because they work perfectly on a clean repository and fall apart on a nine-year-old monorepo with three build systems. If your idea depends on parsing, inference, or correctness across arbitrary user code, spend the first week on a spike against the ugliest real codebase you can get access to, not on a landing page.

Signals worth trusting

Roughly in ascending order of how much weight to give them.

Existing workarounds in the wild. Gists, shell aliases, Stack Overflow answers with hundreds of votes, internal scripts people admit to maintaining, a wiki page of manual steps. A workaround is proof someone already paid a cost to solve this. It is the most honest signal available, because it happened before you showed up.

Long-lived issue threads in adjacent tools. A feature request with many independent comments over years, especially one a maintainer has declined as out of scope, tells you there is demand and that it is currently unmet. Read the whole thread, including the reasons it was declined, because they are usually the reasons it is hard.

People spending their own time with you. A 45-minute call, then a second one. Someone sending you a real repository to test against. Someone introducing you to a colleague. Attention is a currency developers are stingy with, and repeated attention is a better signal than any single enthusiastic conversation.

Someone asking when they can have it, unprompted. Specifically asking about timing, access, or whether it will work with their stack. That is a different sentence from "that sounds useful".

Your own measured pain. If you hit this problem at work, quantify it before trusting it: how often, how long each time, and what you currently do instead. Write the number down. Founders systematically overestimate how much their own annoyance generalises, and a measurement makes the claim checkable.

Money or a signed commitment. A pre-payment, a paid pilot, a purchase order, or a letter of intent. Hard to get and worth an enormous amount, because it is the only signal that has survived contact with a budget.

Someone already paying for something worse. An existing paid competitor is good news, not bad. It proves a budget line exists, which is the single hardest thing to create from nothing.

Signals that lie

Waitlist signups on their own. An email address costs nothing and commits to nothing. A waitlist is a useful launch asset and a poor demand signal. It becomes meaningful only when you ask a question and people answer it in detail, or when signups keep arriving from a channel you are not actively promoting.

"I would definitely use that." The most common sentence in customer research and the least predictive. People are being kind, and they are answering a hypothetical about a future self who has more time. Replace the question. Ask what they did the last time they had this problem, and how long it took.

Upvotes, stars, and likes on a concept. Applause for an idea measures how well you described it, not whether anyone will adopt it. A well-received post about a tool that does not exist yet is evidence you can write, which is genuinely useful, just not about demand.

Surveys where you described the solution. Once you have explained your idea, you have contaminated the answer. Ask about behaviour and current tools, never about whether they like your plan.

Competitor funding announcements. A raise tells you about a fundraising market, not a product market.

Agreement from people who will not be users. Other founders, advisors, and anyone who wants the conversation to go well. Useful for spotting logical holes, worthless as demand evidence.

Your own excitement. Inevitable, and not evidence. Note it, then go find a workaround somebody else built.

Cheap tests, ranked by what they cost you

You can usually run several of these in two weeks.

1. Search for the workaround. An afternoon. Look through issue trackers of adjacent tools, question sites, and community archives for people describing the problem in their own words. Save the exact phrasings, because those become your positioning and your search terms later. Reading what already exists is part of this: browsing Explore and the categories on a directory of upcoming tools tells you quickly whether four teams are already shipping your idea, and alternatives pages show you which tools people already compare against each other.
2. Do the job by hand for one team. A few days. If you would automate code review, review some code manually and report back. You learn the real inputs, the real edge cases, and whether the output is even useful. This is the highest information-per-hour test available and almost nobody runs it.
3. Build the ugly single-case version. One week. A script that solves exactly one person's exact problem with hardcoded paths and no configuration. Give it to them. Whether they use it twice is the answer. Whether they ask for a second feature is a better one.
4. Write the docs first. Half a day. Write the README, the quickstart, and the example as if the tool existed. This exposes whether the interface is coherent, and it gives you something concrete to show in conversations. If you cannot write a compelling five-line example, the tool does not have a clear shape yet.
5. Post a design note or RFC in a community you belong to. A day. Describing the problem and your intended approach, honestly labelled as not yet built, attracts exactly the people who have the problem. It also surfaces the person who will tell you why this is harder than you think, who is the most valuable person in the exercise.
6. A landing page with a waitlist. A day. Worth doing for the audience it builds, not for the validation. Treat the signups as a mailing list, not as proof. If you do build one, make sure it does not overstate what exists: our guide to waitlist page essentials covers the honest version.

One thing to avoid: a page that implies a working product with a fake demo or invented screenshots. It contaminates the only signal you are trying to read, and developers who feel misled once do not come back.

Ask questions that cannot be answered politely

The interview technique matters more than the number of interviews.

Questions that work:

• "Walk me through the last time this happened. What did you actually do?"
• "How long did that take, and how often does it happen?"
• "What did you try before that, and why did you stop?"
• "Who else on the team deals with this?"
• "If this disappeared tomorrow, what would you switch to?"
• "What would have to be true for you to put this in your build pipeline?"
• "Who would have to approve paying for it?"

Questions that produce noise: anything starting "would you", anything containing your product name, anything where the agreeable answer is obvious. And once you have described your idea, the interview is over as a source of behavioural data. Ask everything else first.

How long to spend

Time-box it, because validation has diminishing returns and unlimited capacity to feel productive.

A reasonable shape for a small team:

• Week 1: desk research. Find the workarounds, the issue threads, and whoever is already shipping something adjacent.
• Weeks 1 to 2: eight to twelve conversations with people who have the problem. Stop when the sixth conversation in a row teaches you nothing new, which is the actual signal that this phase is done.
• Weeks 2 to 3: the feasibility spike, against real inputs you did not choose.
• Weeks 3 to 4: the ugly single-case version, in the hands of two or three people.

Four weeks is enough to be wrong about something cheaply. Six months of validation is not validation, it is avoidance, and no number of conversations will produce certainty.

Write the kill criterion down first

Before you start, write one sentence describing what would make you stop, and date it. Something falsifiable:

If, after 10 conversations, fewer than 3 people describe a workaround they currently maintain, we stop.

If the prototype cannot handle two of the three real repositories we were given, we stop and reconsider the approach.

The purpose is not discipline for its own sake. It is that after four weeks of work you will have become attached to the idea, and a criterion written by the less-invested version of you is the only one you will believe. Most ideas are abandoned far too late, and almost always because nobody wrote down in advance what failure would look like.

When to stop validating and build

You have enough when three things are true: you can describe the problem in the words your users used, at least a few people already maintain a worse solution to it, and you know the hard technical part is possible because you built a rough version of it.

That is not certainty. It never will be. At that point the fastest remaining way to learn is to ship something small to a handful of real users, which is where our guides on recruiting beta testers and the pre-launch playbook pick up.

The honest takeaway

Trust what people already do over what they say they will do, and trust their time and money over their enthusiasm. Spend a month, not a quarter, and write down in advance what would make you stop. The point of all of this is not to find out whether the idea is good. It is to be wrong in four weeks instead of six months, and to be wrong about something specific enough that the next idea is better.