Todo el mundo vende software con IA. La demo resume un PDF, completa un campo o responde con tono de marca. En la reunión parece el producto. A los seis meses el modelo sigue ahí y el producto no: datos sucios, flujos a medias, una base que no aguanta el segundo equipo de usuarios.
El software con IA que escala no nace del modelo. Nace de un producto con datos, permisos y un recorrido que ya funciona sin la capa. La IA es una capa real y hay que hacerla bien. Encima de esa base. No al revés. El que empieza por el prompt está construyendo un espectáculo, no un sistema.
En Truman no vendemos IA. Construimos la base: desarrollo web a medida, producto y sistemas que aguantan. Este artículo es el orden que pedimos cuando alguien llega con «queremos meterle IA» y todavía no tiene el software que esa capa necesita.
Qué es software con IA que escala (y qué es una demo)
Software con IA que escala es un producto que ya opera —usuarios, datos, permisos, un flujo que se puede medir— y encima lleva una capa que acelera una tarea concreta: clasificar, sugerir, extraer, redactar un borrador. La capa tiene dueño, evaluación y un sitio donde fallar sin tumbar el proceso. Eso no es un chatbot pegado a la home.
Una demo es otra cosa. Un modelo que resume el último PDF del comercial en un entorno controlado. Útil para explorar. Insuficiente para producción. Escalar es que el segundo equipo, el segundo cliente o el segundo almacén usen lo mismo sin que alguien «le dé un toque al prompt». Si eso no está, no tienes software con IA. Tienes una capa sin suelo.
No vamos contra la IA. Hay que hacerla bien. El problema no es usarla: es usarla sin base. Hoy el mercado pide software con IA, apps con IA, automatizaciones con IA. Truman no discute esa demanda. Construye lo de debajo para que esa capa no se caiga. El orden —qué tiene que estar listo antes— lo detallamos en qué tiene que estar listo en tu software antes de meter IA.
El orden: producto, datos, flujos, luego la capa
Primero el producto que aguanta. Luego la capa. Invertir el orden es el atajo de 2023 que en 2026 sigue saliendo caro: se ficha un modelo, se busca un caso, se descubre que el CRM no tiene campos, que el rol de «solo lectura» no existe y que nadie sabe qué es un ticket cerrado.
30%
de los proyectos de IA generativa serán abandonados tras el proof of concept a finales de 2025, según Gartner: datos, riesgo y costes, no «falta de modelo».
Gartner, comunicado de prensa, 2024
Esa cifra no dice que la IA no sirva. Dice que el POC sin suelo no escala. El modelo no es el cuello de botella. Lo es el producto que no estaba listo para recibir una capa. Si tu proceso aún no está escrito, no tienes un problema de IA: tienes un problema de software. La capa irá después.
Qué tiene que aguantar la base
La base es aburrida y es lo que escala. Identidad y roles. Un modelo de datos con transiciones. APIs que no se improvisan en cada pantalla. Logs de lo que se pidió y lo que se devolvió. Un sitio donde el humano corrige sin rehacer el flujo. Sin eso, la capa no tiene dónde engancharse.
| Pieza | Demo con IA | Producto que aguanta la capa |
|---|---|---|
| Usuarios y roles | Una cuenta de prueba | Permisos en servidor |
| Datos | PDF o Excel de la demo | Fuente de verdad + histórico |
| Flujo | Un happy path ensayado | Estados, excepciones, fallback |
| Evaluación | «Queda bien» | Métrica de la tarea, no del modelo |
| CMS o panel | Nadie edita sin desarrollador | El equipo opera el producto |
WordPress con un plugin de chat no es esa base. A veces WordPress es la web correcta. Casi nunca es el sistema donde vas a colgar una capa que toca pedidos, stock o historiales clínicos. La distinción honesta está en WordPress frente a desarrollo a medida. Elige el suelo por el producto, no por el eslogan del modelo.
Si apagas la capa de IA mañana, ¿el producto sigue siendo usable y el proceso sigue cerrado? Si la respuesta es no, no tenías producto. Tenías una demo.
Klapper y Weddle: el producto primero, la capa después
Klapper es nuestra plataforma de entradas: marca, web, app, inventario, pagos, validación de QR. Eso es producto. Una capa de IA podría, el día que toque, ayudar a un organizador a redactar la ficha del evento o a clasificar incidencias de puerta. No puede inventar el stock. No puede decidir si un abono se ha usado. Si el inventario no es sólido, la capa más brillante escala el error.
Weddle es otra bestia: grupos privados alrededor de una boda, invitaciones, roles, un dato que caduca. Ahí el producto es el grupo correcto a tiempo, no un feed eterno. Una capa podría sugerir un hielo-breaking o un resumen del chat. No sustituye el modelo de invitación ni el permiso de quién ve a quién. Pintar «la app con IA» antes de cerrar grupos y caducidad es diseñar una mentira amable.
Hacer la capa bien: límites honestos, no cruzada anti-IA
Hacerla bien no es «poner GPT en el formulario». Es acotar la tarea, el contexto que puede ver el modelo, lo que nunca puede decidir solo (dinero, acceso, diagnóstico, expulsión) y cómo se evalúa. Los límites de la generativa en web —dónde acelera y dónde inventa— los cubrimos en IA generativa en desarrollo web: límites. Aquí el criterio es de producto: la capa no sustituye el sistema.
Los límites no son una cruzada. Son oficio. Una capa bien hecha sobre un sistema sólido es el escenario correcto. Una capa que tapa un proceso indefinido solo acelera el caos. Truman se queda en lo primero que toca: el sistema. La capa, cuando hay algo debajo.
No vamos contra la IA. Vamos contra el orden invertido. Si el producto no aguanta, el modelo no lo va a sostener. Primero el software. La capa, después, y bien hecha.
Qué hacemos en Truman (y qué no)
En Truman diseñamos y construimos la base: web, producto, app, sistemas con datos y flujos. Eso es la oferta. La IA no es un servicio que contrates en el estudio. No te vamos a vender un pack de «software con IA» para tapar un Excel. Si la capa tiene sentido, el producto ya tiene que existir —o hay que construirlo primero.
El kickoff útil no empieza por el proveedor del modelo. Empieza por el flujo núcleo, los roles y la fuente de verdad. Luego se mira si hay una tarea que una capa pueda acelerar sin tumbar el proceso. Si no la hay, el trabajo sigue siendo de producto. Eso no es quedarse atrás. Es no construir encima del vacío.
Tip técnico: la capa entra por un puerto, no por el núcleo
Si la IA toca el dominio, aísla el puerto: un servicio que recibe un contexto acotado y devuelve una sugerencia con esquema fijo. El núcleo (pedido, entrada, grupo, factura) no importa el JSON crudo del modelo. Versiona el contrato. Guarda el input y el output. Así puedes cambiar de modelo —o apagarlo— sin reescribir el producto. El acoplamiento al vendor es el atajo que más caros sale a los 18 meses.
Antes de meterle IA a un software
- ¿El flujo núcleo se completa hoy sin la capa?
- ¿Hay una fuente de verdad, no tres Excels y un Drive?
- ¿Los roles y permisos existen en servidor, no en el prompt?
- ¿Puedes nombrar una sola tarea que la capa va a acelerar?
- ¿Esa tarea tiene métrica y un humano de fallback?
- ¿Si apagas el modelo, el producto sigue en pie?
- ¿Vas a registrar contexto, respuesta y corrección?
- ¿El núcleo del dominio está desacoplado del vendor?
Preguntas frecuentes sobre software con IA que escala
¿Qué hace falta para que el software con IA escale de verdad?
Un producto que ya opera, datos con permiso e histórico, flujos escritos y una capa acotada a una tarea. Sin eso escalas la demo, no el sistema. El modelo es la parte que más se ve y la que menos sostiene el crecimiento.
¿La IA es un servicio que se contrata en Truman?
Truman construye la base: software, web y producto. La IA es una capa que tiene que ir encima, bien hecha, cuando esa base existe. No es un servicio que contratas aquí. Si llegas pidiendo la capa y no hay suelo, el trabajo empieza por el suelo.
¿Se puede empezar por un POC de IA y construir el producto después?
Puedes explorar. No confundas exploración con arquitectura. El POC no define el modelo de datos ni los roles. Si el calendario asume que el POC «ya es el producto», estás invirtiendo el orden.
¿WordPress vale como base para una capa de IA?
Para una web de contenidos o un asistente acotado, a veces. Para un producto con pedidos, inventario o roles complejos, casi nunca. La pregunta no es el CMS: es si tienes sistema. El CMS es una pieza. No es la base.
