Things need to be in balance when deciding build vs buy

The Developer’s Dilemma Series – Rationalizing the Build Versus Buy Equation for Platform

Welcome to Session 2 of my Developers Dilemma series. If you missed the first session, you can read it  here: The Developer’s Dilemma Series – Technical Debt in the Platform Era

If you read that post you will know we are looking at the concept of development, and the technology stack, through the lens of technical debt. Illustrating ways to mitigate that debt, and indeed even make that debt an asset. In this session we are going to take a look at the big decision in the modern development era: Do I build something from scratch in order to get the most “fit for purpose” tool? Or do I buy something knowing that it may not be 100% of what I need, but with benefits that outweigh the gaps? There is not a right answer to this question in that it will always vary from organization to organization. As I wrote in my earlier post, when properly considered through the lens of technical debt, the answer should almost invariably be “both”.

Debt Servicing via a Platform

There is enormous value in shifting technical debt to the platform, leaving you with more capital to specialize in your needs. Increasingly the general response is, “let’s just build all of it ourselves” instead of going with a platform. This attitude is based on a foundation of poor assumptions and rationalizations that look right, but significantly increase the risk of technical debt load.

There are generally three main arguments that circulate amongst developers when dealing with platform adoption. They are phrased differently, but the general gist is Trust, Control, and Suspension of Disbelief (SoD):

  1. What happens if the vendor goes away/fails/has a bug/something goes wrong? (Trust)
  2. You will lock us in and we won’t be able to switch if we want to? (Control)
  3. We can build the same thing/better thing/our thing just as well and really fast. (SoD)

Suspension of Disbelief

Let us deal with the last one first, since it is the most obvious fallacy here. The most common answer we hear in the market when asked about the first wrong assumption made when planning to build you own solution, is time and effort estimation. We see in the market, that developers lean towards the “build it” model with consistent regularity. They focus on the internals, the code, the functions and features, and generally ignore things like time. That last consideration is almost always wrong. Both in real dollars, and level of effort. This is always the case, and I have yet to find an example to disprove this theory.

The car built just for Homer! Literally only useful to one person…

A platform provider is focused on one thing: the functionality the platform provides. That means they don’t waste time trying to build front-ends to fit every possible scenario (we let the customer’s developers do that). It also means they don’t build Systems of Record (they let others do that). What platform providers focus on is eliminating the challenge of getting those things to work together by building the “glue” that simplifies and tightens the integrations of those solutions. A platform frees developers to work on the parts that are most important to the process by simplifying the stuff that no one wants to do anyway.

Create a Platform Balance

Building integration points is a constant struggle because it isn’t just your software that has to work right. You are relying on other providers to make sure they do not make changes or create unanticipated issues that cause your integrations to break. A platform provider has to do that as well, and the outcome is that your platform continues to work the way you expect because they’ve accounted for the underlying changes. Just like you wouldn’t try and build a database, or an identity management solution from scratch, a platform keeps ahead of the curve by anticipating and mitigating changes.

By combining your own code with a platform, you eliminate the need to develop and maintain these types of interactions and instead focus on the core of the experience for your end consumer. This type of “technical debt shifting” is important to factor into your decision as it can greatly improve your own agility. Features and needs will shift constantly and in order to stay in front of that, resources always have to come from somewhere else. By shifting the expectation for this onto the platform, you free your resources to handle the specialized functions and let your vendor manage the integrations. This is the most ideal form of platform partnership. The benefit is both the functionality of the platform and the facility for your own resources to develop against that platform.

Internal Trust

Building a full-stack yourself means you have to deal with all the bells and whistles, integrations, and ultimately the issues that arise from your software. There is NO software that is perfect. That means that even if you build it yourself, you can still have issues and defects. When you move to a platform, what you are putting in place is a partnership that will help you deal with issues, instead of having to rely 100% on internal resources.

If your technical debt load is high, it becomes more likely that those issues may never be resolved. The balance you need to weigh is “do you trust your vendor to be there for you to resolve them”? The simple litmus for this is longevity. There is significant risk in partnering with a new company or an unknown, versus an organization that has been in business for many years. This risk is no different and no less impactful than losing your key internal developer. Both scenarios need to be carefully considered and the underlying exposure to bad debt carefully evaluated.

External Trust

Could I lose this parter? Technology companies are frequently involved in M&A (Merger and Acquisition) activities. That’s the fancy way of saying tech companies get bought and sold a lot. In the Boston Consulting Group’s 2017 M&A report1  , they list that there were roughly 43,000 tech company-related transactions over the last 20 years. That’s 2,150 a year involving tech companies merging and otherwise being bought. This is not a small number of companies being acquired and in all likelihood being fundamentally changed or shutdown altogether. The risk is there and it is worth consideration in the decision.

Internal Trust

Let’s contrast the loss of partner risk with the “technical debt risk” of building something from scratch. Could I lose the holders of that debt, the developers who create that solution? According to the US Bureau of Labor website2 , there were 1,256,200 “Software Developer” jobs in the US in 2016. That number is currently expected to grow 24% in the next 10 years. That means there will be approximately 300,000 new developer job openings over the next 10 years. A staggering 30,000 new job openings per year. With that type of competition in the market it is not just likely, but inevitable that you will lose developers to better paying, more interesting, or simply new jobs in that time.

Put another way, you are 93% more likely to lose a developer(s) than you are to lose a vendor. Before you pull the plug on all development, this is not a death knell for building solutions yourself. It is just a data point that illustrates that whether you choose a platform or build one yourself there are risks. You are choosing where you want that risk to lie.


Lock In

Vendor lock-in is most often cited as the reason for not using a third-party technology. This is particularly true with a platform as they are acting as a core internal component of a solution. They key is to find a platform that offers you the best functional outcome with the lowest friction of movement. The more “black box” a solution is, the harder it is going to be to move off it because you have ceded all the control to the platform provider. That lack of visibility means that recreating the functionality is significantly more difficult.

A fully viable platform has “just enough” openness to allow you to migrate easily to other providers (even home-grown ones). It also offers the advantage of being a comprehensive platform with options you cannot get elsewhere. This idea of the “whole product” approach to platforms allow you to realize value immediately from the platform without complex integration or development, and then grow into it over time by pushing the boundaries of its capabilities. A truly open platform will allow the best of both worlds without forcing you in one direction or the other.

Thanks for reading! Please feel free to leave comments on LinkedIn or Twitter (@charrold303) and give me your feedback!


*citations in this post:*