You’ve been assigned to lead development on an important new feature for your company’s mobile app. This customized recommendation engine will be the backbone of a major update to increase key metrics like MAUs. It’s an extremely tight deadline, with the CEO stating that hitting the launch date is critical. You know your team needs to get coding right away.
As you dig into planning, you recall that a best-in-class third-party AI-powered recommendation platform could provide 80% of the needed functionality. Excited about the time and effort this could save, you set up a meeting with the CTO to pitch this solution. Surprisingly, he outright rejects the idea without even reviewing the specifics.
“I don’t trust third-party black box code and AI systems,” he states. “Those could recommend anything. We need total control and transparency here — this is too critical.” You calmly push back, listing all the advantages: faster time-to-market, lower costs, superior AI capabilities. But he won’t even engage in a dialogue. The answer is a decisive no.
Reluctantly, you pull your team off two other mission-critical features you already committed to, re-tasking them to build everything from scratch. It soon becomes clear that replicating an enterprise-grade recommendation system is quite challenging. Simple changes require days of rework rather than minutes. Bugs crop up in the flawed homegrown algorithms. Your team falls further behind by the week, missing milestone after milestone.
The CEO grows furious as the promised launch date seems impossible. The product team warns of mass user frustration without the new feature. Your engineers are burning out from the relentless pace. But still, your CTO refuses to budge from his “not invented here” stance — even threatening to fire if outside code or systems are suggested again for critical aspects. As the promised launch date approaches, you feel completely stuck, pressure building up rapidly. Something has to give soon before the entire project collapses under its own weight.
Building Everything Ourselves: Where it Goes Wrong
I do understand the CTO in the imaginary but oh-so-common story above. You want to create things in-house. You have brilliant people and pride in what you build. But constantly reinventing the wheel, even when good solutions exist, can backfire,
First, you wind up doing duplicate work. Your rockstar developers spend their days coding software that’s already out there! Just think what else they could build if freed up from routine tasks. Their creative ideas get sidelined while recreating essential functions.
Second, frankensteining together homegrown parts makes things way more complicated. Every new module means more dependencies to manage. Before you know it, your systems are fragile lab experiments that break unexpectedly. Nobody understands how all the pieces are glued together or how to update them, so maintenance and improvement tasks take forever.
Finally, you risk getting stuck with specific teams and skill sets. Your risks increase dramatically if you rely on one guru or insider group for every software solution. What if they decide to bail or their expertise goes out of fashion? Then, you scramble to fill gaps as your projects stumble.
It’s tempting to keep building everything internally. However, mixing custom-built and existing solutions is smarter in the long term. It keeps complexity in check, so you stay nimble. And it lets your rockstars focus innovation on the 20% of work with a real competitive advantage.
When Should We Build Instead of Buy?
External solutions also aren’t always the perfect fit. They can overcomplicate things or require messy customization to work with your existing systems. Sometimes, crafting something from scratch tailored to what you need is a better option.
Relying on some vendor’s product means all you have is hope they’ll keep supporting and updating it. If they decide to stop or shut down the product, you’re on your own, usually with little time to migrate elsewhere. If you build it yourself, you call the shots down the road. No messy transitions or trying to extract your data if the company goes under.
Besides, your own team knows its niche problems and use cases best. Rather than putting square pegs in round holes by using a general-purpose product, you can leverage that insider perspective to engineer the ideal solution. Sure, some reinvention of the wheel is involved. But if off-the-shelf options can’t fully tackle the intricacies of your situation, it may be worthwhile.
“Not invented here” thinking gets a bad rap, but it has its place. The costs of custom building can pay dividends versus being stuck with software debt and processes that don’t work. The control and perfect fit may justify taking the build versus buy route. Does it always warrant reinventing the wheel? No. But it’s not always a wrong instinct either.
Finding the Right Balance
As engineers, we’ve all faced the “build vs. buy” question. It comes down to objectively considering each project’s unique goals and constraints. First, clearly define the must-have functionality and document exactly what challenges the solution aims to solve. Get input from both technical and business stakeholders so you understand what success looks like from all perspectives. This makes evaluating options much easier later on.
Next, do your homework and research relevant solutions that could potentially meet those needs with some configuration. Reach out to colleagues who have used these tools for candid feedback — the pros and cons you won’t find in vendor pitches. Analyze both the upfront and ongoing costs of integrating each against building ourselves. There are always tradeoffs to weigh.
Finally, check your natural biases at the door. As engineers, we do suffer from “not invented here” syndrome — dismissing existing tools solely because we didn’t create them. But this decision shouldn’t be based on emotions. Focus on what approach genuinely serves our specific problem best.
Finding this balance point takes a thoughtful analysis of our situation and an unbiased perspective. But trying to objectively weigh all alternatives helps us choose the optimal solution for every challenge.
Originally published on Medium.com