Skip to content

How Low-Code Affects the Build vs Buy Dilemma


Jun 11, 2021 - 7 minute read

1734 Low Code Build Vs Buy 416X300
Tomasz Filak Director of Financial Services

Tomasz is the Director of Financial Services at Objectivity. He has over 18 years of experience in guiding clients from the United Kingdom and Europe through the digital transformation process. He’s led strategic IT projects worth millions of pounds for customers in various industries, including investment, banking, real estate and retail. 

See all Tomasz's posts

2988 HC Digital Transformation 476X381


Every company relies on software, one way or another, whether they like it or not. Software is either embedded in their products or essential to how they attract and serve their customers, or how they run internal operations. According to predictions, the demand for new software is only going to grow in the following years — the US Bureau of Labor Statistics predicts a growth of 22% between 2019 and 2029.

This means that organisations need an efficient strategy for provisioning new software. Almost every IT strategy includes a written or unwritten policy determining whether the company should build or rather buy the necessary software.

The Traditional Build vs Buy Approach

For many years, the recommendation of analysts and consultants was that businesses should build their own software for the differentiating capabilities that determine their competitive advantage. Since such software is a strategic asset, it should remain in the company’s full control and be available for unconstraint modification in response to changing market demands or company strategy.

On the other hand, the most common advice has been to buy commercial-off-the-shelf (COTS) software, for the non-differentiating capabilities, provided such software was available. Buying is perceived as less time- and resource-consuming approach. It’s favourable when trade-offs in terms of requirements match, and future flexibility and extendibility are acceptable. When a packaged solution meets at least 80% of the company’s requirements, the usual recommendation is that you should seriously consider buying over building. Growth and popularisation of the Software as a Service (SaaS) model makes buying even more attractive, thanks to its promise of quicker benefits and reduced maintenance costs.

While the simplicity and internal logic behind the traditional build vs buy approach seem very reasonable, things can get more complicated in real-life scenarios. As indicated by Forrester in their April 2021 report, when it comes to software, pure buy rarely exists, and pure build is rarely practical. It’s very unlikely that your requirements will be satisfied with a vanilla COTS solution — buying needs to be followed with customisation. Companies that build their software, on the other hand, will usually prioritise re-using readily available components, over building from scratch. Therefore Forrester recommends looking at the problem as ‘customise vs compose’ instead.

The Shortcomings of the Traditional Policy

While the abovementioned standard approach is still accepted by many organisations, it has a few significant flaws.

1. It underestimates the uniqueness of businesses, which leads to the advice to buy more non-differentiating software more often than build. In reality, there is a lot of uniqueness about how each business operates and serves their customers. Internal processes of every organisation, matured and optimised over time, represent its distinctive DNA. For software to bring highest value to your company, it has to be aligned to your business, not the other way around.

2. It assumes the environment doesn’t change fast. It seems impossible to avoid referring to the global pandemic when speaking about change. Shortly after the global outbreak of COVID-19 in early 2020, most businesses worldwide had to radically change the way they operate. For many organisations, the ability to respond swiftly was determined by the capacity to adapt their software. When facing such a sudden change, owning the software and being able to change it freely can be the deciding factor. And as Heraclitus said over 25 centuries ago, change is the only constant in life.

3. It downplays the customisation effort. In reality, customisation involves custom coding, and requires access to scarce resources — professional developers with strong expertise in the particular packaged solution. Very often such customisation introduces future problems with compatibility, while upgrading the core package. It can require unexpected amounts of cost and time. According to Pat Moynihan, former CIO at Primark, CTO at O2 Ireland and IT Director at Vodafone Ireland: When you make a decision to buy software, you work extremely hard to minimise the customisation required. Then the business realises what needs to be changed, usually resulting in large amounts of time and effort, something you never planned for in the beginning.

4. It doesn’t address the unnecessary functionalities of packaged solutions. COTS solutions often include functionalities that go beyond the company requirements. Most organisations only use a small portion of the package they purchased. This issue has to be addressed either by customising the software to limit user access to certain features, or by additional employee trainings.

5. Finally, it doesn’t take into consideration the Low-Code Application Platforms (LCAP). According to the traditional thinking, building software requires traditional software development methods, and is therefore expensive and time-consuming. But now, there are alternative ways of building software. Low-code platforms such as Mendix or Microsoft Power Platform seem to hit the sweet spot thanks to the variety of use cases they can cover, and the software development speed they offer.

