When to build and when to buy; on the lure of building software

Photo by Nathan Aghelsefat Abatari on Unsplash

So, you’re faced with the challenge of deciding between building your own software or buying something off the shelf.

Your customers might need new features, your staff may need some help running a process specific to your business or investors might want to see the value of their investment increase through the creation of unique intellectual property. Shipping your own software product seems like the obvious answer to keep everyone happy.

Let me give you some advice: unless you are genuinely a ‘tech’ company you should almost always buy rather than build. Building software is invariably the wrong answer for the majority of companies.

Building products is a siren song; investors see busy development teams as a means of creating a strong valuation. Product Managers want to deliver unique and exciting products to happy customers. Engineers want to build stuff. Executives see product delivery as a sign of unique capability and strategic value.

But, that’s not how it works.

There are a whole bunch of reasons why building software — or building a software development capability — is the wrong decision for many companies.

Why do you even want to build something? Is your requirement so unique that you can tolerate the very significant cost of shipping code, or is that just your ego talking?

Instead, start from a position that taking the decision to build requires solid evidence that you will create significant competitive or commercial advantage by building it yourself.

Reasons not to build

Oh, how many reasons there are not to hire engineers and build software. Let me count the ways;

1. Building software is expensive. Really expensive. Building software products is a lot cheaper than building something physical like trainers, pharmaceuticals or houses, but it’s still fraught with complexity.
2. Running the things you built is even more expensive than building them. You may understand the cost to build a product, but you almost certainly haven’t budgeted enough to support it in the future. Software products don’t keep running on their own and will need to be supported, improved, patched and ported to new technology in the future. If you really want to build, plan your ‘run’ costs carefully. Expect it to be at least twice the figure in your head, and add n (where n is a very large integer indeed).
3. Cut-corners will start to cost as your use of the product grows. Even if you are building for internal users where you can potentially nip a few nice-to-have features (like security and UX*) from the spec, those costs will add up if your business grows. I have rarely (if ever) seen an internal software product that was as well built, maintainable, secure or useful as a ‘good’ enterprise software product.
4. You are unlikely to be able to compete with an equivalent product that is sold to many clients. If it’s someone’s sole job to build a product (let’s say Salesforce building a CRM), it’s extremely unlikely that you’ll be able to build an equivalent product more cost effectively (even than an expensive vendor, like, say, Salesforce).
5. It’s easy to be overtaken. If you are building a generic product (for example, ‘a search engine’) it’s easy for an industry giant to sneeze and accidentally release a product which jeopardises your whole business model (cf: the look on the job board industry’s face when Google Cloud Talent Solution was announced). Suddenly, you have paid an awful lot to developers and your competitors all have access to better technology than you.
6. It’s slow to attain the expected value. It won’t just be more expensive, it will also take way longer than you were expecting. While you pat yourself on the back for your cleverness and hire a team of engineers, designers and architects, you’ll barely have delivered your login page before your competitor (who bought a SaaS product from a tech startup) has real users on their system.
7. Assume you’re going to get hacked. Seriously. Building software these days isn’t just complex, but invariably exposes your product to the world as a service. Don’t assume it’s going to be secure. Assume that someone is going to try and steal your valuable data. Budget to develop defensively with security in mind from the outset (which will further increase the cost). And, in case that fails, get some PR training for when you need to explain why you lost all your customer details.

Reasons to build

Occasionally, when the stars align and the data supports it, it might be the right choice to build your own software. Here’s a few times that building your own software really is a great idea.

1. An off the shelf product doesn’t exist to solve your problem. If you can’t buy a product, or mix multiple other partial solutions, you are probably going to have to build your own software. This happens less often than you think, you beautiful and unique snowflake.
2. Your IP is rare or unique, and there is considerable value for you as a business to own either the unique capability (for instance, the dating algorithms at eHarmony) or the intellectual property (for instance, the Colonel’s secret spice blend).
3. You plan on creating a business, or product line, supplying the software and will be able to provide it to a number of customers, thus leveraging your investment.
4. You can claim financial assistance for building — for example, in the UK, the government’s R&D tax credits can support the development of genuinely novel intellectual property.
5. You have a bunch of smart developers sat around, waiting for work to do**

