Você trouxe um ponto muito válido — e que, na verdade, reforça o que o próprio post propõe: não é sobre a stack em si, mas sobre a forma como ela é usada.

O que acontece com muitos projetos no-code (e também com high-code, vamos ser honestos) é que são mal estruturados desde o início, sem visão de médio/longo prazo, sem arquitetura pensada, e com decisões técnicas tomadas apenas com foco em "entregar algo que funcione agora".

O resultado? Código (ou fluxos visuais) difíceis de manter, cheios de gambiarras, com dependências frágeis e baixa flexibilidade para evolução. Isso não é culpa do no-code em si, mas de como ele foi aplicado.

No meu post, inclusive, ressaltei que em projetos mais complexos — com regras dinâmicas, algoritmos pesados ou lógica customizada — pode sim fazer sentido migrar ou complementar com high-code. E essa migração se torna muito mais natural quando o projeto no-code já nasce pensando em integração com backend externo (como Supabase, n8n, APIs próprias).

Ou seja: dá pra escalar com no-code, se for bem pensado, com arquitetura clara e responsabilidade técnica desde o início. Do contrário, vira algo descartável — como você mesmo disse.

E isso vale também pro código tradicional. Já vi sistemas 100% codados que ninguém conseguia mais dar manutenção porque o dev original sumiu, não deixou documentação e criou um monstro técnico.

No fim, tanto o no-code quanto o high-code precisam de visão, arquitetura e boas decisões. É aí que mora a diferença entre uma solução descartável e uma solução escalável.

Obrigado por trazer essa visão. A discussão só cresce com contrapontos assim! 👊