The Graveyard in Your GitHub: Why Engineers Can't Stop Building Tools Nobody Asked For

Open any senior developer's GitHub profile and scroll past the pinned repos. Keep scrolling. Eventually you'll hit it — the graveyard. A CLI tool that parses CSV files in some novel way. A custom deployment script that almost replaced the one the team uses. A Slack bot that was going to change everything about standups. All of them abandoned. Most of them never shipped to a single real user.

This isn't a productivity problem. It's a pattern, and it's worth understanding.

The Itch We Can't Stop Scratching

Ask developers why they start these projects and the answers are remarkably consistent: "The existing tool didn't do exactly what I needed." "I wanted to learn Rust." "It would've taken longer to configure the third-party option than to just write it."

That last one is the trap. Engineers are wired to estimate the cost of integration and immediately compare it to the fantasy of a greenfield build. The integration path has visible friction — reading docs, dealing with someone else's abstractions, accepting limitations. The build path has invisible friction because it doesn't exist yet. You're comparing a real obstacle to an imaginary smooth road.

Marcos Delgado, a backend engineer at a mid-sized fintech company in Austin, describes his personal record as "three separate queue management systems" built across different jobs. "Every time I'd look at something like RabbitMQ or even SQS and think, this is overkill, or this doesn't fit our exact model. So I'd start building. And then six months later the team would be maintaining my thing instead of something with actual documentation and a community."

He's not alone. This is so common it has informal names in developer circles — yak shaving, toolchain maximalism, infrastructure astronautics.

The Organizational Fuel

Individual psychology explains part of this, but organizations make it worse in specific ways.

First, there's the autonomy signal problem. In a lot of engineering cultures, building something from scratch reads as initiative. It signals ownership, technical depth, and creativity. Choosing an existing solution can feel like admitting you didn't think hard enough — even when it's clearly the smarter call. That social dynamic quietly pushes engineers toward building when they should be integrating.

Second, internal tools exist in a weird accountability vacuum. If you're building a customer-facing feature, there are stakeholders, deadlines, and usage metrics. If you're building a developer productivity tool for your own team, you're often your own product manager, your own QA, and your own user. That setup sounds empowering but it removes almost every forcing function that keeps scopes reasonable.

Jen Hartley, an engineering manager at a logistics startup in Chicago, watched this play out with her team's observability stack. "We had a perfectly good setup with a combination of tools we'd paid for. But one of our senior engineers was convinced we were leaving performance on the table. He spent about six weeks building a custom metrics aggregation layer. It was genuinely impressive code. It also never got fully integrated and we eventually turned it off."

The cost wasn't just the six weeks. It was the maintenance burden that accumulated in the meantime, and the opportunity cost of what that engineer could have shipped.

The Three-Stack Spiral

The title of this phenomenon — the three-stack problem — comes from a pattern several developers described independently. You start a side project or internal tool. It needs a data layer, so you build or choose one. Then you realize the data layer needs a caching strategy, so you add that. Then the caching layer needs monitoring. By the time you've made three foundational infrastructure decisions, you've created a small ecosystem that requires ongoing maintenance to stay coherent — for a project whose original goal was to scratch a single itch.

Each stack is individually justified. Together, they guarantee the project never ships.

"I call it going vertical when you should be going horizontal," says Derek Osei, a staff engineer in Seattle. "You keep solving the problems underneath the problem instead of just solving the original problem and shipping something."

A Framework for Actually Deciding

So what's the alternative? A few heuristics that developers and managers have found genuinely useful:

Time-box the evaluation. Before you write a line of custom code, give yourself a fixed window — two hours, maybe four — to seriously evaluate existing solutions. Not a lazy five-minute Google, but a real look. If nothing fits after that window, you have a more honest case for building.

Write the maintenance memo first. Before starting any internal tool, write a short document explaining who will maintain this in six months and what that maintenance will involve. If you can't answer that question, you're not ready to build.

Separate learning from shipping. If you want to learn Rust, that's completely valid. But be honest that the project is a learning exercise, not a production tool. Treat it accordingly. Don't let the learning project creep into your team's infrastructure.

Define done before you start. What does a finished version of this tool look like? What does it do and — critically — what does it explicitly not do? A project without a definition of done will expand to fill whatever time you give it.

Ask who the user is. Even for internal tools, identify a specific person whose workflow this improves. Not "the team." A person. If you can't name them, you might be building for yourself in a way that won't generalize.

The Build Versus Buy Conversation You're Actually Avoiding

Here's the uncomfortable truth underneath all of this: the impulse to build from scratch is often a way to avoid a harder conversation. Sometimes the existing tool is fine and the real issue is that the team hasn't agreed on how to use it. Sometimes the workflow problem isn't a tooling problem at all — it's a process problem or a communication problem that no amount of custom code will fix.

Building is easier than having that conversation. It feels productive. It produces artifacts. It lets you stay in the comfortable space of technical problem-solving instead of the messier space of organizational problem-solving.

The graveyard in your GitHub isn't evidence of wasted talent. Most of those abandoned projects involved real skill and genuine effort. But shipping something nobody uses — even to yourself — is a signal worth paying attention to. The question isn't whether you can build it. It's whether building it is actually the move.

Sometimes the smartest thing you can ship is a decision not to.