Low-Code és Deute Tècnic amb Interfície Bonica
Les plataformes Low-Code oculten deute tècnic davall una capa visual que no pots auditar. Analitzem quan té sentit usar-les i quan construir en codi propi és l'única opció viable.
Bubble té més de 3 milions d'aplicacions construïdes en la seua plataforma. Retool presumeix que el 40% del Fortune 500 usa la seua ferramenta per a apps internes. Els números sonen bé fins que fas una pregunta que cap comercial de Low-Code vol respondre: què passa amb eixes aplicacions dins de tres anys?
No amb les demos. No amb els prototips de hackathon. Amb les que van acabar gestionant comandes, controlant inventari o calculant comissions d'un equip comercial de 40 persones. Les que van començar com "una prova ràpida" i van acabar sent infraestructura.
Eixes aplicacions tenen un problema que ningú veu perquè la interfície continua funcionant: estan acumulant deute tècnic per davall. I és deute que ni tan sols pots auditar.
El problema invisible: deute que no pots llegir
El deute tècnic convencional és roín, però almenys és teu. Tens el codi font. Pots obrir-lo, llegir-lo, mesurar la seua complexitat ciclomàtica, passar-li un linter, fer refactoring. És com tindre una hipoteca: saps el que deus i pots planificar com pagar-ho.
El deute del Low-Code funciona d'una altra manera. No tens codi font. Tens fluxos visuals, connexions arrossegant caixes i una capa d'abstracció que genera codi per davall al qual no tens accés. Quan alguna cosa falla a les 10 de la nit un divendres, no pots posar un breakpoint. No hi ha stack trace que llegir. Obris un tiquet de suport i esperes.
El que tens, en la pràctica, és complexitat operativa ficada dins d'una caixa negra que li pertany a un altre.
Com expliquem en Programari com a Actiu d'Inversió, el programari que construïxes hauria d'aparéixer en el teu balanç com un actiu. Si el codi no és teu, no hi ha actiu. Hi ha una despesa recurrent disfressada de ferramenta.
Quan Low-Code sí que té sentit
Seria deshonest dir que el Low-Code no serveix per a res. Serveix. I hi ha contextos on és el més intel·ligent que pots fer.
Per a prototips i validació d'idees, per exemple. Necessites comprovar si un flux de treball funciona abans d'invertir en desenvolupament, muntes alguna cosa en Retool o Glide en tres dies, ho proves, ho tires. El problema comença quan no ho tires.
També funciona per a ferramentes internes amb data de caducitat. Un dashboard per a un event, un formulari per a una campanya de tres mesos, un flux d'aprovació que usa un sol departament durant una transició. Si saps que allò morirà, el Low-Code estalvia temps sense generar risc.
I per a automatitzacions simples entre SaaS. Connectar Slack amb Google Sheets amb un CRM usant Zapier o Make té sentit si la lògica és lineal i no toca dades sensibles.
El problema no és usar Low-Code per a açò. El problema és que les empreses comencen per ací i acaben amb Bubble gestionant el seu flux de facturació. Això ja no és una ferramenta temporal. És infraestructura core construïda sobre terreny llogat.
El punt de no retorn
Hi ha un moment en què una aplicació Low-Code deixa de ser una solució i es converteix en un llast. La majoria d'empreses ho descobreixen tard perquè els senyals són operatius, no tècnics. No apareixen en un error de compilació. Apareixen en reunions.
La plataforma condiciona el producte. Quan el teu equip comença a dir "això no es pot fer en Bubble" o "AppSheet no suporta eixa lògica", la ferramenta ha deixat de facilitar. Ara limita. Estàs adaptant la teua operació al programari en compte d'al revés.
El cost de llicència escala més ràpid que el teu negoci. Les plataformes cobren per usuari, per registre, per execució o per emmagatzematge. A escala modesta — 50 usuaris, 100.000 registres — els costos comencen a sorprendre. I el que és pitjor: escalen amb el teu creixement, no amb el teu valor. Creixes un 30% en registres i pagues un 60% més de llicència.
Necessites un "desenvolupador de Low-Code". Açò és el que més em crida l'atenció quan ho veig. La complexitat de l'aplicació requereix contractar algú especialitzat en la plataforma, i en eixe moment has perdut l'únic avantatge que tenia el Low-Code: que no necessitaves programadors. Ara tens un programador que només sap operar una ferramenta propietària. Coneixement no portàtil. El dia que se'n vaja, ningú més entén com funciona allò.
Framework de decisió: un arbre per al dilluns
Si has de prendre esta decisió la setmana que ve, fes-te estes tres preguntes per ordre.
El procés que vas a digitalitzar és el nucli del teu avantatge competitiu? Si és el que et diferencia de la teua competència, el que genera marge, el que toca directament al client, construïx en codi propi. El teu avantatge competitiu no pot dependre dels termes de servei d'un tercer.
Esperes que l'aplicació continue en ús dins de 18 mesos? Si no, usa Low-Code sense remordiment. Per a això va bé. Si sí, torna a la primera pregunta.
El teu equip ja diu "això no es pot fer en [plataforma]"? Aleshores ja has arribat al punt de no retorn. Cada mes que continues ací és temps i esforç que no recuperaràs quan migres.
Hem documentat la matriu de decisió completa en la nostra guia de Programari a Mida vs Low-Code, on desglossem quan cada opció té sentit segons el tipus de projecte.
La pregunta correcta no és "quant costa construir açò?". És "quant m'està costant cada mes no haver-ho construït bé des del principi?".
Com abordem açò en SAUCO
En SAUCO no tenim res en contra del Low-Code. De fet el recomanem per a prototips i validacions ràpides. El que no recomanem és confondre un prototip amb un sistema de producció.
Els nostres enginyers FDE es fiquen en l'operació del client i construïxen amb codi obert i modern — Next.js, Go, Python, PostgreSQL — ferramentes que escalen sense sostres artificials i sense caixes negres. El codi és del client des del primer commit. Si demà volen canviar de proveïdor o muntar equip intern, poden fer-ho sense reescriure res.
La velocitat de lliurament no és el problema que pareix. Amb la metodologia FDE, una primera versió funcional ix en 2-4 setmanes. Comparable al Low-Code en temps. La diferència està en el que passa després: als tres anys, el que construïm continua ací i continua sent teu.
Tens una aplicació Low-Code que s'ha convertit en infraestructura crítica? Consulta la nostra guia completa de Programari a Mida vs Low-Code o, si ja saps que necessites migrar, parlem directament.