¿No-code o desarrollo a medida? Cuál conviene

En resumen: una plataforma no-code como Bubble, AppSheet o Glide es más barata y rápida para arrancar, pero se paga todos los meses por usuario o por uso, la app vive en la plataforma y, en el caso de Bubble, el código no se puede exportar. El desarrollo a medida cuesta más al principio, pero el código es tuyo y el costo mensual es el de la infraestructura. Conviene no-code para validar una idea con pocos usuarios; conviene a medida cuando la app es central para la operación, crece en usuarios o necesita integraciones que la plataforma no resuelve.

¿Qué es no-code y qué es desarrollo a medida?

Una plataforma no-code te deja armar una aplicación sin escribir código: arrastrás componentes, conectás una planilla o una base de datos y definís reglas desde una interfaz. La plataforma aloja la app, la mantiene y te cobra una suscripción.

El desarrollo a medida es escribir la aplicación con código propio, sobre herramientas estándar como Next.js y Postgres, desplegada en infraestructura que podés elegir. Alguien tiene que escribirla, pero el resultado es tuyo.

No es una pelea entre bueno y malo. Son dos formas de pagar por software, con costos que se reparten distinto en el tiempo.

¿Cuánto cuesta cada uno, con los años?

No-code: poco al principio, todos los meses después

Las plataformas no-code cobran de dos formas: por usuario o por uso.

• Por usuario. AppSheet, de Google, publica planes de USD 5, USD 10 y USD 20 por usuario por mes. Con 50 usuarios en el plan de USD 10, son USD 500 por mes, USD 6.000 por año y USD 30.000 en cinco años, a precio de lista de octubre de 2026 y sin contar subas.
• Por uso. Bubble cobra por plan con un cupo de "workload units", una medida de cuánto trabaja el servidor. En octubre de 2026, con facturación anual, el plan Starter cuesta USD 59 por mes con 175.000 unidades, el Growth USD 209 con 250.000 y el Team USD 549 con 500.000. Lo que pasa del cupo se paga aparte.
• Por equipo. Glide combina planes mensuales con un número de miembros incluidos y créditos de uso.

La característica común es que el costo crece con el éxito: más usuarios o más uso, más cuenta. Y la cuenta no termina nunca.

A medida: más al principio, infraestructura después

El desarrollo a medida concentra el costo al principio, en la construcción. Después, el costo fijo mensual es el de la infraestructura, que en apps chicas y medianas arranca en decenas de dólares: por ejemplo, el plan Pro de Supabase cuesta desde USD 25 por mes e incluye hasta 100.000 usuarios activos mensuales. Sumar usuarios internos a una app propia no cuesta una licencia por cabeza.

A eso se le suma el mantenimiento y las mejoras, que existen en las dos opciones. Cuánto cuesta mantener una app a lo largo de los años lo detalla año por año.

La comparación que importa

Para comparar en serio, sumá cinco años de cada opción:

1. No-code: suscripción mensual × 60 meses, ajustada por el crecimiento de usuarios o de uso que esperás, más el tiempo de quien la arma y la mantiene.
2. A medida: desarrollo, más infraestructura × 60 meses, más mantenimiento y mejoras.

Con pocos usuarios y un proceso simple, no-code suele ganar. Con muchos usuarios, o con una app que es el centro de la operación, la curva se da vuelta.

¿Qué es el lock-in y por qué importa?

Lock-in es quedar atado a un proveedor porque irse cuesta demasiado. En no-code es estructural: la app está hecha con las piezas de la plataforma y sólo corre ahí.

El caso más claro es Bubble. Su manual explica que las apps sólo corren en su plataforma y que salir implica reconstruir la lógica de la aplicación; lo que se puede exportar son los datos. Eso significa que si la plataforma sube los precios, cambia las condiciones o deja de tener una función que usás, tus opciones son aceptar o rehacer.

En un desarrollo a medida, el lock-in depende del contrato, no de la tecnología. Si el repositorio, la infraestructura y la documentación están a tu nombre, podés cambiar de proveedor sin rehacer nada. Es lo que hay que exigir por escrito.

¿Qué pasa con los datos y la seguridad en cada opción?

En una plataforma no-code, los datos viven en la infraestructura de la plataforma, con sus reglas de seguridad, su región y sus términos. Para muchas herramientas internas eso alcanza. Pero vale la pena leer tres cosas antes de cargar datos de clientes: dónde se alojan, quién puede acceder y cómo se exportan si te vas.

Los permisos son el otro punto. Las plataformas resuelven bien los casos comunes, como un administrador y usuarios que ven todo. Cuando cada cliente tiene que ver sólo lo suyo, o una sucursal no puede ver los números de otra, las reglas se complican, y en algunas plataformas terminan dependiendo de filtros en la interfaz más que de restricciones en la base de datos.

En un desarrollo a medida, esas reglas se diseñan desde el primer día y pueden vivir en la base de datos misma. En el CRM de Digital View, cada inmobiliaria ve sólo sus campañas y sus leads, y el aislamiento es una regla de la base, no una convención de la pantalla.

¿Cuándo conviene no-code?

• Para validar una idea. Querés saber si tu equipo va a usar una herramienta antes de invertir en construirla.
• Para herramientas internas chicas, con pocos usuarios y procesos que entran en lo que la plataforma ofrece.
• Cuando no hay integraciones complejas, o las que hay ya vienen resueltas por la plataforma.
• Cuando aceptás que, si funciona, quizás haya que rehacerla.

¿Cuándo conviene desarrollo a medida?

• La app es central para la operación. Si deja de funcionar, se para el negocio.
• Los usuarios crecen. Clientes, sucursales o empleados que entran a la app hacen que el costo por usuario pese.
• Hay usuarios externos con permisos distintos. Cada cliente ve sólo lo suyo, cada sucursal sólo lo suyo.
• Las integraciones son el valor. Mercado Pago, WhatsApp, tu ERP, tu facturador, con reglas propias.
• Ya estás peleando con la plataforma. Si cada función nueva es un parche, la plataforma dejó de ayudarte.

La app de pedidos de KUKUI es un ejemplo: tres roles (empleado, empresa y marca), pago individual por Mercado Pago, pedido recurrente, bonificación por escalones y un consolidado mensual que se arma solo. Cada empleado de cada empresa cliente es un usuario más, y en una app propia sumar usuarios no suma licencias.

¿Y si ya tengo una app no-code?

No es un error: probablemente te sirvió para aprender qué necesitás. Si estás pensando en pasar a medida:

1. Los datos se migran. Exportá lo que tengas y verificá que esté completo.
2. La app no-code es el mejor documento de requisitos. Muestra qué se usa de verdad y qué no.
3. No hace falta migrar todo junto. Se puede empezar por el flujo que más duele y convivir un tiempo con lo demás.

La misma lógica sirve para software enlatado: CRM a medida o CRM enlatado compara las dos opciones para el caso del CRM.

Cómo lo vemos en V3XRA

Si no-code te alcanza, te lo decimos en el diagnóstico: no tiene sentido construir lo que una plataforma resuelve bien. Si no te alcanza, construimos con código propio, con un prototipo navegable en días, una entrega usable cada dos semanas y el repositorio, la infraestructura y la documentación a nombre de tu empresa.

El diagnóstico no se cobra y salís con el alcance escrito y el número, para comparar contra lo que pagás hoy. El detalle está en desarrollo de apps a medida.