Marketing Tech: to Build or to Buy?

software

A key decision any business seeking growth has to ask itself is whether to build or buy in order to address software requirements.

Some decisions are easy. No right-minded organisation is going to set about writing email clients or IMAP servers when they are readily available to buy or rent fairly cheaply in the cloud.

Other decisions are less clear cut. For example, when it comes to the content management, CRM, HR, finance and payroll applications an organisation may need.

Commercial off the shelf software (COTS) has the advantage of being relatively easy to get up and running, as well as being fairly cheap.

But if there is a competitive advantage to be gained by building your own solutions, it has to be worth looking at. Especially if you are planning on scaling the company to a size where this competitive advantage will deliver a meaningful return, and the cost can be spread over a large customer base.

It all comes down to the functionality and processes you’re trying to facilitate. Let’s look at the processes that may play out:

Generic functions

Sometimes the function the software is going to provide is clearly defined and operationally siloed. The company payroll, for example, could be regarded as a function unlikely to deliver direct business differentiation. So a rigid COTS solution is a good fit. There is no competitive advantage to be had, everyone expects to be paid accurately, on time, and you can’t really exceed that expectation. So it’s very likely you won’t have to interrogate this one too much.

But even in this example additional things like commision payments and shift payments mean it’s worthwhile examining exactly what inputs and APIs the COTS offering provides, and how likely you are to be able to integrate to them. Understanding the full cost of ownership of the COTS offering is vital. Development licenses, contractor costs, and per-seat ownership models all need to be understood beyond the more obvious day one license costs.

Specialised functions

If the function of the software is to be highly specific, and/or core to the company’s offering (it may indeed be the offering itself), then building is the only solution you should consider.

Whether to do this in-house, outsourced with permanent staff or via contractors, is a different topic for a different article. But, if you do it well, you will end up with something that not only matches your singular organisational requirements, but is also flexible and adaptable enough to cope as these requirements grow.

One such application developed in-house at MVF is our Data Aggregation tool, which pulls data from our new media partners. Establishing the optimal way to call partner APIs and turn the varied data sets generated into our preferred unified format is extremely specialised. Finding such a COTS product would be difficult, and even the delay from using an external agency to code against the specifications would present a risk. Building our own solution in-house was an easy choice to make in this instance.

The halfway house

There’s always an exception to the rule, though; the awkward example, where it’s not quite built from scratch and it’s not off the shelf. These situations are often difficult to account for ahead of time, unfortunately. One such example is the story behind our CRM system.

In the early months of MVF the decision was made to use the popular open source application SugarCRM. The application quickly enabled MVF to manage its customer relationships, and was extendable enough that customer fields and processes could be added, which was great. But we soon became more demanding.

As MVF grew, more custom functionality was added, and the application became more integrated to the company’s various workflows. More and more of the UI became custom designed, until eventually only some of the underlying data structures were related to SugarCRM, and the custom UI screens morphed into a standalone highly specific CRM.

This fifty/fifty solution represents an interesting hybrid approach to the ‘buy versus build’ decision. And shows, once again, that adaptability and an agile approach are needed to ensure your tech team supports business growth in the best ways possible.

This piece highlights some of the issues even sophisticated tech companies, like MVF, face when it comes to deciding how to deliver against business technology demands. Challenges such as limited budgets to hire additional coders, limited time for software development and the changing priorities of the organisation are all par for the course. And all further underline the importance of evaluating all aspects of the ‘buy or build’ questions that will underpin your ability to continue facilitating growth.