When I first got started in the enterprise software space, one of the very first lessons I was taught was that “it’s always cheaper to buy than it is to build”. This concept was drilled into my brain over and over by managers, respected colleagues, and the industry at large.

As a software engineer (translation: nerd), this rubbed me the wrong way. I suppose I’m tripped up by the “always” part. For example, what if the only product on the market isn’t that great? Is it actually cheaper to adopt a poorly made product and force it down users’ throats? And what if a company is truly unique? Isn’t there value to be gained by leaning into some of those competitive advantages?

One of the things that has me thinking about this a lot lately is the continued advances in cloud technology, low-code development platforms (LCDPs), and AI. Collectively, these tools have raised developer productivity to unprecedented levels (therefore lowering costs). Indeed, here at Bowdark, we’ve seen a 60% productivity increase in development efficiency across the board.

These breakthroughs raise a thought-provoking question: are we seeing enough of a productivity boost to tip the scales in the classic buy-vs-build debate? To test this hypothesis, I thought I would perform a thought experiment out loud to see what (if anything) has changed. Spoiler alert: I think you’ll find that much has changed!

Case Study 1: ERP Solutions

When enterprise resource planning (ERP) software was first introduced to the world back in the early 1970s, the concept of having a consolidated business software package was truly revolutionary. From a business perspective, ERP solutions provided unprecedented visibility into the goings-on across the entire enterprise. Plus, on the technology side of the house, converging onto a single database greatly simplified the IT landscape and reduced operating costs.

Dealing with Bloat in ERP Solutions

Over the years, as ERP solutions grew in popularity, they also accumulated a significant amount of “bloat”. For example, high-end ERP/business suite solutions like SAP and Oracle can, in theory, do just about anything business-wise. While this makes for one hell of a marketing pitch, there are some major downsides to the adoption of one-size-fits-all solutions like this:

• Most customers are forced to pay a major premium for a host of features that they will never use.
• In an effort to provide a consolidated solution that meets the needs for customers across industry sectors, simplicity, usability, and innovation has largely gone out the window.
• Because of the size/scope of these large-scale solutions, implementation/upgrade projects are measured in terms of months (if not years) and complexity is through the roof.

Monolithic ERP vs. Best of Breeds

The alternative to the one-size-fits-all approach is the notorious best-of-breeds (BOB) model where an ERP landscape is stitched together using smaller, more focused and flexible software packages. I use the term “notorious” here with BOB because this approach has been widely ridiculed by large ERP vendors that claim that the cost of integration will kill you or that your visibility across the enterprise will diminish.

While there’s some truth to these claims, it’s worth noting that innovations in cloud technology have leveled the playing field quite a bit:

• Using modern EiPaaS (enterprise integration platform-as-a-service) packages like Azure Integration Services, developers have access to hundreds of connectors and low-code development tools that greatly simplify the integration process. What used to take weeks can now be accomplished in days or even hours — I’m not kidding.
• With the advent of cloud analytics packages like Microsoft Fabric or even vendor-specific packages like SAP Datasphere, reporting/analytics isn’t happening over in ERP systems anyway. If the objective is to build analytics solutions on top of a centralized data lake, it’s really not a big deal to feed in business data from one system or several.

Perhaps the hidden truth in all of this is that it’s all best-of-breeds these days, anyway. Whether you’re an SAP shop, an Oracle shop, etc., the reality is that most ERP vendors have acquired various cloud solutions that are only loosely integrated into the overall ERP solution. For example, if you’re an SAP S/4 HANA customer running SAP SuccessFactors, is there really that big of a difference architecturally if you were to swap out SuccessFactors for Workday? Yes, SAP may provide pre-built integration content to accelerate the integration process, but it’s still BOB at the end of the day.

Figure 1: The Best of Breeds Elephant in the Room

Top-Down vs. Bottom-Up: Which Approach is Better?

