Software a medida o no-code: señales de que Make, n8n o Airtable se os han quedado cortos

El software a medida es software construido alrededor de tu operación (un backoffice, un panel comercial, un portal de alumnos, una API) en lugar de adaptar la operación a una herramienta genérica. Compensa frente al no-code cuando la lógica de negocio, el volumen o los permisos ya no caben en escenarios y bases compartidas.

Pasar de no-code a software a medida significa mover los datos críticos y la lógica de negocio desde escenarios de Make, n8n, Zapier o bases de Airtable a una base de datos y un código propios, manteniendo en no-code solo lo que sigue funcionando bien. Casi nunca es tirarlo todo: es decidir qué pieza ya no aguanta y sustituirla.

Lo digo porque es una conversación que se repite. El stack no-code hizo exactamente lo que tenía que hacer: permitió lanzar rápido, validar un funnel y conectar herramientas sin esperar a un equipo de desarrollo. El problema aparece después, cuando el negocio ya vende, el volumen crece y ese conjunto de escenarios pasa a ser la operación entera sin que nadie lo haya diseñado como tal.

¿Por qué un stack no-code que funcionaba empieza a fallar?

Porque se construyó para resolver problemas sueltos y ahora sostiene un sistema. Cada escenario tiene sentido por separado: uno mete los registros del formulario en Airtable, otro avisa al comercial por WhatsApp, otro actualiza el CRM, otro genera el acceso al curso. Con cinco escenarios, cualquiera los entiende. Con cuarenta, la lógica del negocio está repartida entre herramientas, cuentas y personas distintas.

Lo que falla no suele ser la herramienta. Make, n8n y Airtable son buenas herramientas. Falla que se les pide un papel para el que no se eligieron: ser la base de datos principal, el motor de reglas de negocio y el panel de control a la vez.

¿Qué señales indican que el no-code se os ha quedado corto?

Estas son las que miro primero cuando reviso un stack. Una sola no justifica reescribir nada. Tres o cuatro juntas, sí justifican sentarse a diseñar.

Señales en los datos

• Airtable hace de base de datos principal y empieza a ir lenta con las vistas grandes, las fórmulas encadenadas o los registros vinculados.
• El mismo dato vive en tres sitios (Airtable, CRM y una hoja) y ninguno coincide del todo.
• No hay forma fácil de saber qué pasó con un registro concreto: quién lo tocó, qué escenario lo modificó y cuándo.
• Los permisos son todo o nada: o alguien ve la base entera o no ve nada, y eso no encaja con setters, comerciales, soporte y dirección mirando lo mismo.

Señales en la lógica

• Las reglas de negocio están dentro de los escenarios: cómo se asigna un lead, qué cuenta como alumno activo, cuándo se revoca un acceso. Cambiar una regla obliga a tocar varios flujos.
• Hay escenarios que dependen del orden en que se ejecutan otros, y nadie lo tiene documentado.
• Los reintentos duplican cosas: un fallo a mitad de flujo y el reintento crea dos contactos o manda dos mensajes.
• Los errores se descubren tarde, cuando alguien del equipo nota que falta algo. De esto hablo más en automatizaciones que fallan en silencio.

Señales en el coste y la operación

• La factura crece con cada ejecución y buena parte de esas ejecuciones son sondeos, filtros o pasos que no aportan nada.
• Estáis rozando límites de operaciones, de registros o de tiempo de ejecución de vuestro plan, y la respuesta siempre es subir de plan.
• Una sola persona entiende el conjunto. Si esa persona se va de vacaciones, nadie toca nada.
• Las herramientas marcan lo que se puede hacer: “eso no se puede porque Make no lo permite” es una frase que aparece en reuniones de negocio.

¿Qué conviene mantener en no-code y qué pasar a código?

La herramienta se elige según el sistema, no al revés. Esta tabla resume el criterio que aplico en FCG Systems. No es una regla fija, pero sirve para ordenar la conversación.

