Evolucionar un MVP sin rearquitectar desde cero

Cuando un MVP empieza a crecer, surgen preguntas incómodas: ¿rearquitecto desde cero o evoluciono lo que ya tengo? Aquí verás cómo evolucionar la arquitectura de software de un MVP cuando aparecen nuevas funcionalidades, dependencias y requisitos no funcionales, usando como caso un sistema de lectura conectado a Telegram.

¿Por qué un MVP simple termina mostrando nuevos problemas?

El primer diseño suele apuntar a una sola cosa: maximizar la simplicidad. Mantienes el MVP lo más pequeño posible, pero con una base escalable para no pintarte en una esquina.

Y aquí viene lo interesante. Cuando empiezas a usarlo en serio, te vuelves más ambicioso. Lees más, lees mejor, y aparecen necesidades que antes ni considerabas. En el caso del sistema de lectura, surgieron tres deseos concretos:

• Etiquetar automáticamente los artículos para no hacerlo a mano.
• Navegar entre artículos agrupados por un tema común.
• Generar un mind map visual con estadísticas de qué leo más, cuándo cambiaron mis intereses y dónde tengo zonas por descubrir.

Eso ya no es el MVP original. Es otra cosa.

¿Cómo cambia el diseño cuando agregas autoetiquetado y visualización?

El contenedor se mantiene, pero ahora viven dentro tres componentes en lugar de dos. Uno integra con Telegram, otro con el sistema de gestión de archivos, y se suma un tercero: un modelo para etiquetar de forma automática los documentos.

Un detalle clave del rediseño: el dispositivo ya no aparece como dependencia externa. Se abstrajo desde el diseño original, así que ese cambio no duele.

¿Qué es un MVP en arquitectura de software? Es la versión mínima funcional de tu sistema, diseñada para validar la idea con la menor complejidad posible, pero dejando espacio para crecer.

El modelo de autoetiquetado se desarrolla in house usando librerías open source. Es una decisión deliberada: no depender todavía de un sistema externo de IA, aunque la puerta queda abierta para el futuro.

¿Rearquitectar o evolucionar la arquitectura existente?

Esta es la pregunta que más cuesta responder. Cuando el alcance crece, tienes que decidir si vale la pena romper lo que ya funciona o estirar el diseño actual un poco más. Hay cuatro preguntas que conviene hacerte antes de mover una sola línea:

• ¿Vale la pena rearquitectar el sistema o puedo evolucionar la arquitectura que ya escogí?
• ¿Conviene incorporar más herramientas externas para resolver nuevos casos de uso, como el autoetiquetado?
• ¿Necesito cambiar las prioridades entre lo importante y lo urgente?
• ¿Aparecieron requisitos no funcionales nuevos que antes no estaban en el radar?

Esa última pregunta suele ser la más reveladora. Cosas como rendimiento, observabilidad o costos de cómputo pueden volverse protagonistas cuando antes no figuraban.

¿Qué son los requisitos no funcionales y por qué aparecen tarde?

Son las características del sistema que no describen una funcionalidad concreta, sino cómo se comporta: velocidad, escalabilidad, mantenibilidad, costo. Cuando agregas un modelo de etiquetado o un mind map, aparecen exigencias nuevas de procesamiento y almacenamiento que el MVP original no necesitaba contemplar.

¿Cuándo conviene rearquitectar en lugar de evolucionar? Cuando los nuevos casos de uso introducen requisitos no funcionales que el diseño actual no puede sostener sin parches frágiles.

¿Cómo proyectar el costo de un sistema cuando agregas nuevos casos de uso?

Cada componente nuevo mueve la aguja del costo. Un modelo de autoetiquetado in house implica cómputo continuo, almacenamiento de embeddings o índices, y mantenimiento del propio modelo. Un mind map con estadísticas implica procesar histórico, no solo lo nuevo.

Por eso vale la pena proyectar a tres horizontes:

• A 1 mes: costos de desarrollo y validación inicial del autoetiquetado.
• A 3 meses: costos de operación estable, con volumen real de lectura.
• A 6 meses: costos de mantenimiento, reentrenamiento del modelo y posible migración a un servicio externo si la operación in house deja de tener sentido.

Esa proyección te ayuda a decidir si la decisión de no depender de un sistema externo de IA sigue siendo la correcta o si llegó el momento de pivotar.

¿Hacia dónde evoluciona tu arquitectura?

Hay dos preguntas que te dejo abiertas para pensar tu propio caso. La primera: ¿hacia dónde está evolucionando tu arquitectura? ¿Hacia un estilo completamente distinto, o simplemente sumando funcionalidades al que ya tenías? La segunda: ¿cómo afectan los nuevos casos de uso a tu proyección de costos a 1, 3 o 6 meses?

Responderlas honestamente cambia mucho las decisiones técnicas que vienen después. Cuéntame en los comentarios qué decidiste tú: ¿rearquitectaste o evolucionaste?