Sorry, didn’t see this comment before, so here’s a very late response that now has the benefit of being informed by more maturity in the no-code/low-code space. I think that these tools are great for early-stage companies and products, especially when your product isn’t unique tech. A tech-enabled service company — which actually describes many current “tech” unicorns — can go a long way toward proving product/market fit and refining their business thesis using off-the-shelf tools now, and I actually recommend that a lot of companies build their MVPs this way. The most important thing is getting your company and your product in front of potential customers, so if a no-code tool helps you get there quickly and cheaply, do it.

A couple of caveats:

1. If you’re a tech-forward company and your product is a unique or complex implementation of new software, then obviously you need to code it yourself, either from the ground up or leveraging open source components. Of course, if you’re building this kind of company then you had better already have one or two really strong engineers on your founding team so no-code has much less appeal for your core tech.
2. At some point, you’re likely to outgrow a no-code/low-code platform, so you need to prepare for a transition in the future. Generally this comes after the business has grown significantly and has the funding to invest in proprietary tech that lends unique efficiencies to the business, so we’re talking about a Year 2 or 3 problem. It’s usually clear that it’s time to rebuild when the tools are either slowing the team down or the configurations have become so complex that they represent a significant pseudocode layer that’s as complicated as code would be. This is fine and should be part of your overall growth plan so that it doesn’t represent a surprise expense. I actually tell every company I work with that they should plan to throw their MVP away and rewrite it after 6–12 months anyway, so this is no different.

These tools have improved a lot in the past couple of years, and I think they’ll continue to do so. The more they can allow non-engineers to build while abstracting the complexity of code, the better, because it enables more companies to get off the ground quickly while reserving the really interesting/unique problems for engineers to tackle.