¿No-code o software a medida? Dónde está la frontera de verdad

Cuando alguien nos escribe pidiendo una herramienta a medida, la primera pregunta que hacemos no es qué quiere construir. Es qué ha probado antes y por qué se le ha quedado corto.

La respuesta útil, más veces de las que nos conviene comercialmente, es que no necesita desarrollo. Un Airtable, un Notion o un Retool bien montados resuelven una barbaridad, cuestan una fracción y los mantiene alguien de tu equipo sin depender de nosotros. Decirlo nos cuesta un proyecto y nos ahorra uno malo, que es peor.

Pero la frontera existe. Este post va de dónde está.

Lo que un no-code hace mejor que nosotros

Empecemos por lo incómodo. Si tu caso cabe en una herramienta de catálogo, un desarrollo a medida es peor. No más caro: peor.

Un Airtable te da hoy formularios, permisos básicos, vistas por rol, automatizaciones, app móvil y una API. Nosotros tardamos semanas en igualar eso, y cuando lo igualamos tienes que mantenerlo tú. Ellos, además, siguen mejorándolo mientras duermes.

Y hay una ventaja suya que casi nadie pondera: el coste de cambiar de opinión. En una herramienta no-code, cambiar un campo o mover un paso del proceso lo hace la persona que conoce el proceso, en diez minutos y sin abrir un ticket. Eso vale muchísimo cuando aún no tienes claro cómo debería funcionar la cosa — que es la situación real de la mayoría de procesos internos antes de estabilizarse.

Si tu proceso todavía cambia cada mes, no tienes un problema de software. Tienes un problema de decidir, y encargar desarrollo a medida sobre algo indeciso es la forma más cara de descubrirlo.

Las cuatro cosas que rompen un no-code

Por nuestra experiencia, casi siempre es una de estas cuatro. No son "cuando crezcas": son fronteras concretas y se notan.

1. Lógica que depende del estado, no del formulario. Los no-code son excelentes en "si el campo A es X, haz Y". Se ahogan cuando la regla es "esto depende de qué pasó antes, de en qué orden, y de qué había hecho el usuario la semana pasada". Y esa distinción es más sutil de lo que parece: en LoverCast nos comimos un bug entero por acoplar dos ideas que se parecían —"no sé" y "está vacío"— en un mismo valor. Un modelo de datos que no distingue esos casos no lo arregla ninguna herramienta: lo hereda.

2. Permisos finos de verdad. "Los comerciales solo ven sus clientes" lo hace cualquiera. "Los comerciales ven sus clientes, más los de su región si están de guardia, menos los que estén en negociación con dirección" no lo hace ninguno sin retorcerse. Cuando los permisos dejan de ser una tabla y pasan a ser reglas, has cruzado.

3. Integraciones que tienen que ser fiables. Conectar dos herramientas para mover datos una vez al día es fácil. Que el pedido llegue a tu ERP siempre, que si falla se reintente, que no se duplique y que alguien se entere cuando algo se rompe — eso es ingeniería, y es justo donde los pegamentos visuales se convierten en un sistema que nadie sabe depurar.

4. Volumen y latencia. Suele llegar el último y de golpe. Mientras la tabla tiene diez mil filas todo va bien; con un millón, las vistas se arrastran y descubres que la herramienta no está pensada para eso.

La pregunta que lo resuelve antes de gastar

Si tuviéramos que quedarnos con una: ¿la parte que te hace distinto es la parte que te hace ganar dinero?

Si tu ventaja competitiva está en cómo compras, cómo produces o cómo atiendes —y el software solo lo apunta— compra la herramienta. Si tu ventaja es el proceso, y ese proceso es exactamente el que ninguna herramienta te deja modelar sin torturarla, ahí se justifica construir la herramienta a medida.

Un ejemplo nuestro, y va en contra de vendernos. Carmela Cartonera vende ediciones artesanales hechas a mano y regala las obras en PDF. Lo obvio habría sido montarle un ecommerce completo con su CMS y su base de datos. No hacía falta: el catálogo cabe en el repositorio, las tiradas son pequeñas y lo único de verdad dinámico es el pago, que resuelve Stripe. Publicar una obra nueva es un commit. No tiene panel de administración porque no lo necesita, y eso le ahorra una cuota mensual y un sistema que mantener.

Construimos poco a propósito. Ese es el mismo criterio que aplicamos cuando el que paga eres tú.

Cómo se sale de un no-code sin drama

Y una cosa más, porque es la que casi nadie mira al entrar: cómo saldrás.

Antes de montar tu operación encima de una herramienta, comprueba que puedes exportar los datos en un formato que se entienda, y hazlo una vez de verdad. No es paranoia: es lo que convierte una migración futura en un trabajo de semanas en lugar de un rescate.

Cuando nos llega un proyecto que viene de un no-code que se quedó corto, el trabajo real no suele ser construir lo nuevo. Es entender qué reglas había implícitas en las automatizaciones que nadie documentó, y a quién le rompe el día cada una de ellas.

Lo que nos llevamos

• Si tu proceso aún cambia cada mes, no encargues desarrollo: decide primero. El software no arregla una decisión pendiente, la congela.
• Las cuatro fronteras son lógica con estado, permisos finos, integraciones fiables y volumen. Si no has tocado ninguna, sigue con la herramienta.
• Construir a medida se justifica cuando la parte que te hace distinto es la que te hace ganar dinero. Si no lo es, comprar sale mejor — y te lo diremos.
• Mira la puerta de salida al entrar. Exporta tus datos una vez antes de necesitarlo.

Si estás en la frontera y no lo tienes claro, cuéntanoslo. Si tu caso cabe en una herramienta, te lo diremos en un correo y te habremos ahorrado el proyecto.