La idea de fondo: el no-code es muy bueno orquestando y conectando. Es peor como almacén de datos críticos y como sitio donde vive la lógica que define cómo funciona tu negocio.

¿Cómo es una arquitectura híbrida que funciona?

La que más veces acaba teniendo sentido en negocios digitales (academias, infoproductores, comunidades, equipos comerciales) tiene cuatro capas:

1. Postgres como fuente de verdad. Contactos, compras, matrículas, asignaciones y accesos viven en una base de datos relacional con claves únicas, restricciones y un historial de cambios. Cada tipo de dato crítico tiene un sistema principal, y es este.
2. Una API o capa de lógica propia. Las reglas de negocio (a quién se asigna un lead, cuándo alguien tiene acceso, cómo se deduplica un registro) se escriben una vez, en TypeScript o Python, con tests. Herramientas como Xano pueden cubrir esta capa cuando el caso lo permite.
3. Un backoffice a medida. El panel donde setters, comerciales, soporte y dirección trabajan, cada uno con sus permisos. Es la parte que el equipo ve y la que más tiempo manual quita.
4. Automatizaciones que orquestan. n8n o Make siguen haciendo lo que hacen bien: escuchar webhooks, mover datos entre SaaS, lanzar avisos. La diferencia es que ya no deciden nada importante: llaman a la API y la API decide. Si la duda es cuál de las dos usar, está en n8n vs Make; si n8n va en tu propio servidor, en n8n self-hosted en producción.

Con este reparto, cambiar una regla es tocar un sitio. Un escenario que falla se puede reintentar sin duplicar nada, porque la API comprueba si el registro ya existe. Y si mañana cambiáis de herramienta de email o de CRM, la fuente de verdad no se mueve.

Esto encaja con cómo pienso los sistemas para negocios digitales en general: automatización, software, IA e infraestructura como capas de un mismo sistema, no como compras sueltas.

¿Cómo se migra sin parar la operación?

Por piezas. Una migración “big bang”, donde se apaga lo viejo un lunes y se enciende lo nuevo, es la forma más rápida de romper un negocio que factura. El orden que sigo:

1. Mapear antes de tocar

Inventario de escenarios, bases, hojas y cuentas: qué hace cada uno, qué datos lee y escribe, quién depende de él. Suele aparecer lógica duplicada y escenarios que ya nadie usa. Si el stack es grande, esto es literalmente un Systems Audit de 5 a 10 días laborables.

2. Elegir la pieza que más duele

No la más fácil ni la más bonita: la que más cuesta hoy en horas manuales, errores o ventas perdidas. Suele ser la gestión de leads y asignación comercial, o los accesos a la formación.

3. Crear la fuente de verdad y sincronizar

Se monta la base de datos y la API para esa pieza, y durante un tiempo conviven los dos mundos: los escenarios existentes escriben también en el sistema nuevo. Así se compara con datos reales si el resultado coincide.

4. Cambiar el origen, no todo a la vez

Cuando los datos coinciden, los escenarios pasan a leer del sistema nuevo. Después se retira la base antigua de esa pieza. El resto del stack sigue igual.

5. Repetir con la siguiente pieza

Cada pieza migrada deja documentación, logs y un responsable claro. Un proceso crítico sin logs no está terminado.

Un proceso crítico bien acotado suele encajar en un Business System Build de software a medida de 3 a 8 semanas. Si lo que duele es un único cuello de botella, a veces basta un Automation Sprint de 1 a 3 semanas que rehaga ese flujo con idempotencia y logs, sin construir software todavía.

¿Construir software propio o contratar otro SaaS?

Es la pregunta correcta y no siempre gana construir. Mi criterio:

