Cómo funciona un SaaS:explicación sencilla para fundadores

Cómo funciona un SaaS: todo producto SaaS (Gmail, Slack, Notion, el tuyo) se compone de cuatro partes: un frontend que ven los usuarios, un backend que piensa, una base de datos que lo recuerda todo y una API que lleva mensajes entre ellos. Si puedes imaginar un restaurante, puedes entender cómo funciona un SaaS. Y cuando lo entiendas, podrás dirigir a la IA para que construya el tuyo.

Ya no necesitas escribir código para construir un producto de software. Pero sí necesitas un modelo mental de lo que construyes; si no, estás haciendo prompts a oscuras. Este es ese modelo, sin jerga.

Cómo funciona un SaaS: la analogía del restaurante

Imagina que diriges un restaurante. Cada parte de un producto SaaS se corresponde con algo que ya entiendes:

El comedor son las mesas, la iluminación, el diseño de la carta: el ambiente por el que te juzgan los clientes. La cocina son chefs que siguen recetas y gestionan varios pedidos a la vez. El recetario y la despensa guardan el conocimiento: recetas, existencias de ingredientes, preferencias de clientes, historial de pedidos. Y los camareros llevan los pedidos a la cocina y traen la comida a la mesa.

Esa es toda la arquitectura. Todo lo demás es detalle.

Qué pasa cuando alguien pulsa "Registrarse"

Sigamos un recorrido real por el restaurante, del clic al resultado:

1. Acción del usuario (comedor). Un visitante rellena tu formulario de registro y pulsa "Crear cuenta". El frontend comprueba lo básico: ¿el email tiene buen formato, la contraseña es lo bastante larga? Como un cliente que le dice al camarero que quiere el salmón.
2. Petición a la API (camarero). El frontend envía la petición (email, contraseña, datos) por internet hasta tu backend. El camarero anota el pedido y lo lleva a la cocina.
3. Procesamiento del backend (cocina). El backend comprueba si ese email ya existe, cifra la contraseña y aplica tus reglas de negocio. El chef verifica que hay ingredientes y sigue la receta.
4. Operación en la base de datos (recetario). El backend le dice a la base de datos que registre al nuevo usuario y esta lo confirma. El chef anota el pedido en el registro de la cocina.
5. Respuesta (vuelve el camarero). Un éxito o un error educado viaja de vuelta al frontend. El camarero trae la comida o se disculpa porque se ha agotado.
6. El usuario ve el resultado (comedor). Aparece un panel nuevo o un mensaje de "el email ya existe". El cliente disfruta de la comida o elige otra cosa.

Cada función de cada producto SaaS que hayas usado (publicar un tuit, reservar en Airbnb, enviar un mensaje de Slack) es una variación de este mismo ciclo.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Las tres capas y lo que cada una nunca debe hacer

La potencia de este modelo no es solo saber qué hace cada capa. Es saber qué nunca debe hacer cada una, porque ahí es donde las construcciones salen mal.

El frontend muestra; no decide. Captura entradas y responde al instante a los clics, pero nunca debe guardar datos de forma permanente ni contener lógica de negocio sensible. Además no tiene memoria: cada vez que el usuario recarga la página, el frontend lo olvida todo, como si el comedor se reiniciara después de cada servicio. Si la información debe sobrevivir, pertenece a la base de datos.

El backend es el guardián. Nunca confíes en el frontend. Cada petición debe validarse, autenticarse y autorizarse en la cocina, igual que una buena cocina revisa cada pedido aunque el camarero se haya equivocado. Un usuario con malas intenciones puede saltarse por completo tus bonitos formularios; el backend es lo que de verdad te protege.

La base de datos almacena; no piensa. Guarda los datos a salvo, los recupera rápido y mantiene las relaciones entre las cosas. No toma decisiones de negocio, no da formato a los datos para mostrarlos ni envía emails. Es el recetario, no el chef.

La API es un contrato. Define exactamente cómo hablan frontend y backend, y si cambias el contrato, rompes el código existente. El camarero y la cocina deben ponerse de acuerdo en el formato del pedido.

Por qué la base de datos es la reina

Esto es lo que la mayoría de los constructores primerizos no ve: tu estructura de datos determina todo lo demás. Si el diseño de la base de datos es erróneo, ningún frontend bonito ni backend ingenioso puede salvarte. Cimientos equivocados, casa torcida, para siempre.

Esto invierte el instinto de obsesionarse primero con la interfaz. La web no es el producto; es la interfaz del producto. El producto real es tu modelo de datos más tu lógica de negocio. Una interfaz se puede rediseñar cualquier fin de semana. Reestructurar una base de datos que ya contiene datos de clientes es realmente doloroso. Así que diseña primero los cimientos; he explicado exactamente cómo en bases de datos explicadas para fundadores no técnicos.

Una idea errónea más que conviene matar: backend y base de datos no son lo mismo. El backend es lógica. La base de datos es almacenamiento. Trabajos totalmente distintos, y cuando hables con la IA sobre tu producto, tendrás que nombrar el correcto.

Por qué este modelo mental importa cuando construyes con IA

La IA escribe el código ahora: las herramientas para construir un producto real cuestan unos pocos cientos de euros al mes, no el salario de un equipo de desarrollo. Pero la IA necesita dirección, y dirigir exige saber de qué capa hablas:

• "Añade un botón" → frontend
• "Valida que los emails sean únicos" → backend
• "Guarda las preferencias del usuario" → base de datos

El modelo también te dice dónde viven los problemas. ¿Página lenta? Puede ser el frontend o una consulta del backend. ¿Datos erróneos en pantalla? Puede ser el contrato de la API o la base de datos. Los fundadores sin este mapa acaban haciendo prompts a ciegas y aceptando lo que produzca la IA, que es justo como se cae en la trampa del vibe coding. Los que lo tienen toman decisiones de arquitectura reales: ¿esto debe calcularse en el frontend o en el backend? ¿Es una tabla nueva o una columna nueva?

No estás aprendiendo a cocinar. Estás aprendiendo lo suficiente sobre cómo funciona un restaurante para ser el dueño.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Cuál es la diferencia entre el frontend y el backend?

El frontend se ejecuta en el navegador del usuario y es todo lo que ve y pulsa: el comedor. El backend se ejecuta en un servidor y piensa: aplica reglas, comprueba permisos, procesa peticiones: la cocina. Los usuarios nunca ven el backend, pero ahí ocurre el trabajo real.

¿Dónde se guardan realmente los datos de mi SaaS?

En la base de datos, la única capa donde los datos sobreviven de forma permanente. El frontend lo olvida todo al recargar y el backend procesa peticiones sin conservarlas. Cuentas de usuario, pedidos, ajustes: todo vive en tablas de la base de datos, como las recetas y las existencias en el libro del restaurante.

¿Necesito entender de código para crear un SaaS con IA?

No, pero necesitas este modelo mental. La IA escribe la implementación; tú decides a qué capa pertenece una función, revisas lo que vuelve y detectas cuándo algo está en el lugar equivocado. Es una habilidad de propietario, no un título de ingeniería.

¿Debería diseñar primero la interfaz o la base de datos?

La base de datos. Tus datos sobreviven a tu código: la interfaz se puede rediseñar sin fin, pero cambiar un modelo de datos que ya contiene registros reales de clientes es doloroso. Haz bien los cimientos primero y todas las capas superiores se vuelven más fáciles.