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
The trap goes like this. You get an idea on a Friday. By Saturday morning you can already see the architecture. By Saturday night you have a half-built prototype. On Sunday you find the ten people who already built it, two of whom are still active and one of whom failed for a reason 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 triggers on phrases like "I want to build", "is there a tool for", or "what if there was a tool that". The moment I say one of those, the agent goes looking.
It searches for prior attempts. Public repos that match the description. Reddit threads where someone asked for the same thing. Hacker News posts. Show HN submissions that got six upvotes and no replies. Abandoned GitHub repos with one star and an unfinished README. Especially the abandoned ones.
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 costs about ninety seconds. The output reshapes the next four hours of my work.
Why abandoned repos are the best teacher
The popular wisdom is to study what works. Read the docs of the winners. Reverse-engineer the successful product. Sure. That is fine.
I think the dead ones teach more. An abandoned repo is somebody's frozen weekend, three weeks, or six months. The README tells you what they thought they were building. The last commit tells you where they got stuck. The issues tab tells you what users actually tried to do with it. The silence after the last commit tells you whether the problem was the implementation 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% there, has not been touched in two years, and could be revived for less effort than starting from scratch. That is also valuable.
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.
Do not build when somebody active is already shipping it, when the dead repos all died on the same hard problem and you have no edge on it, or when the demand signal is missing entirely. The graveyard is also a demand survey. If nobody finished one of these and nobody on Reddit is asking 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