En esta nota (6 secciones)
La pregunta llega casi siempre con la misma forma: "vi que con Power Apps esto se hace en una semana, ¿por qué me estás cotizando dos meses?".
Es una buena pregunta y merece una respuesta honesta, que no es "el low-code no sirve". El low-code sirve, y bastante. Lo que pasa es que resuelve un problema distinto al que la mayoría cree estar comprando.
Qué es cada cosa, sin marketing
Low-code / no-code. Plataformas donde armás una aplicación combinando piezas ya hechas: formularios, tablas, flujos, pantallas. Microsoft Power Apps, Google AppSheet, Retool, Bubble, Airtable, Zoho Creator. La lógica se configura, no se escribe, y la plataforma se encarga del resto.
Desarrollo a medida. Se escribe el código. Todo lo que la aplicación hace, lo hace porque alguien lo definió, y no hay nada que la plataforma decida por vos.
La diferencia real no es "arrastrar contra escribir". Es quién controla las decisiones que no tomaste: la base de datos, dónde viven los datos, cómo se autentica la gente, qué pasa cuando hay mil usuarios a la vez, y qué versión de todo eso vas a estar usando dentro de tres años.
Dónde el low-code gana claramente
No hay ninguna razón para escribir código en estos casos.
- Herramientas internas de equipo chico. Un panel para que administración cargue algo, un ABM interno, una vista sobre datos que ya están en otro lado. Retool y AppSheet están hechos exactamente para esto.
- Formularios y flujos de aprobación. Un pedido que pasa por dos firmas y termina en una planilla. Configurarlo lleva horas.
- Prototipos para validar. Antes de gastar en desarrollo, armar algo funcional y ponerlo frente a usuarios reales. Barato, rápido y descartable a propósito.
- Cuando ya vivís adentro del ecosistema. Si la empresa tiene Microsoft 365 y los datos están en SharePoint, Power Apps ya está pago y ya está integrado.
En todos estos casos, cotizar desarrollo a medida es venderle a alguien algo que no necesita.
Dónde el low-code se choca
Los límites no aparecen el primer mes. Aparecen cuando el proyecto crece, que es el peor momento para descubrirlos.
El techo de la lógica. Las plataformas cubren muy bien el 80% habitual. El 20% restante —tu regla de precios con siete condiciones, el cálculo de comisiones por escala, la validación que depende de tres tablas— o no se puede, o se puede con un rodeo que después nadie entiende. Y ese 20% suele ser exactamente lo que te diferencia.
El costo por usuario. Es la sorpresa más común. El low-code se cobra por usuario por mes, y el número que era razonable con 10 usuarios deja de serlo con 200. Un desarrollo a medida tiene costo alto al principio y marginal por usuario cercano a cero; el low-code es al revés. Hay un punto de cruce, y conviene calcularlo antes, no después.
El rendimiento con volumen. Estas plataformas funcionan muy bien con miles de registros. Con millones, empiezan a mostrar límites que no podés optimizar, porque no controlás las consultas.
La dependencia del proveedor. Esta es la que más pesa a largo plazo. Lo que construiste no es portable: no hay código para llevarse. Si la plataforma cambia los precios, discontinúa un servicio o modifica cómo funciona algo, no tenés alternativa más que aceptarlo o rehacerlo desde cero.
La pregunta no es cuánto cuesta entrar. Es cuánto cuesta salir, y si esa cuenta la podés pagar el día que haga falta.
Las integraciones fuera del catálogo. Si el servicio con el que necesitás hablar tiene conector, es trivial. Si no lo tiene, entrás en el terreno de los rodeos, y ahí el low-code deja de ser más simple que escribir código.
Las cuatro preguntas que resuelven la decisión
Contestalas honestamente y la respuesta aparece sola.
1. ¿Cuánta gente lo va a usar dentro de tres años?
Multiplicá esa cifra por el costo por usuario de la plataforma, por 36 meses. Compará ese número contra el presupuesto de un desarrollo. Es una cuenta de dos minutos que casi nadie hace.
2. ¿Lo que hace especial a tu operación está dentro de este sistema?
Si el sistema es administrativo y tu diferencial está en otro lado, low-code. Si el sistema es tu diferencial —la forma en que despachás, cotizás o asignás—, a medida.
3. ¿Lo van a usar personas de afuera de la empresa?
Clientes, proveedores, la fuerza de venta externa. Acá el low-code se complica en dos frentes: la licencia por usuario externo, y que la experiencia va a tener la cara de la plataforma, no la tuya.
4. ¿Qué pasa si mañana no podés usar esta plataforma?
Si la respuesta es "reconfiguramos en otra en dos semanas", adelante. Si es "perdemos la operación", estás poniendo el negocio arriba de una decisión comercial ajena.
El escenario intermedio, que es el más frecuente
Casi nunca es todo o nada.
Lo que mejor funciona en la práctica: a medida el núcleo, low-code la periferia. El sistema que sostiene tu proceso central se desarrolla y es tuyo. Los formularios internos, los tableros para el equipo, los flujos de aprobación de vacaciones y las herramientas que usan cuatro personas, se arman en la plataforma que ya tenés y se cambian sin llamar a nadie.
Esto también es una buena señal para evaluar a un proveedor. Alguien que te cotiza desarrollo para un formulario interno de aprobación no está mirando tu problema, está mirando su facturación.
Y al revés: si te dicen que todo tu sistema de gestión, con integraciones y usuarios externos, se resuelve en tres semanas de configuración, pedí que te muestren un caso parecido funcionando con tu volumen.
Una forma barata de no equivocarse
Cuando la decisión no es obvia, hay un camino que casi siempre conviene: armá la primera versión en low-code, aunque pienses migrar.
En un par de semanas tenés algo funcionando, con usuarios reales usándolo. De ahí salen dos cosas que ningún relevamiento te da: descubrís los casos que nadie mencionó, y comprobás si el techo de la plataforma está lejos o cerca.
Si a los seis meses la herramienta sigue alcanzando, ahorraste el desarrollo. Si no alcanza, llegás al desarrollo con el alcance definido por el uso real y no por una reunión, que es la diferencia entre un presupuesto que se cumple y uno que se estira.
Lo único que hay que hacer bien en ese camino es no engancharse: la versión low-code se construye sabiendo que puede ser descartable, y los datos se guardan de forma que se puedan exportar el día que haga falta.