El stack que uso para crear proyectos pequeños, rápidos y baratos

Cuando hablo de desarrollar aplicaciones para clientes, casi siempre me refiero a proyectos pequeños y comunes: aplicaciones web con algunos usuarios activos, autenticación, subida de archivos, conexión a base de datos, correos transaccionales y un dominio en producción.

Este tipo de proyectos existen por todos lados. La diferencia es qué tan rápido puedes entregarlos y cuánto cuestan mantenerlos.

Hace algunos años, algo así podía tomar meses. Hoy, gracias a una combinación de frameworks bien definidos, servicios en la nube e inteligencia artificial, estos mismos proyectos se pueden construir en cuestión de días.

En este artículo te explico el stack que uso actualmente, por qué lo uso y en qué casos sí y no lo recomiendo.

Qué considero un “proyecto pequeño”

Antes de entrar en herramientas, aclaremos a qué me refiero con un proyecto pequeño:

• Aplicación web
• Un grupo reducido de usuarios activos
• Frontend y backend tradicionales
• Autenticación
• Base de datos
• Subida de archivos
• Correos transaccionales
• Coste bajo de despliegue y mantenimiento

No estamos hablando de sistemas distribuidos, microservicios, apps móviles complejas ni APIs públicas de alto tráfico.

Cómo desarrollaba aplicaciones antes

Durante mucho tiempo, el enfoque clásico era:

• Frontend por separado (React, Vue o un generador estático)
• Backend por separado (Express, Django, Laravel, Nest, etc.)
• Base de datos conectada al backend
• Dos repositorios
• Dos despliegues
• Dos entornos que mantener

Este enfoque sigue siendo totalmente válido y, de hecho, es ideal para proyectos grandes o equipos múltiples.

El problema aparece cuando quieres rapidez, simplicidad y menos fricción para proyectos pequeños.

Por qué ahora prefiero un framework full stack

Para este tipo de proyectos, hoy prefiero trabajar con frameworks full stack, donde frontend y backend viven en el mismo proyecto.

La razón no es moda ni preferencia personal, sino productividad.

Un solo proyecto implica:

• Menos configuración
• Menos duplicación
• Menos decisiones técnicas
• Más velocidad de entrega

El framework principal: Next.js

En la mayoría de estos proyectos utilizo Next.js.

No porque sea “el mejor”, sino porque:

• Combina frontend y backend en un solo proyecto
• Usa tecnologías que ya conocemos (React + Node)
• Permite compartir lógica entre frontend y backend
• Tiene múltiples métodos de renderizado

Cómo lo uso en la práctica

• Server Side Rendering (SSR) para páginas que necesitan SEO y carga rápida
• Static Site Generation (SSG) para landings o páginas informativas
• Route Handlers (API Routes) para el backend

Algo importante:
👉 No uso Server Actions

Prefiero crear APIs explícitas con rutas y URLs.
¿Por qué?

• Facilita separar el backend en el futuro
• Hace más claro el diseño del sistema
• Evita depender de features nuevas e inestables
• Permite escalar o migrar sin rehacer todo

Alternativas a Next.js

Next.js no es la única opción. Existen alternativas interesantes:

• TanStack Start: prometedor, muy enfocado en calidad, pero todavía joven
• SvelteKit: ideal si no quieres JSX ni virtual DOM
• Nuxt: excelente opción si prefieres Vue
• Astro: no es exactamente un metaframework, pero permite lógica de backend y múltiples frameworks de frontend

Todas siguen la misma idea: un solo proyecto, frontend y backend juntos.

Base de datos y ORM

Para la capa de datos utilizo:

• PostgreSQL como base de datos
• Prisma como ORM

Por qué PostgreSQL

• Es open source
• Tiene una comunidad enorme
• Hay hosting en prácticamente cualquier nube
• Es fácil migrar luego a SQL puro si lo necesitas

Plataformas comunes para PostgreSQL:

