Cómo empezar a montar un SaaS que funciona por chat
Llevas años clicando menús y rellenando formularios. La idea detrás de un «SaaS por chat» es simple: ¿y si en vez de buscar el botón correcto, le dijeras a la app lo que quieres y ya está? Esto no es el producto terminado, es el punto de partida. Te cuento por dónde se empieza de verdad y qué vas a romper por el camino.
¿Qué es realmente un "SaaS por chat"?
Es una aplicación de siempre, con su base de datos y su lógica de negocio, pero donde la capa de entrada deja de ser menús y botones y pasa a ser una conversación. A esto se le suele llamar interfaz conversacional o «UI líquida»: la interfaz se adapta a lo que pides en lenguaje natural en lugar de obligarte a encontrar el camino.
Ejemplo concreto. Imagina una app para pedir comida, llamémosla ByteEats. En la versión clásica: abres la carta, filtras por categoría, añades al carrito, eliges dirección, pagas. En la versión por chat escribes «ponme lo de siempre pero sin cebolla y que llegue antes de las nueve» y la app lo entiende.
Lo importante: por debajo sigue habiendo lógica normal. Hay una base de datos con productos, un sistema que calcula precios, una pasarela de pago. El chat no sustituye nada de eso. Solo cambia cómo el usuario expresa lo que quiere. La inteligencia no está en «la magia del chat», está en cómo conectas ese chat con tus acciones reales.
¿Qué piezas mínimas necesitas?
Lista honesta. No necesitas un equipo de investigación en IA. Necesitas cuatro cosas:
- Un LLM vía API (Claude, GPT, el que sea) como capa de interpretación. Es quien lee lo que escribe el usuario y entiende la intención. No lo entrenas tú: lo llamas por API.
- Tu lógica de negocio de siempre. Base de datos, acciones, validaciones. Lo que ya sabes hacer. Esto no desaparece, es el motor.
- Una capa que traduzca la intención en acciones reales. Esto se llama function calling (o tool calling): en lugar de devolverte un texto suelto, el LLM te dice «el usuario quiere ejecutar
crear_pedidocon estos datos». Tú ejecutas esa función con tu código. En una frase: function calling convierte una frase en lenguaje natural en una llamada a una función concreta de tu app. - Una interfaz de chat sencilla. Un input, una lista de mensajes. Nada sofisticado para empezar.
Esto es agnóstico de stack: vale casi cualquiera. Para que te hagas una idea, con el que uso yo —Next.js + TypeScript + Supabase— te sobra para montar el mínimo viable. El LLM lo pones por API encima de eso.
¿Por dónde empiezo de verdad?
Por lo más pequeño que puedas imaginar. El error número uno es querer «la app entera por chat» el primer día. No. El mínimo viable es esto:
- Elige UN caso de uso ridículamente pequeño. No «una app de pedidos completa». Sino «pedir una sola cosa por chat». Una acción. Una.
- Conecta el LLM a esa única acción real con function calling. Defines una función, por ejemplo
crear_pedido(producto, cantidad), y le dices al LLM que existe. - Prueba que entiende la intención antes de añadir nada más. Escribe de diez formas distintas «quiero dos cafés» y comprueba que siempre acaba llamando bien a tu función.
- Itera. Solo cuando esa pieza funcione, añade la segunda acción.
Un pseudo-ejemplo corto para que veas la forma, no para copiar y pegar:
// Le describes al LLM qué funciones puede invocar
const tools = [{
name: "crear_pedido",
description: "Crea un pedido de comida",
// qué datos necesita extraer de la frase del usuario
parameters: { producto: "string", cantidad: "number" }
}]
// El LLM lee "ponme dos cafés" y responde:
// crear_pedido(producto: "café", cantidad: 2)
// y TÚ ejecutas esa función con tu código de siempre
Fíjate en lo importante: el LLM no crea el pedido. Solo dice qué función llamar y con qué datos. Quien lo crea de verdad es tu código, con tus validaciones. Esa separación es la clave de todo.
¿Qué errores vas a cometer?
Aquí está la parte honesta, la que separa esto del humo. Los vas a cometer, así que mejor saberlos antes.
El LLM alucina. A veces se inventa acciones que no existen o rellena datos que el usuario no dijo. Por eso la validación real la hace tu lógica de negocio, nunca el chat. Si el LLM dice «crea un pedido de 9.000 cafés», es tu código quien decide que eso no tiene sentido. Trata la salida del LLM como una propuesta, no como una orden.
Cuesta dinero. Cada llamada al LLM se paga. No es gratis, pero tampoco es la ruina: se controla eligiendo el modelo según la tarea, acortando el contexto que mandas y cacheando lo repetido. Y el argumento de fondo se sostiene: menos fricción para el usuario suele significar más conversión y menos soporte. El chat puede salir más barato que el coste de que la gente se pierda en tu interfaz.
No todo debería ser un chat. Esta es la más importante. A veces un botón es mejor que una conversación. «Pagar» es un botón. «Confirmar» es un botón. La dirección es conversacional para casi todo, no para todo. Si obligas al usuario a escribir un párrafo para hacer algo que era un clic, has empeorado la app. Usa el chat donde aporta, no como dogma.
En resumen
Un SaaS por chat no es magia: es tu lógica de negocio de siempre con una capa conversacional encima, pegada con function calling. Empieza por una sola acción, valida siempre en tu código y no conviertas en chat lo que funcionaba mejor como botón.
Si quieres montar algo así para tu negocio —una web a medida o una automatización con IA por encima—, puedes calcular tu presupuesto orientativo o escribirme directamente. Sin plantillas y sin humo.
La versión completa, con el paso a paso y el código, está en camino. Cuando esté lista la enlazo aquí.
Artículos relacionados: