Capas de una app: lo que nadie te explica antes de vibecoder
Hay una trampa que nadie te avisa cuando empiezas a vibecoder. Abres Claude o Cursor, escribes "crea una app donde mis clientes puedan hacer pedidos", y en diez minutos tienes algo que parece funcionar. Colores, botones, un formulario. Te emociona.
Luego alguien intenta usarla de verdad y todo se rompe. El pedido no se guarda. Los usuarios no pueden volver a entrar con su cuenta. Los datos de un usuario los ve otro. O simplemente: funciona en tu ordenador pero en ningún otro.
No es un fallo del prompt. Es que estás construyendo sobre terreno que no entiendes. Y cuando algo falla, no sabes ni por dónde empezar a buscar.
Este artículo te da lo que nadie te cuenta al principio: las capas de una app — frontend, backend, base de datos y autenticación — explicadas sin jerga, con analogías del mundo real. No necesitas saber programar para leerlo. Solo necesitas entenderlo para vibecoder con criterio.
1. Por qué toda app tiene capas (y por qué importa saberlo)
1.1 La metáfora del restaurante
Imagina que vas a un restaurante. Tú llegas, te sientas, miras la carta, pides tu plato y te lo traen a la mesa. Eso es lo que tú ves. Pero detrás hay una cocina donde preparan la comida, una despensa donde guardan los ingredientes, y alguien en la puerta que comprueba que tienes reserva.
Una aplicación funciona exactamente igual:
- El comedor es lo que ves: botones, formularios, colores, pantallas. Es el frontend.
- La cocina es donde ocurre el trabajo real: cálculos, lógica, reglas del negocio. Es el backend.
- La despensa es donde se guardan los datos: usuarios, pedidos, mensajes. Es la base de datos.
- El portero de la entrada es quien comprueba que tienes permiso para estar ahí. Eso es la autenticación.
Cada capa existe por una razón concreta. No son caprichosas. Y cuando algo falla, casi siempre puedes identificar en cuál de las cuatro está el problema.
1.2 ¿Por qué el vibecoder necesita entender esto?
Cuando vibecodes, la IA genera código que abarca todas estas capas a la vez. Si no sabes que existen, no puedes:
- Describir bien lo que quieres (el prompt)
- Identificar dónde está el error cuando algo falla
- Tomar decisiones sensatas sobre herramientas y plataformas
- Saber cuándo lo que pides es sencillo y cuándo es complejo
El vibecoding no te saca la necesidad de entender qué estás construyendo. Te saca la necesidad de escribirlo con tus propias manos. Pero el criterio sigue siendo tuyo.
No tienes que saber construirlo. Sí tienes que saber qué es.
2. El frontend: lo que el usuario toca
2.1 La cara visible de tu app
El frontend es todo lo que el usuario ve y con lo que interactúa. Botones, menús, formularios, pantallas, colores, animaciones. Si puedes hacer clic en ello o leerlo, es frontend.
Cuando le dices a una IA "haz que el botón sea azul" o "añade un campo para el teléfono" o "muestra un mensaje de éxito cuando se envíe el formulario", estás hablando de frontend.
Volviendo al restaurante: es el diseño del local, la presentación de los platos en la mesa, el menú que lees. Es la primera impresión. Es lo que el cliente valora visualmente.
Pero el frontend, solo, no hace nada útil. Un restaurante precioso con cocina vacía no da de comer a nadie.
2.2 Lo que el frontend no puede hacer solo
El frontend tiene una limitación fundamental: no guarda datos de forma permanente. Si cierras el navegador, todo desaparece.
También tiene un problema de seguridad: el código del frontend es visible para todo el mundo. No puedes poner ahí tus contraseñas de base de datos, ni las reglas de negocio que no quieres que los usuarios conozcan, ni la lógica que calcula precios.
Por eso existe el backend.
2.3 Qué tecnologías hay aquí (sin profundizar)
Cuando la IA genera tu frontend, usa cosas como HTML, CSS y JavaScript, o frameworks como React o Next.js. No necesitas saber qué son en detalle. Lo que sí es útil saber: si tu app tiene interfaz, tiene frontend. Sea una web, una app móvil o una extensión del navegador.
3. El backend: la cocina donde ocurre la magia
3.1 El cerebro invisible
El backend es la parte de la app que el usuario no ve nunca. Es el código que se ejecuta en un servidor (un ordenador remoto), que recibe las peticiones del frontend, las procesa y devuelve una respuesta.
Cuando pides una pizza en una app de comida a domicilio, el frontend muestra el botón de "Confirmar pedido". Pero cuando lo pulsas, es el backend quien:
- Comprueba que hay stock de los ingredientes
- Calcula el precio con los descuentos aplicables
- Registra el pedido en la base de datos
- Avisa al repartidor
- Envía el email de confirmación
Todo eso ocurre en el backend, invisible para ti.
El backend es donde viven las reglas. "Los usuarios gratis no pueden acceder a esta función." "Solo los administradores pueden borrar pedidos." "Si el stock llega a cero, deja de aceptar compras." Esas decisiones no están en el botón — están en el servidor.
3.2 Por qué no puedes hacer todo en el frontend
Hay cosas que técnicamente podrías hacer en el frontend pero que sería irresponsable:
- Comprobar si una contraseña es correcta: si la lógica está en el navegador, cualquiera puede verla y saltársela.
- Calcular precios finales: alguien podría manipular el código del navegador para pagar menos.
- Acceder a la base de datos directamente: expondrías todos tus datos al mundo.
El backend actúa como intermediario de confianza. El frontend le pregunta, el backend decide, y solo devuelve lo que debe devolver.
3.3 El backend en el vibecoding
Cuando vibecodes y usas plataformas como Supabase, Firebase o similares, parte del backend ya viene hecho. Esto es una ventaja enorme: no tienes que construir el servidor desde cero. Pero sí tienes que entender qué parte del código es frontend y qué parte es backend, porque los errores de uno no se resuelven en el otro.
4. La base de datos: la memoria de tu app
4.1 Dónde vive todo lo que importa
Una base de datos es, simplificando al máximo, una hoja de cálculo muy potente que vive en un servidor. Guarda toda la información que tu app necesita recordar: usuarios, contraseñas (cifradas), productos, pedidos, mensajes, configuraciones.
Sin base de datos, tu app es como una tienda que no tiene archivo: atiende a los clientes, pero al cerrar por la noche olvida todo lo que ocurrió durante el día.
Imagina el libro de reservas de un restaurante. Ahí están todos los nombres, fechas, mesas y peticiones especiales. Cuando llega el cliente, el maître consulta el libro. Cuando se va, apunta lo que ocurrió. La base de datos es ese libro, pero digital, instantáneo y capaz de gestionar millones de entradas a la vez.
4.2 Cómo se organiza la información
Los datos en una base de datos se guardan en tablas (como las hojas de un Excel). Cada tabla tiene columnas (qué tipo de información) y filas (cada registro individual).
Por ejemplo, una app de pedidos podría tener:
- Tabla usuarios: id, nombre, email, fecha de registro
- Tabla pedidos: id, id_usuario, producto, fecha, estado
- Tabla productos: id, nombre, precio, stock
Las tablas se relacionan entre sí. El pedido sabe a qué usuario pertenece porque guarda su id. Esto es lo que hace que toda la información esté conectada, aunque esté en tablas separadas.
4.3 El error más común del vibecoder con las bases de datos
Uno de los fallos más frecuentes al vibecoder sin entender esto es mezclar lo que se guarda en la base de datos con lo que solo vive en la pantalla.
Si le dices a la IA "guarda los elementos del carrito de la compra", hay una diferencia enorme entre guardarlos en la base de datos (persisten aunque cierres el navegador, aunque pase una semana) y guardarlos solo en memoria del navegador (desaparecen al cerrar la pestaña).
Entender dónde viven los datos te ayuda a describir mejor lo que necesitas.
5. La autenticación: el portero de tu app
5.1 Qué es y por qué existe
Autenticar significa verificar que eres quien dices ser. Es el proceso de "iniciar sesión": le dices a la app quién eres (tu email) y demuestras que realmente eres tú (tu contraseña, un código por SMS, tu huella).
Sin autenticación, cualquier persona podría entrar a cualquier cuenta. Tu app no sabría quién es quién.
La analogía más directa es la del acceso a un edificio de oficinas. No basta con decir "soy empleado de la empresa X". Tienes que mostrar tu tarjeta. Si coincide, la puerta se abre. Si no, te quedas fuera.
5.2 Autenticación y autorización: no es lo mismo
Aquí hay una distinción que confunde a mucha gente, pero es importante:
- Autenticación: ¿Eres quien dices ser? → El sistema verifica tu identidad.
- Autorización: ¿Tienes permiso para hacer esto? → El sistema verifica qué puedes hacer.
Un empleado que entra al edificio con su tarjeta (autenticación) no necesariamente puede entrar a la sala de servidores (autorización). Ha demostrado que es empleado, pero no tiene el rango necesario para esa sala en concreto.
En una app, se traduce así: un usuario autenticado puede ver su perfil, pero no puede ver el de otro usuario. Un administrador puede borrar cuentas; un usuario normal, no.
No confundas "está logueado" con "puede hacer cualquier cosa". La autorización es la segunda capa de seguridad que muchos vibecorders olvidan configurar.
5.3 Métodos de autenticación que verás en el vibecoding
Cuando vibecodes y añades un sistema de login, la IA suele proponer una de estas opciones:
- Email y contraseña: lo más clásico. El usuario crea una cuenta con su email y elige una contraseña.
- Magic link: el usuario solo pone su email, y la app le envía un enlace de un solo uso. No hay contraseña. Más seguro y más cómodo.
- Login con Google / GitHub: el usuario usa su cuenta existente para autenticarse. No necesita crear otra contraseña nueva.
- OTP (código de un solo uso): la app envía un código por email o SMS que caduca en pocos minutos.
La elección depende de tu público y de cuánta fricción toleras. Para una app interna de empresa, un magic link puede ser perfecto. Para una tienda con millones de usuarios, probablemente quieras varias opciones.
6. Cómo se comunican las capas entre sí
6.1 La API: el lenguaje común
Hasta ahora hemos visto las capas por separado, pero ¿cómo hablan entre sí? A través de algo llamado API (Application Programming Interface). No te asustes con las siglas: una API es simplemente un conjunto de reglas sobre cómo una parte de la app le pide cosas a otra.
Volviendo al restaurante: la API sería el sistema de tickets de cocina. El camarero no entra a la cocina a decirle al cocinero lo que necesita — escribe un ticket con el pedido y lo pasa por la ventanilla. La cocina lo recibe, lo procesa, y devuelve el plato preparado.
La API define:
- Qué se puede pedir (rutas o endpoints)
- Cómo se pide (formato de la petición)
- Qué se devuelve (formato de la respuesta)
6.2 El flujo completo de una acción
Para que veas cómo encaja todo, aquí está el flujo completo de algo tan sencillo como "el usuario inicia sesión":
- El usuario escribe su email y contraseña en la pantalla → esto es frontend
- El frontend envía esos datos al servidor mediante la API
- El backend recibe los datos y los compara con los que tiene guardados
- El backend consulta la base de datos para verificar que ese email existe y que la contraseña coincide (cifrada)
- La autenticación confirma la identidad y genera una sesión o token
- El backend devuelve la respuesta al frontend: "acceso permitido"
- El frontend muestra la pantalla de bienvenida
Siete pasos para algo que ocurre en menos de un segundo. Y si cualquiera de esos pasos falla, el login no funciona. Entender dónde está el fallo es lo que separa al vibecoder que resuelve problemas del que se queda bloqueado.
6.3 Qué plataformas juntan varias capas
Una de las razones por las que el vibecoding es posible hoy es que existen plataformas que ya incluyen varias capas hechas:
- Supabase: base de datos + autenticación + API, todo junto y con panel visual
- Firebase: similar, de Google, muy usado en apps móviles
- Vercel: despliega tu frontend y backend en segundos, sin gestionar servidores
Cuando la IA te propone usar alguna de estas herramientas, no lo hace al azar. Cada una resuelve un conjunto de capas. Saber qué capa cubre cada plataforma te ayuda a evaluar si es la adecuada para lo que quieres construir.
7. Errores frecuentes del vibecoder que no entiende las capas
7.1 "Mi app funciona pero los datos desaparecen"
Clásico. El frontend muestra todo correctamente, pero al recargar la página o al día siguiente, todo se ha borrado. Causa: los datos no se están guardando en la base de datos, sino en la memoria del navegador.
Cuando vibecodes, tienes que ser explícito: "quiero que este dato se guarde en la base de datos y persista aunque el usuario cierre el navegador". Si no lo dices, la IA puede tomar el camino más corto, que no siempre es el correcto.
7.2 "Cualquier usuario puede ver los datos de cualquier otro"
Esto ocurre cuando hay autenticación pero no autorización. La app sabe quién eres, pero no tiene reglas sobre qué puede ver cada uno.
La solución se llama RLS (Row Level Security) en bases de datos como Supabase: reglas a nivel de fila que dicen "este usuario solo puede ver sus propios datos". Es algo que la IA puede generar, pero tienes que pedirlo explícitamente.
7.3 "Funciona en local pero no en producción"
Cuando desarrollas en tu ordenador, la app usa una base de datos local. Cuando subes la app a internet (producción), usa otra. Si no has configurado correctamente las variables de entorno (las "claves" que conectan el código con la base de datos real), la app funciona en local y explota en producción.
Entender que hay una base de datos de desarrollo y una de producción te evita horas de confusión.
7.4 Pedir demasiado en un solo prompt
Cuando no entiendes las capas, tiendes a hacer prompts del tipo: "crea una app completa de gestión de clientes con login, dashboard, historial de pedidos, pagos con Stripe y notificaciones por email".
Eso abarca las cuatro capas a la vez, con integraciones externas. El resultado suele ser código que parece funcionar pero que tiene errores ocultos en cada capa. Lo correcto es ir capa a capa, validar que funciona, y luego añadir complejidad.
8. Cómo usar este conocimiento cuando vibecodes
8.1 Estructura tus prompts por capas
Cuando tengas claro qué quieres construir, describe lo que necesitas en cada capa:
- Frontend: "Quiero una pantalla con un formulario de contacto con los campos nombre, email y mensaje, y un botón de enviar que muestre un mensaje de éxito al pulsar."
- Backend: "Cuando se envíe el formulario, quiero que el backend envíe un email con los datos a mi dirección."
- Base de datos: "Guarda cada envío del formulario en una tabla llamada
contactoscon los campos nombre, email, mensaje y fecha." - Autenticación: "Solo los usuarios con rol admin pueden ver el listado de contactos."
Cuatro prompts separados, claros, precisos. Mucho mejor que un prompt caótico que mezcla todo.
8.2 Cuando algo falla, pregunta en qué capa está
Antes de entrar en pánico, hazte estas preguntas:
- ¿El problema es visual? → Frontend
- ¿Los datos no se guardan o se guardan mal? → Base de datos
- ¿La lógica de negocio no funciona? → Backend
- ¿El usuario no puede entrar o ve cosas que no debería? → Autenticación
Luego díselo a la IA: "El problema está en el backend. Cuando el usuario envía el formulario, el servidor devuelve un error 500. ¿Qué puede estar fallando?"
8.3 El siguiente paso
Entender las capas es el mínimo indispensable. Pero para vibecoder de verdad — con criterio, sin romperte la cabeza cada vez que algo falla — hay más cosas que ayudan: saber elegir el stack adecuado, entender el flujo de datos, saber depurar errores con la ayuda de la IA.
En Claudio Academy tienes el camino completo: desde los primeros prompts hasta construir apps reales con autenticación, base de datos y lógica de backend. Sin código, sin clases de programación, con proyectos concretos que puedes usar desde el primer día.
¿Quieres dominar la IA con Claude?
Más de 20 horas de vídeo en español para pasar de cero a experto. Pago único de 49€, acceso de por vida.
Ver el curso