• Contrata un SaaS si el proceso no es el centro de tu negocio y una herramienta existente lo resuelve casi entero. Nadie necesita un sistema de facturación propio porque sí. El caso de libro es el CRM, con el criterio de coste desglosado en CRM para pymes: de catálogo o a medida.
• Construye si el proceso es tu forma de operar (cómo captas, asignas, vendes y das acceso), si el SaaS te obliga a vivir de parches o si las licencias crecen más rápido que el valor que aportan.
• Combina en la mayoría de casos: SaaS para lo estándar, software propio para lo que te diferencia, automatizaciones para unirlo.

Hay una trampa frecuente: sustituir un stack no-code desordenado por otro SaaS “todo en uno” sin haber diseñado el proceso. El desorden se muda de herramienta. Antes de comprar o construir, conviene saber qué sistema queréis tener. Y si lo que tenéis encima de la mesa no es un stack no-code sino una demo generada con IA, el salto tiene sus propias trampas: las repaso en de prototipo a producción.

¿Y quién es dueño de lo que se construye?

Pregunta obligatoria antes de empezar. En FCG Systems el repositorio, la base de datos y las credenciales quedan a nombre de la empresa del cliente, y la arquitectura se documenta para que cualquier equipo técnico pueda continuar. Si el software lo mantiene luego tu equipo o lo mantenemos nosotros como partner tecnológico, es una decisión que se toma con el plan de mantenimiento, no una dependencia oculta.

Un escenario para aterrizarlo

Imagina una academia online que capta con formularios de Tally, guarda todo en Airtable, asigna leads a cuatro setters con un escenario de Make, agenda llamadas con Calendly y da acceso a la plataforma formativa con otro escenario.

Durante un lanzamiento, Airtable empieza a ir lenta, dos setters llaman al mismo lead porque el escenario de asignación se ejecutó dos veces tras un error, y un alumno que pagó no recibe acceso porque un paso falló sin avisar. Nadie sabe cuántos casos más hay.

La migración por piezas sería:

1. Postgres para contactos, compras y accesos, con una clave única por persona.
2. Una API que asigna leads por reglas y capacidad, y que no asigna dos veces el mismo registro.
3. Un backoffice donde cada setter ve solo sus leads y dirección ve el conjunto.
4. Tally, Calendly y la plataforma formativa siguen donde están; Make escucha sus webhooks y llama a la API.
5. Logs y alertas en los flujos de pago y acceso (cómo dar y quitar accesos según el estado del pago está en pagos fallidos en Stripe y control de accesos).

Tally no se cambia. Calendly tampoco. Lo que cambia es dónde vive la verdad y quién decide.

Checklist para decidir si dar el salto

• Tenemos un inventario de escenarios, bases y hojas con lo que hace cada uno.
• Sabemos qué sistema es la fuente de verdad de contactos, ventas y accesos.
• Hemos contado cuántos escenarios contienen reglas de negocio repetidas.
• Hay logs y alertas en los flujos que tocan dinero o accesos.
• Los reintentos no duplican registros ni mensajes.
• Más de una persona entiende cómo funciona el conjunto.
• Sabemos cuánto crece la factura de herramientas por volumen.
• Hemos identificado la pieza que más cuesta hoy (horas, errores o ventas).
• Hemos valorado si un SaaS existente resuelve esa pieza antes de construir.
• Está claro a nombre de quién quedan código, base de datos y credenciales.

Si marcáis pocas casillas, el primer paso no es escribir código: es diseñar el sistema.

¿Por dónde empezar con vuestro stack?

No hace falta decidir hoy entre no-code y software a medida. Hace falta saber qué pieza está frenando la operación y qué pasaría si mañana duplicaseis el volumen. A partir de ahí la herramienta sale sola.

Si tu stack ya se parece a los cuarenta escenarios de los que hablaba al principio, cuéntame qué proceso os está frenando y lo miramos juntos. Y si estáis valorando meter IA en alguno de esos flujos, antes echa un vistazo a dónde la IA aplicada ahorra trabajo de verdad.