Another reason developers wince is these things aren't in version control or follow safe release guidelines. In software, we typically put all our logic and such in git or other version control system so we can see exactly what changes were made, when, why, and by whom. Typically we also have reviews and automated tests before anything can be committed.
Any changes, we release to production slowly, using a combination of canary rollouts (where you only put the new code on one server and watch for a while, to limit the damage in case something is broken) and feature flags (where you slowly release the new feature to increasing subsets/percentages of end users).
Anything that allows modifying your production logic without these safeguards or audit history is considered fraught with danger. Even small things like our own operational dashboards, API authorization settings, or feature flag configurations, we feel unsettled when those are not in our version control system and I've seen plenty of outages caused.
Low-code tools typically don't provide this functionality, or if they do, it's some bespoke thing not integrated into the developers' existing toolset. This is fine for small projects that are only used by a couple people, but for any large public-facing service, this would be considered "unacceptable risk" by most engineering leadership.
For customer-facing apps I found Weweb (Frontend) + Xano (backend) is a great alternative to Bubble since it's way more flexible/portable than current bigger players (standard VueJS apps that you can self-host/Create custom components/Add javascript in their workflow builders, etc...)
Another reason developers wince is these things aren't in version control or follow safe release guidelines. In software, we typically put all our logic and such in git or other version control system so we can see exactly what changes were made, when, why, and by whom. Typically we also have reviews and automated tests before anything can be committed.
Any changes, we release to production slowly, using a combination of canary rollouts (where you only put the new code on one server and watch for a while, to limit the damage in case something is broken) and feature flags (where you slowly release the new feature to increasing subsets/percentages of end users).
Anything that allows modifying your production logic without these safeguards or audit history is considered fraught with danger. Even small things like our own operational dashboards, API authorization settings, or feature flag configurations, we feel unsettled when those are not in our version control system and I've seen plenty of outages caused.
Low-code tools typically don't provide this functionality, or if they do, it's some bespoke thing not integrated into the developers' existing toolset. This is fine for small projects that are only used by a couple people, but for any large public-facing service, this would be considered "unacceptable risk" by most engineering leadership.
For customer-facing apps I found Weweb (Frontend) + Xano (backend) is a great alternative to Bubble since it's way more flexible/portable than current bigger players (standard VueJS apps that you can self-host/Create custom components/Add javascript in their workflow builders, etc...)
This is a fantastic explanation of low-code. I work for one of the companies shown in the examples, you nailed it!
Excellent explanation! I'd love to know what you think about substack's platform
GREAT write up Sophie!!!