Desarrollo a medida vs no-code: cuándo conviene cada uno

"No-code va a reemplazar al desarrollo." "Las herramientas no-code colapsan a escala." Las dos posiciones extremas son falsas. La pregunta real detrás del debate desarrollo a medida vs no-code no es qué tecnología es superior — es qué herramienta le conviene a qué problema, y durante cuánto tiempo. Hay categorías de problema donde no-code gana siempre, otras donde código gana siempre, y un middle ground donde la decisión depende de variables que cambian cada 18 meses.

Cuándo no-code gana siempre

Procesos internos de empresas no-tech, con < 50.000 ejecuciones/mes, donde la lógica de negocio cambia más rápido que lo que un equipo de devs podría implementar. Ejemplos típicos:

• Workflows de back-office (asignación de leads, envío de remitos, conciliación de pagos básica).
• Dashboards internos para no-técnicos que necesitan editarse sin pedirle al dev.
• Forms y portales internos (Tally, Softr, Glide).
• Automatización marketing/sales (Make, n8n simple, Zapier).
• MVPs ultra-tempranos donde la validación importa más que la arquitectura.

En estos casos, código propio sale 5–10× más caro y se queda atrás del cambio de negocio. No-code es la respuesta correcta — y si lo armás bien, escala mucho más de lo que el discurso anti-no-code sugiere.

Caso típico: una distribuidora con 12 vendedores necesita dejar de asignar leads a mano en un grupo de WhatsApp. Un flujo en n8n (formulario → scoring simple → asignación round-robin → notificación) se arma en 2–3 días por unos US$800–1.000 de setup. Reescribir lo mismo en código propio ronda los US$8.000 y 6 semanas de desarrollo — para un proceso que además cambia de reglas cada trimestre según la temporada de ventas.

Cuándo código a medida gana siempre

• Producto comercial (SaaS B2B, e-commerce propio, marketplace). Tu UX es parte del producto; no podés depender de la UX de Bubble.
• Performance crítico. Más de ~100k operaciones por hora, latencia < 200ms.
• Compliance/security profundo. SOC 2, HIPAA, PCI requieren control de stack.
• Algoritmos propietarios. Si tu IP es código, encerrarlo en una plataforma de terceros es regalar tu valor.
• Integraciones que requieren consistencia transaccional. ACID real, no eventualmente consistente con retries.

Caso típico: un marketplace B2B que procesa pagos entre compradores y proveedores no puede quedarse en Bubble después de superar 8.000 transacciones/mes — los timeouts de los workflows nativos y la falta de control transaccional real empiezan a generar pagos duplicados. Migrar a un backend propio (Node + Postgres) resuelve el problema de raíz, pero suele costar 3–4 meses de refactor bajo presión, con el producto ya en producción, en lugar de haberse construido así desde el principio sabiendo que el volumen transaccional lo iba a exigir.

El middle ground (donde se rompen los proyectos)

Acá viven los proyectos que empezaron en Bubble/Webflow + Airtable y crecieron lo suficiente como para que la herramienta sea cuello de botella, pero no lo suficiente como para justificar reescribir todo. La pregunta no es "¿debo migrar?" — es "¿cuánto vale 6 meses más en la herramienta vs reescribir ahora?"

Señales de que llegaste al límite del no-code:

• Workarounds de tu CTO/dev para hacer cosas básicas (sumar 3 fórmulas concatenadas en Airtable porque no hay subquery).
• Costos de la plataforma superan US$1.500/mes y siguen creciendo.
• Velocidad de release bajó porque toda nueva feature requiere reorganizar la base.
• Tu cliente final (cuando es B2B) pide cosas que no podés ofrecer (SSO, API pública, on-prem).

Dónde se rompe no-code a escala (los límites técnicos que nadie lee hasta que los pega)

• Límites de filas/registros. Airtable y herramientas similares cobran por registro desde cierto plan; pasar de 50.000 a 500.000 filas puede multiplicar la factura mensual por 6–8× sin que eso agregue valor de negocio.
• Límites de ejecuciones. Zapier y Make cobran por "tarea" (cada paso del workflow cuenta). Un proceso que corre 200.000 veces al mes con 5 pasos son 1.000.000 de tareas — en Zapier eso son varios miles de dólares mensuales, cuando el mismo flujo en n8n self-hosted cuesta apenas el hosting (~US$30/mes).
• Degradación de performance en el builder visual. Bubble y herramientas similares se vuelven notablemente más lentas cuando la pantalla o la lógica condicional supera cierta complejidad — no es un bug, es cómo funciona el motor de renderizado del builder.
• Portabilidad de datos. Migrar de Airtable o Bubble a otro stack no es exportar un CSV — la lógica de negocio (fórmulas, automatizaciones, permisos) vive dentro de la herramienta y hay que reconstruirla a mano del otro lado.
• Compliance de nivel enterprise. SSO con SAML, logs de auditoría, data residency específica, SOC 2 Tipo II — muchas plataformas no-code recién lo ofrecen en el plan enterprise (con precio a medida), o directamente no lo ofrecen.

Ninguno de estos límites es motivo para evitar no-code desde el día uno. Son la lista de señales a monitorear una vez que el proceso importa de verdad — así, si la migración a código llega, es una decisión planeada y no un incendio.

Estrategia de portfolio (la respuesta honesta)

Las empresas más eficientes que vemos no eligen una sola cosa. Manejan un portfolio de stacks por categoría de problema:

