Este post no está pensado solo para programadores. También es para quienes alguna vez contrataron una agencia de desarrollo (o de "productos digitales") y sintieron que estaban con los ojos vendados.
Muchas veces se compara el desarrollo de software con la construcción. Y no es casual: hay planos (diagramas), decisiones estructurales difíciles de revertir, y también egos.
Uno de los errores más comunes es tomar decisiones técnicas basadas en gustos personales o modas tecnológicas. "Quiero probar esta tecnología", "me gusta más esta otra", "por las dudas usemos esto". Esto suele derivar en mayor complejidad, más costos, más tiempo, y sobre todo, pérdida de foco en lo que realmente importa: el negocio.
¿Qué entendemos por arquitectura de software?
La arquitectura define cómo se estructura y organiza un sistema, cómo interactúan sus componentes y qué decisiones son difíciles de cambiar más adelante.
Es la base sobre la que se construye todo lo demás. Si te equivocás en las decisiones tempranas, vas a pagarlo en cada etapa que siga.
¿Qué significa que una arquitectura sea escalable?
La escalabilidad es la capacidad de un sistema de crecer sin romperse, manejando una mayor carga al agregar recursos.
Pero que algo sea escalable no implica que tenga que ser complejo.
Si estás lanzando un MVP en dos semanas para validar una idea en verano, probablemente no necesites una API con microservicios ni despliegues en múltiples regiones. Una solución simple, bien pensada y mantenible puede ser mucho más efectiva.
La clave: la escalabilidad se trata de tomar decisiones que no te dejen encerrado, no de construir para millones de usuarios desde el día uno.
¿Qué usamos en BlackBox Vision según el caso?
Después de más de 50 lanzamientos de productos, desarrollamos un criterio claro para elegir herramientas. Esto es lo que guía nuestras decisiones:
Firebase: MVPs rápidos con necesidades de tiempo real
Firebase es ideal para MVPs rápidos. Base de datos en tiempo real, NoSQL, autenticación y analytics — todo listo para usar de entrada.
Ideal para: apps de consumo, funcionalidades en tiempo real, prototipos que necesitan salir en días, proyectos donde la velocidad de llegada al mercado es la prioridad.
Trade-offs: capacidades de consulta limitadas, vendor lock-in con Google Cloud, más difícil de migrar a medida que tu modelo de datos crece.
Supabase: cuando necesitás poder relacional
Supabase es excelente si necesitás trabajar con SQL, relaciones y lógica más compleja. Requiere mayor conocimiento — Row Level Security, stored procedures, triggers — pero es potente y cumple con estándares como SOC2 Type 2 y HIPAA (en planes avanzados).
Ideal para: productos B2B, apps con relaciones de datos complejas, proyectos con requisitos de compliance, equipos que ya piensan en SQL.
Trade-offs: curva de aprendizaje más pronunciada, más setup inicial, requiere entender las internals de PostgreSQL.
Cómo elegir entre uno y otro
| Factor | Firebase | Supabase |
|---|---|---|
| Velocidad de prototipado | Más rápido | Moderado |
| Relaciones de datos | Limitadas | Fuertes |
| Tiempo real | Integrado | Integrado |
| Compliance (SOC2/HIPAA) | Limitado | Disponible |
| Camino de migración | Más difícil | Más fácil (PostgreSQL) |
| Curva de aprendizaje | Más baja | Más alta |
Sobre el frontend: no todo tiene que ser Next.js
Para una landing simple o un blog, Vite puede ser más que suficiente.
Next.js tiene sentido cuando hay necesidades específicas como el Server-Side Rendering — por ejemplo, un sitio de noticias donde el contenido debe actualizarse en cada request (como hicimos para Acercando Naciones).
Pero no todas las aplicaciones lo necesitan. Y elegir Next.js "por defecto" introduce complejidad en hosting, pipelines de build y modelo mental que muchos MVPs simplemente no necesitan.
Cuándo usar qué
- Vite + vanilla o React SPA: Landing pages, dashboards, herramientas internas, apps client-side
- Next.js: Sitios con contenido crítico para SEO, apps que necesitan SSR/ISR, proyectos con routing complejo y data fetching a nivel de página
- Astro: Sitios pesados en contenido, blogs, páginas de marketing donde querés JavaScript casi nulo
La elección correcta depende de las necesidades reales de tu producto — no de lo que sea tendencia en Twitter.
Errores arquitectónicos comunes en MVPs
Después de construir más de 50 productos, vemos los mismos patrones repetirse:
Sobreingeniería desde el día uno — Microservicios, Kubernetes, arquitectura event-driven... para una app con 100 usuarios. Empezá simple. Siempre podés agregar complejidad después.
Elegir tecnología basándose en el hype — La mejor tecnología es la que tu equipo conoce bien y que encaja con el problema. Un stack aburrido y bien entendido le gana a uno brillante y mal comprendido todas las veces.
Ignorar el camino de migración — Tu MVP va a cambiar. Elegí herramientas que te permitan evolucionar sin tener que reescribir todo. PostgreSQL te da más opciones de salida que un store NoSQL propietario.
Optimización prematura — No optimices para una escala que no tenés. Pero sí tomá decisiones que no te impidan escalar después. Hay una diferencia.
No separar responsabilidades — Incluso en un MVP, mantené tu lógica de negocio separada de tu infraestructura. Cuando llegue el momento de escalar o cambiar de proveedor, te lo vas a agradecer.
En resumen
No existe una única arquitectura ideal. Lo importante es entender el contexto, evitar la sobreingeniería y tomar decisiones alineadas con los objetivos del negocio y las verdaderas necesidades técnicas del proyecto.
La mejor arquitectura para tu MVP es la más simple que resuelva el problema de hoy dejando la puerta abierta para el crecimiento de mañana.
