do it yourself, no matter what

In the world of software engineering, there’s a mantra we’ve all heard: Don’t reinvent the wheel. It’s a sensible guideline after all, why waste time solving a problem someone else has already solved?

But this mindset can morph into something more dangerous: the fear of doing it yourself. The truth is, sometimes reinventing the wheel is exactly what you need.

Not as an exercise in duplicating effort, but as a way to truly own the problem, understand its nuances, and challenge the status quo. Don’t be afraid to think differently and ruffle a few feathers.

The Not-Invented-Here Syndrome

“Not-Invented-Here” (NIH) syndrome is often used as a warning. It describes the tendency to reject external solutions simply because they aren’t created in-house. On the surface, NIH seems like a bad thing; why reinvent a perfectly good library, framework, or process?

But the phrase carries unfair baggage. Sometimes, refusing to adopt an off-the-shelf solution isn’t about ego or stubbornness. It’s about creating something that fits your unique needs, aligns with your team’s principles, or solves a problem in a way that existing solutions can’t.

The Case for Doing It Yourself

I once worked on a project where we needed to implement an event-driven system to handle very complex workflows. At first, adopting a popular event streaming platform seemed like the obvious choice. A strong community, proven scalability, and plenty of integrations seems like a win-win - but as we started evaluating it against our needs, cracks would begin to show.

Our workflows had strict requirements around event ordering, idempotency, and long-term replayability, particularly for compliance auditing in a high security environment. Off-the-shelf solutions provided partial coverage but relied on workarounds or external systems to meet these requirements. We found ourselves questioning: why adopt a solution that solves 80% of the problem when the last 20% introduces so much operational complexity?

We decided to build a custom event processing framework tailored to our use case. It wasn’t about reinventing the wheel for the sake of it. It was about creating something that aligned perfectly with our domain and operational needs. The process also forced us to better understand the core principles of event-driven architecture.

The result wasn’t just a system that fit seamlessly into our architecture - it resulted in a team that had a shared understanding of the problem space and the confidence to tackle challenge in the future.

By taking ownership, we didn’t just solve the immediate problem. We built a foundation for solving future ones better.

Choosing to build in-house isn’t about rejecting external help. It’s about evaluating what truly serves your team and your goals. There are real benefits to reinventing the wheel in the right context:

Ownership and Mastery
When you create a solution yourself, your team takes full ownership of the problem. You understand every line of code, every edge case, and every trade-off. This mastery is invaluable when systems evolve or when something breaks.
Tailored Solutions
Off-the-shelf tools are designed to solve general problems, but they rarely fit perfectly. Building your own solution allows you to address specific needs without the bloat or constraints of third-party tools.
Challenging the Status Quo
Many “standard solutions” persist not because they’re the best but because no one questions them. Reinventing the wheel often leads to insights that push the industry forward.

Think of Unix. Its “do one thing well” philosophy wasn’t about adopting what everyone else was doing but instead rethinking how software should work. That mindset led to a foundation that powers the worlds systems today.

The Risks of Reinventing

Of course DIY isn’t always the best choice. Building something from scratch can introduce significant costs in time, effort, and maintenance. Without careful consideration, NIH can result in over-engineering or wasted resources.

I’ve seen this firsthand. In one project, a team spent months building an internal deployment tool. By the time it was ready, the requirements had shifted, and we realized existing tools could have handled 90% of the job with minor adjustments.

The lesson? Reinventing the wheel needs to be a strategic decision, not a knee-jerk reaction.

Finding the Balance

The key to balancing innovation with practicality is asking the right questions:

Does the existing solution meet 80% of our needs? If so, it might be more efficient to adapt it than start from scratch.
Will building in-house improve long-term outcomes? Consider the costs of maintaining your solution versus the benefits of a perfect fit.
Is this a chance to learn? Sometimes, the process of building is as valuable as the product itself, especially for growing teams.

By reframing NIH as an opportunity rather than a flaw, you empower teams to make thoughtful, deliberate choices about when to build and when to buy.

Driving Improvement Through Ownership

I think the real power of “doing it yourself” lies in the mindset it creates.

Teams that take ownership of their tools and systems are more invested in their success. They question assumptions, identify inefficiencies, and constantly look for ways to improve!

In my experience, the best teams aren’t the ones that always follow industry best practices - instead they’re the ones that challenge them: asking questions, understanding the underlying problems and building solutions that reflect the true needs, not just the spirits of their requirements.

Summary

The next time you face a build-or-buy decision, don’t be afraid to ask if reinventing the wheel makes sense.

By taking ownership of your challenges, you’re not just solving problems. Forget pride - it’s only about creating solutions that align with your goals and strategy.

Building a culture of innovation, mastery, and trust. That’s the real power of doing it yourself.