Una pila web para startups en la era de los agentes de IA: Next.js, MUI y Firebase
Una pila web para startups en la era de los agentes de programación: Next.js, MUI, Firebase, Vercel y PostHog, con una configuración mínima del agente y la razón detrás de cada elección.
Fuentes: The Teach Stack for Building Full-Stack Apps in the AI-Agentic Era (2026 Edition)
Elegir una tecnología cuando el código está parcialmente escrito por máquina
Agentes de programación como Claude Code y Codex han cambiado la forma en que se desarrolla el software. La iteración es mucho más rápida, lo cual solo es útil si el código se mantiene lo suficientemente manejable y escalable para que el proyecto siga evolucionando.
Las startups en etapa inicial dependen de la velocidad de iteración. Los requisitos cambian rápidamente, las funcionalidades se añaden a diario y el código se reescribe constantemente. En ese entorno, las tecnologías elegidas deben permitir cambios rápidos sin empeorar la experiencia del usuario.
La tecnología presentada a continuación proviene de aproximadamente cuatro años de experimentación con herramientas modernas en una plataforma real de aprendizaje. Abarca autenticación, interfaz de usuario, backend, alojamiento, pruebas y más; el objetivo en todo momento es desarrollar rápidamente sobre una base de código que los humanos puedan seguir manteniendo, con una infraestructura escalable.
Mantener simples a los agentes y el código
Los agentes facilitan las mejoras rápidas: las correcciones de errores, las nuevas funciones y las optimizaciones de rendimiento llegan con rapidez. También facilitan la sobreingeniería, ya que añadir miles de líneas de código es algo trivial. La disciplina consiste en resistirse a resolver problemas que aún no existen y mantener el código, la infraestructura y la experiencia de usuario simples.
Una configuración sencilla y reducida también ayuda en esta era del desarrollo con agentes. Los agentes se coordinan mejor, las funciones se lanzan más pronto, los errores son más fáciles de corregir y las personas pueden seguir manteniendo lo que ya existe.
El enfoque hacia los agentes en el código en producción es equilibrado y la configuración es modesta:
- Mantenga
AGENTS.mdoCLAUDE.mdlo más breve posible. Solo incluya en ellos lo que se repite en cada conversación, junto con los detalles específicos del proyecto que los agentes suelen equivocarse. - Los archivos de instrucciones demasiado grandes pueden afectar el rendimiento de un modelo y hacerlo menos útil.
- Instale solo las habilidades que necesita una conversación y retírelas cuando esta termine.
- Menos habilidades y un archivo de instrucciones más pequeño suelen funcionar mejor que más.
- Algunas habilidades son útiles tenerlas a mano, pero no de forma permanente, ya que dejarlas instaladas contamina la ventana de contexto. Las áreas útiles son el diseño UI/UX, React y Next.js, Firebase y PostHog.
En los servidores MCP, PostHog ofrece acceso fácil a rastros de errores y registros, lo que acelera la depuración. Context7 proporciona documentación actualizada de las bibliotecas al modelo para que los agentes puedan consultar la documentación más reciente de bibliotecas y frameworks. La mayoría de las veces los agentes resuelven los problemas sin la ayuda de un servidor MCP, por lo que activarlos rara vez es necesario.
La regla general es que cada herramienta, habilidad o servidor adicional compite por la atención del modelo. Cualquier elemento que no se demuestre útil en la tarea actual es mejor excluirlo, y se puede volver a revisar la configuración cada vez que aparezca un error recurrente que pueda solucionarse con una instrucción sencilla.
Frontend: React y Next.js
React es la opción preferida para el núcleo de muchos proyectos full-stack. Vue y Svelte también son alternativas, pero el amplio ecosistema de bibliotecas de React facilita la adición de funcionalidades y los cambios de dirección, y por eso los desarrolladores lo prefieren.
El punto débil son los motores de búsqueda. Google y Bing utilizan bots que leen el HTML de una página, y una página de React suele recibir del servidor un cuerpo vacío. Para que un sitio aparezca en los resultados de búsqueda, la primera respuesta del servidor debe contener HTML con la información correcta de la página.
Next.js se encarga de esto. Es un framework de React que ofrece renderizado del lado del servidor y generación estática, por lo que las páginas se renderizan primero en el servidor y luego el HTML se envía al navegador, lo que significa que el contenido inicial contiene todo lo que necesitan los bots. Después, solo el JavaScript necesario se envía al cliente, manteniendo el paquete pequeño. Tanto la experiencia del usuario como la comprensión de los rastreadores mejoran.
El estándar actual en los proyectos de Next.js es el app router, que facilita el uso de funcionalidades como la regeneración estática incremental y el pre-renderizado parcial, haciendo que la aplicación parezca más rápida. Los nuevos proyectos deberían comenzar con él.
React se está orientando hacia el lado del servidor, acercándose algo en espíritu a PHP, y el app router ofrece una buena experiencia de desarrollo para componentes centrados en el servidor. El caché, Turbopack y una configuración amigable con los agentes facilitan la creación e iteración rápida.
UI: una biblioteca de componentes sobre un diseño personalizado
El desarrollo web tradicional sigue un proceso de planificación, diseño UI/UX, implementación y numerosas rondas de intercambio entre diseñadores y desarrolladores. Las startups no pueden permitirse un ciclo tan largo.
El enfoque más eficiente ha sido elegir un framework UI sólido, en este caso MUI, y seguir una plantilla de diseño. La alternativa es que un diseñador dibuje todo en Figma y luego los desarrolladores lo reconstruyan en React. Mantener una única fuente de verdad en el código ahorró meses de trabajo.
MUI ofrece un amplio conjunto de componentes personalizables que cubren necesidades comunes. Todo puede modificarse, pero los valores predeterminados son lo suficientemente buenos como para que la mayoría de los componentes se utilicen con su comportamiento y apariencia estándar. También incluye una gran colección de íconos que se pueden usar como componentes React, por lo que incluirlos es sencillo.
Existen alternativas:
- shadcn/ui es moderno y popular, aunque para algunos copiar el código de la biblioteca a su propio repositorio a través de una CLI es una práctica cuestionable.
- Ant Design es una opción sólida.
- Chakra UI también funciona como framework de interfaz de usuario.
- HeroUI, anteriormente NextUI, también es una buena opción.
Algunas personas prefieren styled-components o Tailwind CSS. Con cualquiera de ellos, aún se escribe mucho CSS, lo cual resulta menos eficiente que utilizar un framework de interfaz de usuario en términos de experiencia de desarrollo, especialmente cuando el objetivo es evitar diseñar cada página desde cero.
Para obtener inspiración, las tiendas de plantillas son útiles. La tienda propia de MUI cuenta con muchas plantillas de interfaz atractivas, y Dribbble también ofrece plantillas para React. Otra opción es pedir a un agente que cree varios prototipos y elegir el mejor; además, contar con habilidades en UI/UX mejora la calidad de los resultados generados.
Formularios
Los formularios representan una gran parte del trabajo en desarrollo full-stack. Zod y React Hook Form combinan bien y cubren casi todo lo necesario. Zod se encarga de la validación de esquemas, incluyendo tipos, rangos, longitudes y enumeraciones, mientras que React Hook Form ofrece una API flexible para interactuar con el formulario. Juntos permiten componentes anidados que comparten un mismo formulario, validaciones complejas y actualizaciones en tiempo real de los datos. Los formularios comienzan a parecer casi demasiado fáciles de usar.
Dado que el esquema de validación es un objeto sencillo compatible con TypeScript, las mismas reglas pueden describir qué acepta un formulario y qué espera una función del backend. Esto elimina toda clase de incoherencias entre lo que permite la interfaz de usuario y lo que rechaza el servidor, y los agentes pueden leer un esquema de manera mucho más fiable que al leer la lógica de validación dispersa entre los controladores.
Backend, autenticación y base de datos
Firebase y Supabase ofrecen un backend como servicio, capaz de escalar hasta millones de usuarios sin que sea necesario mantener infraestructura propia. En este caso, la solución utiliza Firebase para la autenticación, el almacenamiento, la base de datos Firestore y funciones serverless que albergan la lógica de backend personalizada.
Autenticación
Clerk es un producto sólido para la autenticación, pero el sistema predeterminado de Firebase funciona bastante bien aquí. Firebase también incluye un paquete llamado firebaseui-web que configura la autenticación sin necesidad de escribir código de interfaz. Para que funcione sin problemas, la aplicación Next.js también se despliega en un subdominio dedicado a la autenticación, de modo que Firebase pueda gestionar el inicio de sesión sin dificultades.
Base de datos
En un desarrollo tradicional, con una interfaz frontal separada y un backend que accede a una base de datos, la interfaz frontal realiza numerosas llamadas a API que modifican las entradas de la base de datos. En muchos proyectos, alrededor del 80% de esas llamadas son operaciones CRUD simples, mientras que el 20% restante es más complejo, como la actualización de varias entradas o la agregación de datos de varias fuentes. Firebase se optimiza para ese 80%, lo que facilita la manipulación de datos desde la interfaz frontal sin necesidad de endpoints redundantes.
Hay dos componentes que hacen posible esto.
- Reglas de Firestore. El control de acceso y los permisos se encuentran en un único archivo,
firestore.rules. Los endpoints de API no tienen que verificar permisos en cada función, ya que Firebase verifica automáticamente si un usuario puede leer un dato o crearlo, actualizarlo o eliminarlo. Esta separación elimina gran parte del código genérico. - SDK del cliente de Firestore. La creación, lectura, actualización y eliminación de datos se realizan a través del SDK de Firebase, el cual también admite receptores en tiempo real, incrementos de contador y actualizaciones por lotes, todo lo cual se verifica automáticamente contra
firestore.rules.
Hay una advertencia: el modelo mental para almacenar datos. Firestore está optimizado para las lecturas, que suelen ser las más frecuentes, por lo que fomenta el uso de datos denormalizados. Esto puede resultar poco natural para quienes vienen de un entorno SQL, y vale la pena ver una buena presentación en una conferencia sobre el modelado de datos en Firestore.
En general, Firestore ofrece una excelente experiencia de usuario, especialmente gracias a los receptores de cambios en tiempo real, además de una buena experiencia para los desarrolladores, lo que permite que la aplicación se adapte rápidamente a las necesidades cambiantes.
Es mejor iniciar nuevos proyectos en la edición Enterprise de Firestore en modo Nativo. Esta versión ofrece funciones que faltan en la versión estándar anterior, como consultas por pipeline y búsqueda de texto completo integrada, lo que brinda la flexibilidad de una base de datos similar a MongoDB junto con la facilidad de uso de Firestore.
Funciones sin servidor
El código del cliente se mantiene deliberadamente simple, ya que las partes complejas se encuentran aisladas en el código del backend dentro de las funciones sin servidor. Mantener el frontend sencillo y el backend avanzado ha funcionado muy bien. Firebase Functions pueden contener cualquier código de backend, y pueden ser activados por una solicitud HTTP simple, por la creación o actualización de una entrada en Firestore, o según un horario establecido mediante un trabajo cron a través de Pub/Sub. Toda la funcionalidad del lado del servidor puede entonces residir en funciones separadas y autónomas.
Las herramientas BaaS como Firebase ahorran mucho tiempo y, por lo general, funcionan sin problemas. La depuración de problemas causados por irregularidades en la base de datos o migraciones fallidas es un evento raro.
Funciones de IA
La IA es una parte fundamental de las aplicaciones web modernas, y muchos productos incorporan chatbots y agentes. El SDK de IA de Vercel se encarga de la integración con diferentes proveedores de modelos y de la creación de agentes personalizados. Su ventaja radica en lo sencillo que resulta conectar diferentes modelos e intercambiarlos, ofreciendo una experiencia de desarrollo más fluida que cualquier SDK específico para un modelo.
Pruebas
Las pruebas son probablemente el tema más controvertido, especialmente para las startups con requisitos en constante cambio. Al principio no había pruebas. A medida que el producto crecía, modificar el código existente con la certeza de que la producción seguiría funcionando se volvió casi imposible, por lo que se introdujeron pruebas para el backend, concretamente en la capa de servicios de Firebase Functions. El frontend no se prueba porque se mantiene simple, mientras que el backend más complejo se prueba frente a casos límite.
Las pruebas de backend utilizan Jest, junto con faker.js para generar datos ficticios dentro de las pruebas. Se ejecutan en un proyecto de Firebase separado para que la producción quede intacta, lo que también permite iteraciones rápidas sin preocupaciones por afectar a los usuarios. Una vez que las pruebas pasan, la nueva versión de Functions se envía a producción.
La razón por la que solo se prueban los backends es el costo. Un frontend que simplemente muestra datos y llama a funciones tiene poca lógica que valga la pena verificar, y las pruebas de interfaz suelen fallar cada vez que cambia el diseño, lo cual ocurre constantemente en un producto en fase inicial. La lógica del backend es donde una regresión silenciosa puede dañar los datos o cobrar erróneamente a un usuario, por eso allí se concentra el esfuerzo.
Refactorización
A medida que el proyecto crece, las funcionalidades cambian, los requisitos evolucionan y las cosas envejecen, la refactorización se vuelve inevitable. Dos elementos contribuyen en mayor medida a modificar el código con confianza: TypeScript y pruebas de integración sólidas. TypeScript mantiene los tipos seguros tras los cambios, y las pruebas de integración confirman que la lógica sigue funcionando.
El refactoring aparece con más frecuencia de la esperada. No ha habido un período de seis meses sin alguna refactorización importante, ya que la plataforma sigue cambiando y adoptar nuevas tecnologías implica grandes modificaciones en el código. Los dos hitos más importantes fueron pasar de React puro a Next.js y luego del enrutador de páginas de Next.js al enrutador de aplicaciones.
Hosting
Dado que el backend está completamente en Firebase (Google Cloud), el frontend se despliega en Vercel, que ofrece la infraestructura más conveniente para publicar aplicaciones Next.js. Su integración con GitHub funciona bien con las ramas y no requiere configuración manual:
- Un push a
mainse despliega automáticamente en producción. - Un push a cualquier otra rama activa un despliegue de vista previa con su propio enlace, de modo que cada rama puede verse en tiempo real, lo que facilita y acelera el proceso de iteración.
Revisar un cambio implica abrir un enlace en lugar de descargar una rama y ejecutarla localmente, lo cual es adecuado para un equipo pequeño donde los diseñadores, los responsables del producto y los ingenieros quieren ver el trabajo en progreso sin necesidad de realizar configuraciones en sus propias máquinas.
Análisis y monitoreo
Saber quiénes son los usuarios y cómo utilizan el producto es valioso. Puede ahorrar semanas o meses de desarrollo al indicar qué priorizar, y un buen monitoreo mejora la experiencia al detectar errores comunes.
PostHog cubre el análisis general y el monitoreo del producto, incluyendo reproducción de sesiones, captura de excepciones, registros y mapas de origen en producción. Google Analytics para Firebase es una alternativa gratuita que requiere más configuración, mientras que Sentry es un poco más costoso. Todos ellos ayudan a conocer a los usuarios, pero nada reemplaza hablar con ellos directamente.
Correo electrónico
El correo electrónico sigue siendo una de las formas más fiables de mantenerse en contacto con los usuarios, enviar actualizaciones y mantenerlos involucrados. Recientemente, el sistema pasó de Sendgrid a react-email junto con Resend.
react-email permite crear correos altamente personalizables al convertir cada uno en un componente de React. Resend se integra bien con él y tiene precios competitivos. Dado que los correos son componentes de React, se gestionan bajo control de versiones junto con el resto del código, por lo que cada cambio se registra en un solo lugar.
Previsualizar y probar plantillas es igual de sencillo, ya que el mismo componente se muestra en el navegador durante el desarrollo y genera el HTML que llega a las bandejas de entrada.
Leer más
- Un agente financiero de QuickBooks que funciona con un LLM local mediante Ollama y LangChain — Un agente ReAct en Qwen 3.5 9B y una RTX 4070 que lee datos en tiempo real de QuickBooks sin ningún costo relacionado con la nube. Consulte el código, los resultados y las limitaciones conocidas.
- Diseño de un buscador de empleos multiagentes: pipeline, HyDE y capacidad de observación — Un pipeline de LangGraph de nueve pasos que relaciona currículos con empleos, con ocho opciones de diseño en HyDE, enrutamiento de modelos, límites de velocidad y seguimiento de operaciones.