The hidden costs of low-code tools

There has been a recent boom of powerful off-the-shelf tools that allow non-programmers to build and operate software systems that can run a business. There are some big advantages to using these tools - folks closer to the business domain can build solutions, you can prototype products to find product-market fit without investing heavily in tech, and you don’t have to reinvent the wheel, to name a few. However, everything comes with tradeoffs, and there’s one in particular I want to highlight - when you store your data in a third party, you don’t control how you get to interact with it.

There are some obvious downsides to this. First, you may need a view of the data that just isn’t available. Or, you may want to write the data in a way that isn’t possible - perhaps a batch update for performance reasons. This may force you to replicate the data, and operate on a shim application that sits in front of the third party tool.

This gets to a downside that can be very, very costly - third party tools force you into a distributed system early on, and can necessitate that you build more components and data stores in the distributed system than your org really needs.

Consider that the major upside of third parties is that you need fewer engineers in order to build features. If you have a small team of engineers, though, they will likely build a relatively simple monolithic application that solves the problems your business needs solved, and nothing more. A small team operating a distributed system, some components of which they don’t control, is going to spend a lot of time grappling with difficult distributed systems problems, that are entirely orthogonal to your product needs.

Controlling APIs matters a lot in distributed systems design. If you have distributed data, a major problem you will run into is providing some form of consistency for that data. There are significant tradeoffs here - the CAP Theorem, a simplification of these tradeoffs, states that you have to choose between availability and consistency in all distributed systems.

As an example, say you have data stored in Airtable and a shim application that many of your users interact with. Some simple operations in your shim may require many hundreds or thousands of requests to Airtable - maybe you needed to build the shim to get around that constraint. This pattern doesn’t scale, and you’ll run into rate limits which essentially make Airtable unavailable to you. You then have to choose whether your application is unavailable, too, or whether to accept updates and risk concurrent and conflicting updates that threaten consistency. You can’t change Airtable’s API, so distributed systems solutions like 3-phase commit or causal consistency models aren’t an option.

I think this risk is mostly hidden to those making the decision to opt for off-the-shelf tooling over engineering, because of the technical nature of distributed systems problems. If they were aware of this, it may change the cost/benefit calculation of betting on non-engineers using powerful low-code solutions, versus a small team of engineers building a simple solution to the business’s problems, as many startups have done in the past.

We’re at an interesting point in the experiment with low-code off-the-shelf solutions driving software systems for early stage startups. The tools have been around long enough for some products to have been built on them, but we are just now getting to a point where those products are reaching maturity. Now is a good time to consider whether the promised value of low upfront cost and non-engineer development have panned out to be net-positive.