Cómo elegimos la arquitectura de un MVP

Cuando un fundador nos pregunta qué arquitectura usaremos para su MVP, a menudo espera una lista larga: microservicios, colas de mensajes, capas de caché, quizá Kubernetes.

Nuestra respuesta suele ser mucho más sencilla. Y es a propósito.

En nuestro artículo anterior hablamos de cómo decidir qué construir. Este trata de cómo lo construimos, y de por qué empezar con algo sencillo casi siempre es lo correcto.

La trampa de complicarlo todo

Es fácil diseñar una primera versión como si ya tuviera un millón de usuarios. Parece lo responsable. Queda muy bien en un diagrama.

Pero cada pieza extra tiene un coste. Más servicios significan más cosas que desplegar, más cosas que vigilar y más sitios donde se esconden los errores. La primera versión tarda más en salir, y cada cambio posterior también va más lento.

En la fase de MVP, el mayor riesgo no es tener demasiados usuarios. Es construir lo que no era y no poder cambiarlo rápido. Por eso diseñamos, antes que nada, para poder cambiar rápido.

Nuestro stack por defecto

La mayoría de los productos que construimos parten de la misma base.

Next.js para la web. Ofrece páginas rápidas y, como puede generar las páginas en el servidor, los buscadores leen bien tu contenido. Es una parte importante de cómo integramos el SEO desde el primer día en lugar de arreglarlo después.

NestJS sobre Node.js para el backend. NestJS le da al backend una estructura clara desde el principio. Cada parte de tu producto, como usuarios, pagos o pedidos, vive en su propio módulo con límites claros. Es una sola aplicación, pero organizada como si pudiera convertirse en varias. Eso importa más adelante, y volveremos a ello.

PostgreSQL para la base de datos. Es fiable, muy conocida y aguanta mucho más de lo que la mayoría de productos necesitará al principio. Sirve para datos estructurados, datos flexibles y búsquedas, así que rara vez hace falta una segunda base de datos al inicio.

React Native para móvil, cuando el móvil es clave. Si tu producto necesita una app en App Store y Google Play, React Native nos permite construir ambas desde un solo código. Como usa el mismo lenguaje que el resto del stack (TypeScript), la lógica y los tipos se pueden compartir entre web, móvil y backend. Si la app móvil no es central para lo que quieres validar, a menudo empezamos con una web adaptable y añadimos la app cuando el producto ha demostrado su valor.

Un solo lenguaje en todo el producto también significa que un mismo equipo puede moverse por todo él, lo que lo hace más rápido y más barato, sobre todo al principio.

Tres preguntas antes de añadir nada

Cada vez que alguien propone algo nuevo para la arquitectura, nos preguntamos:

¿Qué problema resuelve ahora mismo, no algún día? ¿Qué pasa si todavía no lo construimos? ¿Qué tan difícil será añadirlo más adelante?

Si la respuesta sincera es "no se rompe nada sin ello y podemos añadirlo después", espera. La mayoría de las veces, esa es la respuesta.

Un comienzo sencillo que puede crecer

Empezar sencillo no significa ignorar el futuro. Significa tomar decisiones que lo mantengan abierto.

Por eso la estructura importa tanto. Como el backend en NestJS está dividido en módulos limpios, cualquier parte puede separarse en su propio servicio cuando haya una razón real. Simplemente no lo hacemos antes de que exista esa razón.

Algunas señales reales de que es momento de añadir más:

Las páginas o peticiones van lentas con tráfico real. Ahí empieza a tener sentido la caché. Algunas tareas tardan demasiado dentro de una petición, como enviar cientos de correos o procesar archivos. Ahí ayudan las colas de trabajos en segundo plano. La base de datos está haciendo demasiado trabajo. Primero mejores índices, y después réplicas de lectura si hace falta. El equipo crece y distintos grupos necesitan publicar cambios de forma independiente. Ahí dividir en servicios separados puede compensar.

Cada una de estas decisiones responde a algo real, medido en tu producto. No a una suposición hecha antes del lanzamiento.

Qué significa esto para ti

Una arquitectura sencilla y bien estructurada significa que tu producto sale antes y cuesta menos construirlo. Los cambios después del lanzamiento son más rápidos, porque hay menos piezas en movimiento. Y cuando contrates tu propio equipo, heredará un código basado en herramientas populares y bien documentadas que entenderá rápido.

Una buena arquitectura no consiste en construir para un millón de usuarios el primer día. Consiste en no bloquearte cuando lleguen.

¿Estás planificando tu producto?

Si estás pensando cómo construir tu primera versión, estaremos encantados de hablarlo contigo. Empieza por cómo definimos el alcance de un MVP o cuéntanos tu idea.