Low-Code as an Alternative to Custom Coding for Building Your Own Software

What is low-code? Forrester explains that low-code platforms enable rapid delivery of business applications with a minimum of hand-coding and minimal upfront investment in setup, training, and deployment.

Low-code application platforms are known for their visual approach, and high level of automation of the developer’s daily tasks. This allows the developers to maximise the time they spend on providing the actual business value when creating low-code solutions. At Objectivity, thanks to over 3 years of experience in delivering complex solutions to our clients with LCAP, we regularly observe our low-code projects finishing consistently 3-5 times faster than equivalent traditional coding estimates. Very often these projects also require smaller teams than the ones carried out in the classic approach.

The other important advantage of leading low-code platforms is their multi-channel approach. An application built once can be run on a wide range of devices (including mobile and tablet) and accessed across multiple channels, such as chat-bot, text messages and MS Teams chats.

While visual approach helps developers build the software fast, it also changes the way in which people without the IT background can contribute to software projects. For some, this will mean the ability to see, understand and review the system’s business processes. For more tech savvy employees, low-code platforms enable a no-code approach, in which software is created purely through visual modelling. No-code allows them to build their own, less complex applications, which in turn enable them to improve their personal or their team’s productivity.

As opposed to other platforms, which offer rapid development capabilities, such as BPMS (Business Process Management Suite), the General Purpose LCAP cover wide range of solutions and use cases. Mature Low-code platforms are fit for digitalising operations, building customer-facing solutions, as well as building core systems and systems of record.

The benefits of low-code have become attractive not only in the context of building solutions. The development speed, democratic approach and multi-channel capabilities led many COTS providers to adopt low-code as an extension mechanism used to customise their products. For example, Microsoft has now ported most of their Dynamics 365 suite onto the Power Platform, and the low-code approach is the default way of customising their package. There are many more examples, such as Siemens Mendix and SAP partnership, in which the package providers partner with or develop their own low-code platforms to enable more efficient customisation of their software. At Objectivity, we have also successfully used low-code to extend other packages such as Oracle Retail.

Example – A Custom CRM System at a Price of a Packaged Solution

When our client, a high street jewellery retailer operating worldwide, decided to digitalise their customer loyalty and marketing processes, their natural first instinct was to look at ready off-the-shelf CRM systems. As a customer-centric company, they care about making every single one of their customers feel special.

With their unique process and unique customer insights, it became clear that an off-the-shelf CRM solution would require significant customisation. However, building their own CRM with .NET or Java would have been cost-prohibitive. As their technology partner, Objectivity suggested another way, which was building a custom CRM system utilising the Mendix low-code platform.

This way, we delivered a significantly more cost-efficient solution that was fully tailored to the client’s needs. Furthermore, they can now benefit from the new ability to turn ideas into production changes much faster than it would be possible in the case of a packaged solution, or a system built with traditional coding.


It’s time to consider a new approach to the traditional build vs buy dilemma. Forrester’s John Bratincevic, in his report Now Tech: General-Purpose Low-Code Development Platforms, Q1 2021, recommends: ‘Digitize Everything — Always; Use Low-Code To Accelerate’.

Building software more often than buying can help companies become more competitive, agile, and responsive to changes. With the use of low-code platforms, the level of time and resources traditionally associated with building your own software can be cut down significantly. This eliminates one of the main advantages buying had over building.

It’s also important to note that building vs buying is often no longer an either-or debate. When you look at the problem as customising vs composing software, low-code emerges as an effective and elegant approach to customising and extending commercial off-the-shelf packages.

If you’d like to identify low-code use cases within your organisation, download our latest “Solving Business Problems with Low-Code: Use Cases & Benefits” eBook.
2988 HC Digital Transformation 476X381
Tomasz Filak Director of Financial Services

Tomasz is the Director of Financial Services at Objectivity. He has over 18 years of experience in guiding clients from the United Kingdom and Europe through the digital transformation process. He’s led strategic IT projects worth millions of pounds for customers in various industries, including investment, banking, real estate and retail. 

See all Tomasz's posts

Related posts

You might be also interested in


Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.