My first job was building a Windows program, using an old framework—even at the time, back around 2004–2005—called Microsoft Foundation Classes. It was a thin client, taking UI and UX commands from a custom server framework which we also maintained. A UI component would be defined as a C++ class on the server, its properties stuffed into a byte array, transferred over the wire, and then read and constructed using MFC and Windows drawing APIs. Every 6 months, I asked my manager why we didn’t just build a website instead.
It was the most persistent and complicated Not Invented Here (NIH) software system I’ve encountered in my career1.
Taking a step back, NIH is itself an extreme expression of a question of: should we Buy or Build? For tech companies, this decision is applicable to software systems, products, and sometimes teams: should we go out and pay another company to provide the service, or invest the time and effort to flesh it out internally? And while there is no easy way to converge on the “right answer” for any given situation, I have experienced the common pattern in how organizations swing between the two modes.
Things typically start out in Buy mode. The primary constraint is time, and so it’s easy enough to pay for a service, hire consultants to flesh out an MVP, or “buy into” the most popular open source framework to kickstart development. Buying in the beginning correctly trades commitment for convenience.
Eventually though, there are places when tactical Building makes sense, or at least seems to make sense. Salesforce has too many limitations, and so we should build our own CRM; React is too slow, and so we’ll build our own framework; our QA vendor is dropping the ball, and so we need to bring the function in-house. While I’ve seen this decision made to cut costs2, the majority of the time Building is motivated by optimizing for specific use cases, the ones insufficiently supported by purchased solutions.
Unfortunately, many of these attempts to Build don’t end up working out. The custom web application framework is too limited; the internal tool is too unreliable; the specialized team never found a leader to orient its direction. Building sounded great initially, but few appreciated the difficulty and complexity of what they were replacing, and don’t have the commitment to work through the hard parts to emerge as a truly competitive alternative. More often than not, a decision to Build eventually generates additional work to revert back to a Bought solution.
Building makes the most sense when the individual/team/company believes it can do better than others, and is willing to commit to getting there. In other words, deciding to Build should be synonymous with making it a core competency, a key differentiator that others would have trouble matching without their own dedicated efforts. If you are going to write your own framework, you should have plans to convert all your projects and evangelize it to others; if you need to take an outsourced team in-house, make sure they can be many times more efficient. Anything less and the trade-off in development and costs won’t make a Build worth the time.
With this framing, thinking through what can be Bought vs. Built in aggregate is pinpointing where to apply focus.
Though to be fair, the company had invested in this system predating the web, and I heard by the late 2000s they eventually did scrap it for a Chromium-based client.↩
I distinctly remember one time, an infra. team determined that since Splunk was so expensive, that they assigned an intern to create a replacement in 8 weeks.↩
