Blog · Idea validation
Killing ideas early is a builder's superpower
Every builder has a graveyard of side projects. The graves that hurt aren't the ideas that died — they're the ones that died late, after the weekends, the rewrites, and the launch nobody noticed.
Talk to any builder long enough and you'll hear about the one that got away with six months of their life. Not a bad idea, exactly — a plausible one, which is worse. Plausible ideas survive contact with your doubts. They rack up commits and weekends and "almost ready" milestones, and by the time reality delivers its verdict, the cost isn't the idea. It's everything you fed it.
Why ideas die late
It's rarely a knowledge problem. Halfway through, most builders already suspect the truth. The idea keeps going anyway, for reasons that have nothing to do with evidence: sunk cost — "I've put in too much to stop now" — and identity. Somewhere along the way, "I'm building an invoicing tool" became "I'm the person building the invoicing tool," and killing the project starts to feel like killing a version of yourself.
Coding agents quietly made this worse. When progress is cheap, the signal that something is wrong — "why is this so hard?" — never fires. The repo grows. Momentum reads as validation. It isn't.
A kill is a verdict, not a failure
The way out is to change what "killing an idea" means. A failure is when reality decides for you, months in, with an audience of zero. A verdict is when you decide, early, on evidence: this assumption was tested, it did not survive, we stop here. Same idea, radically different cost — an idea killed in week one costs a week; the same idea killed in month six costs half a year, plus the confidence you'll need for the next one.
A good kill has three properties. It's evidence-backed — you can point at the test that failed, not just a mood. It's recorded — the reasoning is written down, because killed ideas come back and future you deserves to know why past you said no. And it's final for now, not forever — "kill" means "not this, not now, on this evidence," which leaves the door open when the evidence changes.
Not everything deserves the axe
An honest gate has four outcomes, and kill is only one of them. Sometimes the answer is build — the risky assumption survived a real test. Sometimes it's validate more — the evidence is mixed and another cheap test settles it. Sometimes it's pivot — the problem is real, your solution isn't. The point isn't to be trigger-happy. It's to make the decision on purpose, at a moment you chose, instead of letting the project decay into abandonment — the slow no-decision that teaches you nothing.
What killing early buys you
Every early kill is a transfer of resources to your next idea: weeks of building time, intact motivation, and credibility with the people you'd ask to try the next thing. Builders who kill fast get more shots on goal, and shots on goal are most of the game. The graveyard stops being shameful and becomes what it actually is — evidence that you test ideas honestly.
Where Motriz fits
Motriz makes the kill decision a first-class part of the journey, not an admission of defeat. Every idea runs through nine founder questions to a gate where the co-founder lays out the evidence for, the evidence against, and the open risks — and returns one of four honest verdicts: build, validate more, pivot, or kill. Whatever you decide is recorded with its reasoning. If the answer is stop, you just had the cheapest failure of your career — and your next idea starts with everything this one taught you.
Earlier in this series: the validation gap and how to validate an idea before you build it.
Give your next idea an honest gate.
Download Motriz for macOSFree during early access · No account · See the nine questions