Where Do Low-Code and No-Code Fit in the Build vs Buy Debate?

I thought it might be my imagination, but Google Trends confirms that “build vs buy” really is coming up more often these days that it had in recent years. 

This surprises me, since I had thought that debate was over. It seemed that most organizations had accepted the default position of buying when possible and building only when necessary.

In the world of customer data management, I’d say the reason for the new interest in building systems is that corporate IT is more involved than before. Remember the growth in marketing and sales technologies was due mostly to the fact that marketing and sales teams could often buy what they wanted as a Software-as-a-Service subscription, with little or no involvement of the central IT team. Marketing and sales leaders had no interest in building software, and even martech and salestech groups were more oriented to selecting and implementing systems than building their own. But as customer experience rose to become a primary corporate priority, a trend accelerated by the pandemic, it became more important to integrate marketing and sales systems with the rest of the company. Privacy rules created a parallel pressure for corporate-level involvement. And corporate IT groups are much more likely to at least consider building their own system.

It’s a less obvious why interest in build vs buy should have also grown in the broader IT world. One possibility is that the growth of low-code and no-code options made building your own systems more attractive alternatives. I can’t really say the Google Trend data bear this out, since the dip in build vs buy interest happened after the initial growth in low-code development. The correlation is better for no-code although there are probably other, equally plausible explanations.

What’s more important is that no-code and low-code do change the terms of the build vs buy debate. One way to think about this is to break the software development process into four main components and see who does what under each approach. Those four components are:

• requirements definition: this is identifying system goals and what functions it needs to reach those goals. It is (or should be) done by users regardless of the development approach.

• process creation: this is the design and building of the system processes that meet the requirements. It’s the core of the development process. It’s done by IT under “build” and “low-code” approaches, by the users themselves under “no-code”, and by the software vendor under “buy”.

• platform creation: the is the development and maintenance of the structures that support the system processes. It doesn’t really have a separate existence in “build” or “buy” approaches, where it’s tightly intertwined with process creation. But it’s distinctly separate in “no-code” and “low-code”, since it’s purchased from the software vendor rather than built by either users or IT. (Note: even “built” systems rely on purchased technology, such as operating systems and database engines. We can ignore that for present purposes.)

• integration: this is connecting the system with other corporate systems. It’s always done by the IT department, which often argues it’s more work to integrate a purchased system than to connect a home-built one. (In many cases, they’re probably right.)

You can visualize the four development approaches as a column chart showing the distribution of work by department:

This diagram highlights several points worth considering:

• users are always responsible for defining their requirements. That should go without saying, but there’s sometimes an assumption that a highly-rated package will have all the features they want, so there’s no need to define their requirements or check out the package in detail. In fact, it’s probably the most common mistake that people make when buying software. It applies equally to “no-code” systems, where a particular required feature may not be built into the system’s capabilities. Best to know that in advance.

•  IT is always involved. If nothing else, they’ll do the integration work. In practice, they’ll also be vetting any purchased system against security, privacy, reliability, and other standards. This is another thing that should go without saying, but they should be part of the any process from the start.

• The real battle is over process creation. This is where either users, vendors, or IT may end up doing the work. The key question then becomes which group is best equipped to handle this task for any particular project. If the processes are mostly limited to individual users, who may each have their own preferred way of doing things, then letting the users define their own process with no-code makes sense. If the processes are shared by many users and fairly standard for the industry, a purchased package will likely work the best. If the processes are unique to the company, but not exceptionally odd, a low-code package should work. If the processes require capabilities that won’t be well supported in a low-code package, then custom-building the system is probably the best choice. 

This thinking is summarized in the matrix below, which proposes that the appropriate choice depends on two binary variables: process variety (is the process the same for all users or do they each want their own) and process difficulty (either defined in terms of absolute complexity, or of how unique the process is to the company compared with others in the industry). 

The underlying logic of the matrix is that packaged systems, whether no-code or bought, make the most sense when the underlying processing is simple or common to the industry, while IT involvement via low-code or build is required to create complex or unique processes. When IT is involved, the productivity advantages of low-code are most important where individualized processes mean a great deal of customization is needed. The productivity advantages of low-code are less critical where there is one shared process to create, and any limits on the complexity imposed by low-code may be more important. (I’m not entirely convinced this matrix is correct, but it’s a good starting place for discussion.)

• The magnitude of each component has an unclear role in the choice. It might seem that projects with very complex integration requirements should be built by IT, while those with extensive user requirements should let users create their own no-code solutions. But if a purchased platform supports the integration needs, their complexity doesn’t matter. Similarly, if the extensive user requirements are well understood and stable, it’s a waste of time for users to build them for themselves. If anything, extensive and stable user requirements would favor a purchased system, assuming the system is already meets them.

Beyond these specific propositions, I think it’s generally helpful to break a project into these components when thinking about the right development approach. They’re all important and are different enough to treat separately to ensure they’re all considered. If you have other thoughts on how to apply them, or can offer a better approach, please share your comments.