Low code has been around since the late 80s. It got going when client-server architecture was the rage. However, in nearly 40 years, it has remained a niche. So it will be interesting to see how AI tools like ChatGPT change things.

When companies should develop software

The ONLY time a company should embark on internal software development is when that new software will create significant business value for the company.

I worked for Netflix in the early days. Netflix developed a front end that, to its customers, WAS Netflix. There was nothing else like it on the market. That front end is still used today, even though the business has changed from mailing DVDs to providing content online. That front end delivered so much value that Netflix destroyed Blockbuster, its chief rival in the DVD rental market.

However, Netflix didn't code its internal systems to handle HR, accounts payable, etc. Instead, they bought that software. Why? Because there was no business value in writing software that was easily purchased.

Business value is NEVER in the form of "it's cheaper to build than to buy." And the moment you hear somebody saying, "How difficult can it be?" you know they haven't the slightest clue about software development.

When companies should NOT develop software

When low-code projects start, everything goes well because you are "harvesting the low-hanging fruit," the easy projects with a big return. But as the code base grows, all the usual software development problems eventually appear. For example, few companies document what they develop, so maintenance gets more challenging as time passes and employees leave.

I often tell CEOs that "Your company's business is its business. You are not in software development." If you build your own ERP, you are designing that software for a customer base of ONE.

Generally, companies don't attract top-tier software architects who prefer to work at "real" software companies. So the software architecture is left up to the developers. I recently spoke with a CEO who said they had designed themselves into a corner with their internal development and had to rethink their approach. Months of work were wasted.

Several years ago, we were helping a company replace an ancient ERP system maintained by an 86-year-old developer. Only he knew their code well, but they were unsure how much longer he would live. Sure enough, halfway through the project, he passed away. So while it is hard enough to recruit software developers, it can be near impossible to find people with experience in your particular low-code tool when you need to replace somebody.

Low-code limits

Every low-code or no-code tool has its limits. You WILL run into a wall at some point. Low-code tools will do about 90% of what you want with 10% of the effort, but getting the last part of the project done can take more time and effort than all of the first 90%. 

I recently chatted with a highly experienced software developer who said that his low-code tool could not do what was needed. If he had access to the underlying database, he could have written a query to get the data needed, but the low-code tool did not give that level of access. So he had to find another way to achieve what the business required.

Conclusion

While companies are unique in HOW they do things, WHAT they do is seldom unique. For example, there are uncountable variations in HOW goods or services are invoiced, but they all produce invoices at the end of the day.

With apologies to Milton Friedman, the purpose of a corporation is to create value. Customers convert that value into cash. Many companies think HOW they execute their business processes adds value when it rarely does. Instead, their value comes from WHAT they provide.

With over a thousand ERPs on the market, there is little reason to develop an ERP system, even with a low-code tool. It is always FAR more work than expected. Companies should only build software if it creates significant value for the business. And only the business can answer that question.