Saltar al contenido
Softronic
← Volver al blog

Low-Code vs código a medida en 2026: la pregunta de $44 mil millones

El mercado low-code llega a $44B en 2026 (Gartner). Dónde funciona, dónde se rompe, y la regla aburrida para cuándo abandonar la plataforma y construir a medida.

7 min de lectura Por Softronic low-codeno-codesoftware-a-medidasaas

Gartner ahora dimensiona el mercado de desarrollo low-code en $44 mil millones para finales de 2026, creciendo aproximadamente 22% año contra año. Retool levantó a billones. Bubble tiene cien mil usuarios pagos. Microsoft Power Platform es el item individual más grande en muchos presupuestos IT enterprise.

Y aun así la mitad de nuestros leads este quarter son “lo construimos en low-code, se está rompiendo, ayuda por favor”.

Ambas cosas son ciertas. Low-code es una categoría real, útil. También tiene modos de falla muy predecibles. Este post es el manual aburrido sobre cuándo usar low-code, cuándo abandonarlo, y cómo se ve realmente una migración.

Qué hace bien low-code

Seamos honestos sobre los wins antes de la crítica. Low-code se gana su market cap con valor real:

  • Apps CRUD internas. Tracker de inventario, panel admin simple, portal customer-facing donde el modelo de datos son 3-5 tablas y el workflow es “lista, filtra, edita, guarda”. Retool, Appsmith, o incluso Airtable + interface block pueden shippear esto en 2 días donde custom tomaría 2 semanas.
  • Formularios y flows de intake. Typeform, Tally, Jotform. Genuinamente no hay razón para construir formularios custom en 2026.
  • Automatización de workflows internos. Zapier, n8n, Make. Triggers de emails de sales-ops, notificaciones Slack, ETL básico entre herramientas SaaS. Un backend custom para esto es overkill.
  • MVPs para testear una idea. Bubble o Lovable pueden poner un producto clickeable frente a usuarios en una semana. Si el producto no agarra tracción, ahorraste meses.
  • Prototipos para buy-in de stakeholders. Un prototipo low-code funcionando obtiene sign-off ejecutivo más rápido que un deck de Figma. Shippea el prototipo, consigue el presupuesto, después decide si lo mantienes o lo reconstruyes.

Usado en estos cinco buckets, low-code es una de las categorías tecnológicas de más alto ROI en software moderno.

Dónde low-code falla consistentemente

Luego está el otro lado del inbox. Aquí están los cinco modos de falla que vemos una y otra vez:

1. Lógica de negocio compleja metida a la fuerza en un builder visual

En el momento en que tu lógica “si esto entonces eso” se anida cuatro capas profundo, la representación visual se vuelve más difícil de leer que el código que estaba reemplazando. El workflow drag-and-drop que se suponía “le permita a no-ingenieros mantenerlo” ahora es un grafo spaghetti de 200 nodos que solo la persona que lo construyó puede descifrar, y esa persona se fue en marzo.

Las apps Bubble con este problema son las más difíciles de migrar. La lógica está medio documentada en flows visuales, medio codificada en comportamientos de plugins, y no hay test suite porque las plataformas low-code rara vez tienen testing de primera clase.

2. Performance a escala

La mayoría de plataformas low-code están bien con 10 usuarios y 1,000 registros. Con 5,000 usuarios y 5M registros, te chocas contra una de tres paredes:

  • La DB es la DB de la plataforma. No puedes agregar índices, no puedes tunear queries, no puedes shardear. Le pagas a la plataforma por un plan más grande y rezas.
  • La curva de pricing es exponencial. Bubble, Retool, Mendix tienen planes donde el costo sube no-linealmente con el uso. Hemos visto apps low-code de $400/mes inflarse a $8,000/mes en 18 meses de crecimiento.
  • El runtime es opaco. Cuando una página tarda 9 segundos en cargar, no puedes profilearla. No puedes agregar caching en la capa correcta. Abres un ticket de soporte.