On Capitalising Software Development

I’ll briefly mention one other ‘benefit’ which can be credited to build over buy which I find very hard to justify but is regularly (mis)used by larger companies; capitalising software development costs. This is a financial treatment which can be attractive, particularly for publicly listed companies where shareholders scrutinise company accounts closely and the markets react with alarm to any change to expected financials in earnings calls. Capitalising development costs can help offset tax on profits.

There are some accounting benefits for preferring capital costs over operating costs (for instance, for young, investment heavy tech businesses protecting their annual accounts from too much loss which might scare clients), however I would generally argue that it produces an overall increase in costs and reduction in efficiency for very little long term benefit.

This approach requires a very questionable position on the value of the product being created. Software products being treated as an asset generally do not exceed the value of their engineering, which means this is more a game of accounting silly-buggers than a genuine reason to capitalise.

I always prefer the simplicity of operating expenditure wherever possible. You can read more about why capitalising development costs is generally a poor accounting idea, here.

We will add your biological and technological distinctiveness to our own

All this might sound like I’m eschewing the value of engineering completely, in favour of a vendor management and procurement patchwork with little unique value. Let me make clear that I’m not, as engineering can, in the right situation, offer massive benefit to the company. Instead, think of buying software as stocking your palette with more colours to paint with.

Value and strategic positioning isn’t derived from ‘building software’, but rather from developing a set of unique capabilities that offer value to your customers. The crux of my argument is that it is normally more pragmatic and economical to stock your palette with point solutions and then blend them together to suit your business and customers. Sometimes you’ll need to throw a little engineering fairy dust into the mix.

A CRM on its own? That’s table stakes. A CRM which delivers data into a data warehouse, which links to a multi-touch attribution engine that helps you follow your customers through their lifecycle? That’s becoming be valuable.

Collecting and processing user data to predict outcomes and provide customers with a rich and intelligent workflow that directly helps them make better decisions? That’s valuable, and you certainly don’t need to build every part of it.

To really use technology you need to make sensible decisions about what to build and when. You need to make sure that you’re blending the palette uniquely for your organisation.

A warning about buying; it’s not all butterflies and rainbows

Becoming reliant on procurement can have it’s own pitfalls, most often that purchases are considered to be a one-and-done investment with insufficient consideration to maintenance or replacement. This leads to poorly supported legacy systems that no-one in the business knows how to support, leaving the rotting carcass of some enterprise software festering in the corner of the IT department’s portfolio. For those of us who have seen poorly managed Microsoft Exchange servers or Salesforce implementations, the cost to those businesses is very real, and very painful.

When buying and maintaining software, as much discipline is required as in engineering, albeit of a different sort. Control of costs, contract negotiation, vendor management, renewal, termination and replacement cycles all need a specific set of skills to manage.

Many of the warnings about building software can be applied to buying it, so do make sure that you develop a competence in managing an external portfolio rather than leaving the management of outsourced tech to chance.

To recap; Buy it , then blend it, but don’t build it (unless you have to)

In my experience, software engineering teams normally take twice as long as they think to deliver an MVP, and even then it won’t usually pass a third party penetration test first time" - Marcus Corner, CTO.

It is more common that I work with a company that is building things unnecessarily, rather than having bought things that they shouldn’t have. So let me recap on why you shouldn’t build software unless you absolutely have to. Compared to buying software that’s already on the market it is normally;

1. More expensive
2. More complicated
3. Harder to maintain
4. Slower to generate value
5. Less secure

So you’re paying more for functionality which is less secure, harder to maintain and takes longer to benefit from.

Perhaps counter intuitively all of these things make building software less Agile than the faster, cheaper approach of buying something. This doesn’t mean that I don’t value the work of software engineering teams; in those situations where building is the right approach, engineers create massive value (let’s face it, all those things you’re buying are created by engineering teams).

Take a considered and pragmatic approach to build vs buy, understanding the very considerable cost and complexity of engineering projects; buy it, then blend it, but don’t build it (unless you can really prove it’s necessary).

* In case it’s not obvious, these are bad things to cut corners on

• * That was a test. That’s a very bad reason

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +426,678 people.

Subscribe to receive our top stories here.