Ask the graveyard first
Every idea I have ever been excited about has been tried before. Sometimes it worked. Sometimes it died. Either way, I want to know before I burn a weekend on it.
The founder's cognitive trap
Here's the trap. You get an idea on Friday. By Saturday morning, you can see how to build it. By Saturday night, half of it is built. On Sunday, you find ten people who already built it. Two are still at it. One of them failed. The reason they failed is one you would have hit by Tuesday.
I have done this. More than once. I am a technical founder. I have been writing tools and scripts since long before AI. The reflex to just build is strong. So is the cost of a wasted weekend.
The fix turns out to be one habit. Ask the graveyard first.
What GraveyardCheck actually does
GraveyardCheck is a skill I built into my own setup. It fires on phrases like "I want to build", "is there a tool for", or "what if there was a tool that". Say one, and the agent goes looking.
It looks for past tries. Public repos that fit. Reddit threads where someone asked for the same thing. Hacker News posts. Show HN posts that got six upvotes and no replies. Dead GitHub repos with one star and a half-done README. The dead ones most of all.
Then it summarizes. Who tried this. What approach they took. Where they got stuck. Whether anything is still being maintained. Whether the problem is solved already or just in pieces.
It takes about ninety seconds. What I get back shapes the next four hours of my work.
Why abandoned repos are the best teacher
Most say to study what works. Read the docs of the winners. Take apart the product that won. Sure. That is fine.
I think the dead ones teach more. A dead repo is someone's frozen weekend, three weeks, or six months. The README shows what they thought they were building. The last commit shows where they got stuck. The issues tab shows what users tried to do with it. The quiet after that last commit shows if the problem was the build or the demand.
Half the time the lesson is "this is harder than it looks for a reason that is not obvious from the outside." The other half is "this works fine, the builder just got bored." Both are useful. Both change my plan.
Sometimes I find a repo that is 80% done. No one has touched it in two years. I could bring it back to life with less work than starting from scratch. That has value too.
When to build anyway
Not every search ends with a "do not build." Some end with a green light.
Build anyway when the prior attempts solve a different shape of the problem, when the abandoned repos all hit the same wall and you can see how to get past it, or when the gap is the integration into your specific stack and that is the whole value. Build anyway when the cost of a weekend is small and the cost of being wrong is small.
Don't build if a live team ships it now. Don't build if all the dead repos died on the same hard part and you can't beat that part. Don't build if no one wants it. The graveyard is a demand check too. If no one shipped one, and no one on Reddit asks for one, there might be a reason.
I run this check before any "I want to build" turns into code. It has saved me more weekends than I can count. It is also where some of my best ideas came from, because sometimes the right answer is "fork that one and finish it."
Either way, the graveyard speaks first. Then I decide.
← Back to blog