In order to put some of these concepts into perspective, consider the graph shown in Figure 1 below. In a nutshell, I think the consolidated ERP vs. BOB debate comes down to finding the right approach to arrive at a solution that meets the needs of your business. In other words, what’s faster/better/cheaper: to start with a one-size-fits-all large-scale ERP solution and enhance/shave it down to meet business needs (a top-down approach) or start with a BOB solution and use low-code tools to fill in the functional gaps (a bottom-up approach)?

Figure 2: Measuring the Implementation Gaps between ERP Customization and Best of Breeds

Although there’s insufficient data out there to accurately project the cost/effort percentages depicted in my graph above, let’s take a look at the tale of the tape with these two approaches from several different angles:

• Cost: This one probably depends on what kind of consumer you are. If you’re a heavy user that leverages most of the modules baked into your ERP solution, then you’re probably getting pretty decent bang for your buck. However, we talk to customers all the time that are only using 1–2 modules of their ERP solution (e.g., finance + something else). For this type of customer, it can be significantly cheaper to just purchase a best-in-class financial module (e.g., SAP S/4 HANA for Simple Finance), surround it with some best-of-breeds solutions (e.g., Workday, Salesforce, or Dynamics 365), and then smooth out the rough edges using low-code development tools.
• Functionality: Again, this comes down to usage. Large-scale ERP packages are jam-packed with many functions and features, but are you really using them? Or, is the out-of-the-box (OOTB) functionality so generic that you’re actually having to work harder to make this module work for your business? With the BOB/bottom-up approach, you should be working from a stronger position in terms of solution fit to begin with, so filling in functionality gaps with low-code development tools should be a much more straightforward exercise.
• Usability: This goes back to the whole generic design concept. Although there’s something to be said about having a consistent UX, those benefits fly out the window if users are stuck on transaction screens that are way too complex to navigate. And, let’s face it, with all the cloud acquisitions in recent years, it’s not like most of the large-scale ERP packages have the same look-and-feel across the board anyway. With BOB, you have much more say in terms of usability as you can carefully select the solutions that best match your business/industry.
• Complexity: Modern business is complex, and there’s no doubt that there are many cases where you just need that industrial-strength “oomph” that comes from large-scale ERP packages. With that being said, this conversation is sometimes about transparency. For example, if you have a highly complex MRP process that no one understands, do you trust it? We’ve seen many customers double-down and adopt 3rd-party “optimization solutions” to replace areas of their ERP solutions that are overly complex and difficult to understand. Obviously, we’re painting with broad strokes here, but these are situations where it at least makes sense to kick the tires on BOB and maybe even look at using low-code development tools to build something that’s tailor made for your business.

Naturally, your mileage may vary quite a bit depending on what you want for your business. Some customers will be happy staying where they are. However, if your core ERP footprint is small, then there are some significant cost savings to be found.

Logically, you can think of low-code/no-code as presenting a door #3 in this debate. Before, you may have been forced to adopt half-baked solutions because there was not an affordable alternative. Now, you have options. You can mix-and-match best-in-class SaaS solutions to build a foundation and then use low-code to bring it all together and make it hum for your business.

Case Study 2: Industry Solutions

As more and more software vendors have moved towards a SaaS model, one of the first things to fall by the wayside has been industry solutions. Although such solutions figure to find their way back onto vendor roadmap eventually, can you really afford to wait 5–10 years to get that hazardous waste management solution you’ve been needing in your business?

I think this is one of those areas where the buy-vs-build debate has skewed too far to the left. With the advent of low-code development tools, even building a temporary solution doesn’t have to be the punt that it was in the past. Indeed, with careful architectural design, you can seamlessly integrate your low-code solution into your existing landscape and model the data in such a way that you can always pivot back to standard later if/when your dream solution shows up in the marketplace.

Nature abhors a vacuum, so you know that the business will step in and cobble something together with Excel or Access if they have to. So, why not build on a more stable low-code platform that can grow/evolve as you figure out your longer-term roadmap?

Of course, this conversation is not reserved to situations where you can’t find industry-based solutions in the marketplace. At the potential price point we’re talking about with low-code solutions, there are situations where it just makes sense to build an in-house solution because you get exactly what you want. In some cases, a custom solution might even help you develop a competitive edge for your business.

