Cuándo NO deberías montar tu app sin código: cuatro situaciones

Monto cosas sin código constantemente y aun así hay cuatro situaciones donde recomendaría no hacerlo. En esas cuatro, el no-code te va a salir más caro que hacerlo bien desde el principio.

No por el precio de la suscripción. Por lo que cuesta salir de ahí cuando ya tienes gente dentro.

¿Cuándo se queda corto el no-code?

Cuando alguna de estas cuatro cosas es verdad en tu proyecto. Si ninguna lo es, tira de no-code sin complejos y no le des más vueltas.

Uno: cuando la lógica rara es el producto

Las plataformas visuales están hechas para patrones comunes. Listar cosas, filtrarlas, crear, editar, borrar, mandar un correo cuando pasa algo. Todo eso lo tienen resuelto y lo tienen resuelto bien.

El problema aparece cuando lo que hace especial a tu producto es precisamente una regla que no es común. Un cálculo de precios con quince condiciones. Un sistema de asignación que depende de disponibilidad, prioridad y una lista de excepciones. Una lógica de facturación con prorrateos.

Ahí pasa una cosa curiosa: la parte fácil (las pantallas) la montas en dos días, y la parte difícil (tu regla) te lleva tres semanas de pelearte con la herramienta para que haga algo que en código son cuarenta líneas.

Y encima queda ilegible. Cuando vuelvas dentro de dos meses a cambiar una condición, vas a encontrarte tu propia lógica repartida en ocho sitios distintos porque la herramienta no te dejó ponerla en uno.

La señal para detectarlo: si al describir tu producto la frase más importante empieza por "depende de", cuidado.

Dos: cuando el precio escala en tu contra

Este es el que más gente pilla por sorpresa.

Muchas plataformas cobran por usuario, por registro o por acción. Es un modelo perfectamente razonable y para muchos casos sale barato. Lo que tienes que mirar es la dirección en la que crece tu proyecto.

Si tu app es interna, para tres personas, el precio se queda quieto para siempre. Perfecto.

Si tu app es para tus clientes y el plan cobra por usuario final, entonces tu coste crece exactamente igual que tus ingresos. Y como tu margen es la diferencia, cada cliente nuevo te aporta menos de lo que parece. He visto proyectos donde la herramienta se comía un pedazo del ingreso que quitaba las ganas de crecer.

Haz el cálculo antes, no después. Con cien usuarios, ¿cuánto pagas? ¿Y con mil? Si el número te asusta, esa herramienta no es para este proyecto. Escribí sobre esto con números en el no-code no es gratis, porque hay más costes escondidos de los que parece.

Tres: cuando los datos son sensibles de verdad

Datos de salud, datos de menores, datos financieros, cualquier cosa que si se filtra te mete en un problema serio.

No es que las plataformas sean inseguras, que suelen tener mejor seguridad que la que montarías tú. Es otra cosa: cuando tus datos viven dentro de una herramienta de terceros, hay preguntas que no puedes responder del todo. Dónde están alojados exactamente. Quién de esa empresa puede verlos. Qué pasa si la compran. Qué te llevas si te vas.

Para un listado de clientes normal, esas preguntas no te quitan el sueño. Para datos que legalmente tienes que proteger, sí deberían.

Ahí prefiero Supabase o algo equivalente donde la base de datos es mía, la puedo exportar entera cuando quiera y sé exactamente dónde está. Sigue siendo cómodo, sigue sin ser programar desde cero, y me quita ese tipo de dudas. La comparación entre las dos filosofías la desarrollo en Supabase frente a Airtable como backend.

Cuatro: cuando alguien va a construir sobre esto durante años

Si lo que montas es el cimiento de algo que va a crecer y que otras personas van a mantener, el no-code te va a doler.

El motivo es simple: no se puede versionar bien. En un proyecto de código normal ves quién cambió qué y cuándo, puedes volver atrás, puedes tener una copia de pruebas separada de la de producción. En la mayoría de plataformas visuales, eso o no existe o existe a medias.

Trabajando solo, aguantas. Tú te acuerdas más o menos de lo que tocaste. Con tres personas metiendo mano a la vez, es un caos que se paga en horas de "¿quién ha cambiado esto?".

Y hay un factor añadido: los asistentes de IA trabajan muchísimo mejor sobre archivos que sobre lienzos propietarios. Si tu proyecto es código en una carpeta, le puedes pedir a un modelo que te lo explique, que lo documente, que encuentre el fallo. Si tu proyecto son cajas dentro de un editor, estás tú solo. Esa diferencia se agranda cada mes que pasa.

Y ahora la otra cara: cuándo sí, y sin dudarlo

Porque me da rabia que este post se lea como "el no-code es de segunda", que no lo es.

Herramientas internas para poca gente. Paneles sobre datos que ya tienes. Formularios que alimentan un proceso. Un portal de clientes para consultar cosas. Un directorio. Una primera versión para validar si a alguien le interesa lo que quieres vender.

Todo eso en Softr (enlace de afiliado: así me ayudas a seguir creando contenido) o similares lo tienes funcionando en una tarde, y montarlo de otra forma sería tirar el tiempo a la basura. La velocidad de salir a producción vale muchísimo, sobre todo cuando lo que buscas es descubrir si la idea vale algo.

De precio se mueve en el rango de varias decenas de euros al mes según usuarios y aplicaciones. Confirma en la web oficial antes de decidir.

El resumen del criterio: no-code para descubrir, código para escalar. Y ojo, que la mayoría de proyectos se mueren en la fase de descubrir, así que empezar por lo rápido es casi siempre lo correcto.

Si quieres el panorama entero de opciones, lo tengo aquí: crear apps sin programar.

¿En qué me estaría equivocando?

En dos cosas, y son importantes.

La primera: la mayoría de la gente que se preocupa por estos cuatro puntos no debería preocuparse todavía. Están optimizando para un problema de escala que nunca van a tener porque el proyecto no va a llegar ahí. Y mientras tanto no sacan nada, que es el único fracaso que importa de verdad. Si estás dudando entre montarlo rápido en una plataforma o hacerlo bien, monta rápido. La migración es un problema bonito de tener porque significa que funcionó.

La segunda: la frontera se mueve. Cada año estas herramientas se comen un trozo más del terreno que antes era exclusivo del código. Cosas que hace poco eran imposibles sin programar hoy son un bloque en un menú. Lo que hoy es una limitación real puede ser un botón el año que viene, así que no des mi lista por eterna.

Lo que no se mueve es el punto tres. Que tus datos vivan en casa de otro tiene un coste que no depende de lo buena que sea la herramienta. Ese sigue igual. Si no sabes si tu proyecto encaja en no-code o se te va a quedar corto, hice un test corto que te lo dice en un par de minutos.

Hacer el test de IA