3. Vendor lock-in

Tu código vive en su plataforma. Si la plataforma cambia pricing (Salesforce hace esto regularmente), es adquirida (múltiples plataformas low-code han sido adquiridas y re-priceadas en los últimos 24 meses), o simplemente cierra (el producto general-availability de Coda, RIP), tienes una migración forzada en un schedule que no controlas.

Código custom estándar en frameworks estándar (Next.js, Postgres, AWS/Vercel/Fly) se porta entre providers. Las apps Bubble no se portan a ningún lado. No hay botón “export a código estándar” que produzca un codebase mantenible, a pesar de lo que algunas plataformas claman.

4. Multi-tenancy y requerimientos de seguridad

Si estás construyendo SaaS B2B que necesita multi-tenancy apropiado (row-level security, aislamiento de tenant, configuración por tenant), las plataformas low-code son uniformemente malas en esto. Fueron diseñadas para uso interno mono-org. Atornillarles tenancy produce o agujeros de seguridad o complejidad inmanejable.

Lo mismo para evidencia SOC 2. Los auditores quieren logs, access controls, encryption, historial de code review. Las plataformas low-code producen quizás la mitad de lo necesario. Terminas escribiendo controles custom alrededor de ellas y la auditoría se vuelve más difícil de lo que habría sido para una app custom.

5. Costos ocultos que componen

El costo de titular es la fee de plataforma. El costo real incluye:

  • Especialistas específicos de plataforma. Un developer senior de Bubble es más caro que un generalista que puede trabajar en Next.js, porque hay menos y cuestan dinero real retener.
  • Plugins y add-ons de terceros. Cada uno es una fee mensual y un futuro punto de falla.
  • Workarounds para escapar limitaciones de plataforma. Bridges de webhook, sidecars, wrappers de código custom alrededor de la app low-code. Cuando agregaste todo esto, tienes un sistema híbrido y lo peor de ambos mundos.

La regla aburrida: cuándo abandonar la plataforma

Usamos un checklist simple. Si puedes responder sí a 3 o más de estos, planea migración a custom ahora, antes de que el costo crezca más.

  1. Tienes 5 o más workarounds. Plugins custom, webhooks a servicios externos, syncs manuales de data. La plataforma ya no está haciendo el trabajo; tú la estás sosteniendo.
  2. Tiempos de carga de página o transacción exceden 3 segundos con data real. Y no puedes arreglarlo porque no puedes acceder al runtime.
  3. Tu cuenta mensual de plataforma se duplicó en los últimos 12 meses. Y el crecimiento proyectado mantiene esa trayectoria.
  4. Necesitas multi-tenancy verdadero. Diferentes clientes, diferente data, aislamiento duro.
  5. Una auditoría de compliance está en tu roadmap. SOC 2, HIPAA, ISO 27001.
  6. Dos o más ingenieros no pueden hacer cambios de forma segura. La plataforma permite solo flows de single-editor para alguna lógica, o los cambios se rompen invisiblemente.
  7. Tus inversionistas están preguntando sobre riesgo de plataforma. Series A en adelante, esto aparece en due diligence.
  8. El roadmap de la plataforma no coincide con el tuyo. Van a donde no necesitas que vayan.

Tres o más síes, pasaste el breakpoint. Cinco o más, estás pagando por dos sistemas y obteniendo uno.

Patrones de migración: cómo salir con gracia

La mayoría de escapes de low-code son dolorosos porque los equipos intentan migrar de una vez. El patrón que usamos en cambio es strangler fig: construye el nuevo sistema al lado del viejo, migra un workflow a la vez, y apaga la plataforma vieja solo cuando nada depende de ella.