Finally, it’s worth noting that the shifting economics have changed to the point that it might actually be cheaper to build certain types of industry solutions than it is to buy them. For example, we work extensively in the utilities space here at Bowdark and have observed multiple cases where the annual cloud subscription/maintenance costs are actually more than what it would cost to just build a replacement solution using low-code development tools. Here, a one-off low-code replacement solution might pay for itself in a matter of months and then you pocket the annual savings for the next 5–10 years. Plus, you get exactly what you want.

Case Study 3: Human Capital vs. Automation

My final case study focuses on the idea that it’s cheaper to just throw bodies at a problem instead of fixing broken processes or automating them. This is another area where low-code platforms really shine. Although most people think of apps when they think of low-code solutions, there are many powerful workflow/automation tools out there on the market — several of which have been infused with powerful AI capabilities.

For example, Figure 3 below highlights one of the canned AI workflows built into Microsoft’s Power Automate solution: invoice processing. As you can see, using the AI Builder tool, we can quickly train an invoice recognition model and extract key data points from scanned images, etc. This data can then be used to automate downstream processes in a backend ERP system, etc.

Figure 3: Automating Invoice Processing with Power Automate

Although we’ve had access to OCR technology and workflow engines for a long time, the perception has been that these solutions are difficult to build and cost a lot of money. So much so that automation projects are frequently dismissed out of hand based on the assumption that throwing more labor resources at the problem is the cheaper way to go.

This is another case where the shift in development economics changes up the game. To put this concept into perspective, let’s sharpen our pencils and crunch the numbers on our invoice processing example:

• If a business processes on average 100 invoices a day and it takes 10 minutes to process each invoice, when we’re essentially talking about 17 person hours or roughly 2 FTEs.
• According to ZipRecruiter, the average salary for an AP staff accountant here in the US is roughly $51,000/year.
• So, if we keep processing invoices by hand, the annual cost to tie up two FTEs on this task is roughly $102,000/year.

Once we understand the baseline costs, it’s a fairly simple exercise to calculate a potential ROI. At that point though, the question is when do we see that return on investment? For example, if we can use low-code tools to deliver a continuous improvement project for ≤ $50,000, then we can build a pretty strong business case. However, there still might not be enough budget available to cover payroll costs and absorb the investment in automation.

This is another area where the use of low-code tools can make a big difference. Cheaper is great, but cheaper and faster is even better. If we can use low-code development tools to deliver the project in ≤ 6 months, then the project makes an impact to the bottom line within the first year.

Zooming out a bit, it’s also important to think about further dividends that can be gained by building automation solution like this. Instead of manually processing invoices all day, imagine if your AP department was freed up to work on more value-add activities? For example, what if they could use that time to analyze supplier performance, spend, or to pursue new sourcing options? And what if we could, once again, supercharge those efforts with low-code and/or AI-infused tool sets?

The key take-away from all this is that recent cloud/low-code/AI innovations have lowered the barrier to entry for automation solutions in such a way that you can save money and get more value out of your business at the same time. It’s truly a win-win.

Closing Thoughts (aka TL;DR)

If you made it all the way to here, then I want to thank you for indulging me in my latest thought experiment. Although it’s easy to get caught up in all the hype/hyperbole that surrounds cutting-edge tech these days, I cannot emphasize enough just how much the game has changed.

The shifts in development economics should make us rethink everything. Last year, I listened to a talk at the inaugural Microsoft Power Platform Conference where a large consulting firm you may have heard of told the story of how they had used low-code solutions to transform many processes across the enterprise. When asked what plan B was if they didn’t use low-code technology, the customer quickly responded by saying that there wasn’t one — it would not have been remotely feasible using traditional development methods.

At the end of the day, these technology innovations create new choices for customers. If nothing else, I hope this article will motivate you to explore some of these new angles to determine what makes the most sense for your business. I think you’ll be glad you did.