• Neon
• Supabase
• ElephantSQL
• AWS, Azure, GCP

Aunque muchas cobran desde ~$20, la flexibilidad y estabilidad lo valen para proyectos reales.

UI y componentes visuales

Para la interfaz utilizo una UI Library, específicamente shadcn/ui.

¿Por qué?

• Componentes comunes listos para usar
• Código accesible y modificable
• No dependes de estilos cerrados
• Acelera muchísimo el desarrollo

Incluye:

• Formularios
• Botones
• Cards
• Avatares
• Sidebars
• Command palettes
• Layouts completos

Ideal cuando quieres que algo se vea bien sin perder tiempo en CSS.

Formularios y validaciones

Aquí el combo es:

• React Hook Form para manejar formularios
• Zod para validaciones

Lo interesante es que Zod se puede usar tanto en frontend como backend, lo que permite:

• Definir esquemas una sola vez
• Validar datos en ambos lados
• Reducir errores y duplicación

Subida y almacenamiento de archivos

No guardo archivos grandes en la base de datos.

En su lugar, uso almacenamiento externo.

Mi opción habitual

• DigitalOcean Spaces

Razones:

• $5 por 250 GB
• Precio fijo y predecible
• Compatible con S3
• Fácil migración futura a AWS S3

Ideal para:

• Imágenes
• PDFs
• Videos
• Archivos de usuarios

Correos transaccionales

Para emails utilizo Brevo.

Ventajas:

• Plan gratuito (~300 emails/día)
• No requiere tarjeta de crédito
• Fácil integración
• Soporte para email, SMS y WhatsApp

Perfecto para:

• Confirmaciones
• Reset de contraseña
• Notificaciones
• Eventos del sistema

Autenticación

Actualmente utilizo Better Auth.

¿Por qué?

• Más simple que soluciones anteriores
• Menos errores
• Framework-agnostic
• Fácil integración con ORMs como Prisma o Drizzle
• Sistema de plugins
• Mejor preparada para flujos modernos (IA, MCPs, etc.)

Pagos (depende del país)

Aquí no hay una única respuesta.

• Stripe no está disponible directamente en muchos países de LATAM
• Alternativas comunes:
  • Mercado Pago
  • PayPal
  • Proveedores locales

Esto depende totalmente del cliente y el contexto.

Despliegue: Railway

Para producción uso Railway.

Lo elijo porque:

• Frontend, backend y base de datos en un solo lugar
• Despliegue automático desde GitHub
• CI/CD incluido
• Diagramas claros del proyecto
• Escala bajo demanda
• Costes bajos para proyectos pequeños

Muchos proyectos reales funcionan por $10–15 al mes sin problemas.

El rol de la IA en todo esto

Hoy casi todo este stack puede generarse con IA.

Personalmente:

• Ya no dependo tanto de editores tradicionales
• Uso modelos como Claude para generar estructuras completas
• La IA acelera, pero no decide por ti

El verdadero valor está en:

• Saber qué generar
• Saber qué revisar
• Saber qué NO aceptar

Esto no es para principiantes.
Si aún estás aprendiendo a programar, no empieces aquí.

Primero aprende las bases.
Luego, optimiza el tiempo.

Limitaciones de este enfoque

Este stack no es para todo.

No es ideal si necesitas:

• WebSockets complejos
• GraphQL servers dedicados
• Versionado avanzado de APIs
• Múltiples frontends (web + móvil)
• Arquitecturas más grandes

En esos casos, separar frontend y backend vuelve a ser la mejor opción.

Conclusión

Para proyectos pequeños, rápidos y económicos, este stack funciona increíblemente bien.

Es el mismo enfoque que usan muchos servicios modernos, incluidos muchos productos de IA que vemos hoy.

La clave no está en usar más herramientas, sino en usar las correctas según el contexto.

Si sabes programar y quieres entregar más rápido, con menos fricción y menor coste, este enfoque es una excelente opción.