Pasos concretos:

  1. Audita la plataforma. Documenta cada workflow, cada dependencia externa, cada regla de negocio. Time-boxea esto a 1-2 semanas.
  2. Toma primero el workflow de mayor dolor. Usualmente el que tiene problemas de performance o presión de compliance. Construye el reemplazo custom solo para ese workflow.
  3. Corre ambos en paralelo. Los nuevos requests pegan al nuevo sistema, la data vieja vive en el sistema viejo. Hace bridge con APIs de lectura.
  4. Migra data en batches. No intentes mover todo a la vez. Mueve lo que se usa activamente; archiva el resto.
  5. Repite workflow por workflow. Cada paso shippeable independientemente, cada paso muestra ROI inmediato.
  6. Corta la plataforma al final. Cuando ningún workflow dependa de ella, baja al free tier o cancela.

Timeline típico de migración para una app low-code mid-size: 12-20 semanas. Costo típico: $40K-$120K. Comparado con “quédate en la plataforma y paga $8K/mes para siempre”, la migración se paga en 12-18 meses.

Cuándo custom es correcto desde el día uno

También está el caso inverso: cuándo no deberías empezar en low-code para nada, ni siquiera para un MVP.

  • El producto es software. Si estás vendiendo un producto SaaS donde la UX es la diferenciación, construirlo en el framework de UX de alguien más limita tu diferenciación y te encadena.
  • Esperas levantar capital de riesgo. Los VCs marcan dependencia de plataforma low-code en due diligence. Series A en adelante, la pregunta se vuelve más afilada.
  • Multi-tenant desde el día uno. No empieces en una plataforma single-org y finjas que migrarás. No lo harás, hasta que duela.
  • Aplicaciones AI-native. La mayoría de productos IA necesitan prompt management custom, pipelines de eval, ruteo de modelos y controles de costo. Las plataformas low-code tienen soporte superficial para todo esto.
  • UX sensible a performance. Plataformas de trading, colaboración en tiempo real, cualquier cosa donde los usuarios estén mirando el loading spinner.

En estos casos el costo día uno de custom es más alto. El costo a 24 meses es dramáticamente más bajo porque te saltas la migración por completo.

Comparación honesta de pricing a 24 meses

Un ejemplo representativo. Un producto SaaS B2B, creciendo de 50 a 1,000 clientes en 24 meses:

Camino low-code:

  • Fees de plataforma año 1: ~$24K
  • Fees de plataforma año 2 (growth): ~$90K
  • Tiempo de developer especialista (1 senior, asignación parcial): ~$80K
  • Migración a custom en el mes 22 (forzada): ~$90K
  • Total: ~$284K, y al final empiezas custom.

Custom desde el día uno:

  • Build MVP: ~$60K
  • Retainer de mantenimiento año 1-2: ~$40K
  • Hosting y tooling: ~$10K
  • Total: ~$110K, y al final eres dueño de un codebase.

El camino custom es aproximadamente 60% más barato a 24 meses si el producto despega. Si no despega, el camino low-code era correcto, porque descubriste el no más rápido y barato. Por eso low-code es excelente para validar ideas y terrible para escalarlas.

La posición Softronic

Construimos custom para empresas donde el software es el producto. No intentamos sacar a cada cliente de low-code; para herramientas internas y prototipos, lo recomendaremos. Para productos SaaS que estás vendiendo, no. Código propio en frameworks estándar le gana a código de plataforma en runtime managed en cualquier timeframe que importe.

Hemos migrado 14 codebases fuera de plataformas low-code en los últimos 18 meses. El hilo común: cada uno desearía haber cambiado 12 meses antes.

¿Listo para abandonar la plataforma?

Auditamos tu setup low-code y te damos un plan de migración real con precio fijo. O te decimos que te quedes en la plataforma — eso también pasa.

Empieza en software a medida o lee sobre nuestros servicios completos.

PRÓXIMO MOVIMIENTO

Lanza lo siguiente. Hoy.

Agenda una llamada de 30 minutos. Te decimos en la propia llamada si podemos ayudarte — incluido un "no" honesto cuando no somos la opción.