> then low code environments are great ways to build businesses
Eeeehhhh - it depends on where and how your business delivers value. As others have said, the problem with low-code platforms is they're generally proprietary, which means it's much harder to wean yourself off once you get started - though that's not my main concern: my main concern is that low-code platforms necessarily mean ceding control over your product's E2E: if you accept that for the productivity gains from not having to get bogged-down in the details, sure - but for a lot of stuff it's a very limiting factor.
My current company's focus is a small suite of domain-specific line-of-business SaaS apps - nothing special there. It does mean that our entrenched and incumbent competitors built "unsexy" ASP.NET WebForms (ew) pages over a decade ago and haven't maintained them - or they're relatively modern but built on-top of heavy SPA frameworks that ultimately detract rather than benefit the E2E UX (an egregious example is a competitor that has a traditional SSR web-app, except they load Angular2+ in every single page-load... it's stuff like that which makes users develop negative sentiment around a web-application.
Another anecdote is a simple reporting system built-in to one of our products: again, it's nothing special: just a data warehouse in Azure with some clever hand-written SQL queries to populate some simple HTML tables with ChartJS thrown-in for good measure - and one of our biggest customers' buyers was completely floored by our demo - I thought he was being sarcastic or facetious in the meeting but it turned out that they were using another of our competitors who built their similar reporting functionality using a low-code-ish platform where the web-service is a dumb store of data and the client JS code has to retrieve and process all the data itself... (with no multi-tenant access-controls either) so it took 30+ seconds (and thousands of AJAX requests) for their report to load.
...now you can argue that my anecdotes concern companies that either let their product go stale or had an incompetent (or under-funded and over-worked) development team - but that doesn't detract from my point that low-code tools and platforms make it very difficult, if not impossible, to root-out E2E issues. Having an app with poor performance is bad enough, but having an app where the low-code platform you built-on makes it impossible to address some core user-experience fault is why I have a hard line against low-code in principle. Another example of this is this one particular low-code web-app platform (no names please) which hard-codes in some old version of jQuery which then precludes bringing in other client-side libraries or third-party widgets (think: stuff like ZenDesk chat support, and their widget's bad enough already).
So yes, it's cliche: but "it's a tradeoff" - but just be mindful of exactly what you're trading-away in exchange for developer productivity. You're either the kind of company that looks at, say, Blackboard and either sees them as a success for their large user-base - or you're someone who actually used it and consequently will carry that bad-taste-in-the-mouth over to not recommend purchasing it if they're ever put a position where they make decisions about what software/systems an org buys. My opinion is that the user-experience matters, and low-code tools make it easy to ruin the E2E UX if you're not careful.
Eeeehhhh - it depends on where and how your business delivers value. As others have said, the problem with low-code platforms is they're generally proprietary, which means it's much harder to wean yourself off once you get started - though that's not my main concern: my main concern is that low-code platforms necessarily mean ceding control over your product's E2E: if you accept that for the productivity gains from not having to get bogged-down in the details, sure - but for a lot of stuff it's a very limiting factor.
My current company's focus is a small suite of domain-specific line-of-business SaaS apps - nothing special there. It does mean that our entrenched and incumbent competitors built "unsexy" ASP.NET WebForms (ew) pages over a decade ago and haven't maintained them - or they're relatively modern but built on-top of heavy SPA frameworks that ultimately detract rather than benefit the E2E UX (an egregious example is a competitor that has a traditional SSR web-app, except they load Angular2+ in every single page-load... it's stuff like that which makes users develop negative sentiment around a web-application.
Another anecdote is a simple reporting system built-in to one of our products: again, it's nothing special: just a data warehouse in Azure with some clever hand-written SQL queries to populate some simple HTML tables with ChartJS thrown-in for good measure - and one of our biggest customers' buyers was completely floored by our demo - I thought he was being sarcastic or facetious in the meeting but it turned out that they were using another of our competitors who built their similar reporting functionality using a low-code-ish platform where the web-service is a dumb store of data and the client JS code has to retrieve and process all the data itself... (with no multi-tenant access-controls either) so it took 30+ seconds (and thousands of AJAX requests) for their report to load.
...now you can argue that my anecdotes concern companies that either let their product go stale or had an incompetent (or under-funded and over-worked) development team - but that doesn't detract from my point that low-code tools and platforms make it very difficult, if not impossible, to root-out E2E issues. Having an app with poor performance is bad enough, but having an app where the low-code platform you built-on makes it impossible to address some core user-experience fault is why I have a hard line against low-code in principle. Another example of this is this one particular low-code web-app platform (no names please) which hard-codes in some old version of jQuery which then precludes bringing in other client-side libraries or third-party widgets (think: stuff like ZenDesk chat support, and their widget's bad enough already).
So yes, it's cliche: but "it's a tradeoff" - but just be mindful of exactly what you're trading-away in exchange for developer productivity. You're either the kind of company that looks at, say, Blackboard and either sees them as a success for their large user-base - or you're someone who actually used it and consequently will carry that bad-taste-in-the-mouth over to not recommend purchasing it if they're ever put a position where they make decisions about what software/systems an org buys. My opinion is that the user-experience matters, and low-code tools make it easy to ruin the E2E UX if you're not careful.