Tipo de necesidad	Stack recomendado
Producto comercial / SaaS	Código a medida (Next.js, Postgres, etc.)
Back-office cambiante	n8n + Postgres + UI mínima en code
Portales/dashboards internos	Retool, Tooljet, o lovable lo que sea
Marketing site / landing	Framer, Webflow, o Next.js si tenés dev
Forms y captura de leads	Tally, Typeform
Documentos / contratos	DocuSign + automatización con Make/n8n

El anti-patrón del code-everywhere

Una empresa con 6 personas que escribió su propio CRM interno con React y Postgres se gastó 4 meses de uno de sus mejores ingenieros, terminó con un producto inferior a HubSpot, y al año 2 ningún dev quería tocarlo porque nadie lo mantuvo. Ese mismo equipo podría haber comprado HubSpot Starter por US$200/mes y dedicar a ese ingeniero a su producto principal.

Code-everywhere mata startups tanto como no-code-everywhere mata escalas.

Costo comparativo a 24 meses (proyecto típico)

"Portal interno de clientes con login, dashboard, capacidad de subir archivos y dejar comentarios". Equipo a soportarlo: 1 dev senior + 1 PM (medio time).

• No-code (Softr + Airtable + Make): setup US$3.500. Mensual US$280. Total 24 meses: US$10.220.
• Low-code (Retool + Postgres): setup US$9.000. Mensual US$190 (Retool + hosting). Total 24 meses: US$13.560.
• Code a medida (Next.js + Postgres): build US$28.000. Mensual US$120 (hosting). Total 24 meses: US$30.880.

El portal no-code es 3× más barato — y para 80% de los casos basta. El portal code propio gana solo si necesitás UX premium, integraciones complejas, o vas a escalar a 50k+ usuarios.

Comparación a 12 meses: automatización de conciliación de pagos

Otro caso típico: reconciliar pagos entrantes (Stripe/MercadoPago) contra facturas emitidas y marcar pendientes de cobro. Volumen: ~3.000 transacciones/mes.

• No-code (Make + Google Sheets): setup US$600. Mensual US$90 (plan Make + Sheets). Total 12 meses: US$1.680.
• Low-code (n8n self-hosted + Postgres): setup US$2.200. Mensual US$45 (hosting + mantenimiento liviano). Total 12 meses: US$2.740.
• Code a medida (servicio corriendo en su propio backend): build US$9.500. Mensual US$70 (hosting + monitoreo). Total 12 meses: US$10.340.

A 12 meses la diferencia entre no-code y low-code (n8n) es chica — apenas US$1.060 — pero n8n elimina el riesgo de que el proveedor suba precios o límites de tareas de golpe — un riesgo real y recurrente en herramientas SaaS de automatización, donde los cambios de pricing suelen anunciarse con poco margen de negociación para el cliente. Para este volumen, ninguna empresa necesita código a medida todavía: el break-even recién aparece si el volumen mensual se multiplica por 10, o si hace falta lógica de reconciliación no estándar (multi-moneda, split payments, disputas).

Preguntas frecuentes

¿Cuál es la diferencia real entre no-code, low-code y desarrollo a medida?

No-code (Airtable, Bubble, Softr) no requiere escribir código para la mayoría de los casos de uso, a cambio de menos control. Low-code (Retool, n8n) combina bloques visuales con código propio en los puntos donde la lógica no entra en un nodo estándar — es el punto medio real. Desarrollo a medida es código propio de punta a punta: máximo control, mayor costo inicial, cero límites de plataforma.

¿No-code escala?

Sí, hasta donde escalan los SaaS detrás. Airtable banca millones de filas en su plan enterprise. Webflow soporta sitios con millones de visitas. La pregunta no es si escala — es si te conviene económicamente escalar ahí.

¿Quién mantiene el no-code cuando se vaya la persona que lo armó?

El mismo problema existe con código. Documentar el setup (Loom de 15 minutos por cada workflow + README) resuelve 90% del problema. La diferencia es que el no-code documentado lo puede mantener cualquier persona técnica básica; el código documentado requiere mantener el lenguaje y framework.

¿Híbrido es siempre la respuesta?

Para empresas medianas-grandes, sí. Para startups muy tempranas, no — la coordinación entre stacks consume más que el ahorro. Empezá monolítico (todo no-code o todo code) y sumá otra categoría cuando duela.

¿Puedo migrar de no-code a código a medida sin perder los datos?

Los datos casi siempre se pueden exportar (CSV, API). Lo que se pierde si no lo planificás es la lógica de negocio: fórmulas, automatizaciones y permisos que viven dentro de la herramienta no-code y no tienen equivalente exportable. Antes de migrar, documentá cada regla de negocio como si tuvieras que explicársela a un desarrollador que nunca vio la herramienta — ese documento es el verdadero entregable de la migración, más que el código en sí.

Lo que recomendamos

Hacé un inventario rápido de tus sistemas internos. Marcá cada uno como "core" (impacta producto al cliente) o "soporte" (operación interna). El core va a código a medida casi siempre. El soporte va a no-code casi siempre. El problema más caro es confundir las dos categorías.

Si recién empezás un producto nuevo: empezá en no-code si tu hipótesis no está validada. Migrá a código cuando tengas señales claras (revenue recurrente, retención mes-2 > 25%, requests de features que no podés hacer en la plataforma).

Si no tenés claro en qué categoría cae tu próximo proyecto, un diagnóstico rápido lo resuelve: para automatizaciones y portales internos armamos el flujo con automatización no-code; para el producto que sí necesita ser tuyo de punta a punta, trabajamos desarrollo de software a medida. En ambos casos partimos del mismo inventario: qué es core, qué es soporte, y cuánto vale tu tiempo de dev en cada uno.