Arquitectura MVP: de Telegram a Remarkable

Diseñar una solución partiendo de un problema personal es una de las mejores formas de practicar arquitectura de software. Aquí verás cómo Nicolás Bohórquez analiza un flujo de información entre Telegram y un dispositivo de tinta electrónica usando técnicas como los seis sombreros, priorización y el modelo C4 para llegar a un MVP viable.

¿Cuál es el problema real que se quiere resolver con arquitectura?

El punto de partida es concreto: Nicolás colecciona enlaces, documentos e imágenes en un canal privado de Telegram y luego los transfiere manualmente a un Remarkable, una tableta de tinta electrónica que usa para leer sin forzar la vista por su alta miopía [01:00].

El flujo actual es tedioso. Hay que conectar el Remarkable a la misma red, exportar el contenido como PDF y copiarlo a mano. Y hay una restricción dura: el cliente no quiere cambiar de herramientas, ni Telegram para coleccionar ni Remarkable para leer.

¿Qué es un canal privado de Telegram? Es un canal de mensajería instantánea donde varias personas pueden suscribirse, pero en este caso el dueño es el único productor y consumidor de la información.

¿Qué es Remarkable y por qué condiciona la solución?

Remarkable es una tableta de e-ink pensada para enfocarse en la lectura sin el daño visual de pantallas tradicionales. Esto fija un requisito técnico: el contenido debe llegar al dispositivo en formato compatible, idealmente PDF.

¿Cómo analizar el problema con la técnica de los seis sombreros?

Antes de saltar a soluciones, Nicolás aplica los seis sombreros para pensar y revisa el problema desde distintos ángulos [03:00].

• Sombrero azul, el del proceso: el flujo va desde que se encuentra la información hasta que se consume.
• Sombrero blanco, el de los hechos: no se cambian las herramientas, hay información histórica acumulada y se desea enriquecer datos con etiquetas automáticas.
• Sombrero rojo, el de los sentimientos: hay frustración por coleccionar mucho y consumir poco, y satisfacción potencial si un sistema lo resuelve.
• Sombrero negro, el de las dificultades: dos retos de integración, con Telegram y con Remarkable, más preguntas abiertas sobre descubrimiento y enriquecimiento.
• Sombrero amarillo, el de los beneficios: aprovechar el insomnio para leer y reemplazar el scrolling infinito por lectura con valor.
• Sombrero verde, el de la creatividad: reemplazar todo con Pocket, etiquetar artículos automáticamente o generar un resumen semanal.

Esta exploración deja insumos suficientes para tener una conversación de calidad con un par o con un modelo de IA.

¿Cómo priorizar funcionalidades antes de diseñar el MVP?

Con el análisis listo, llega el momento de priorizar usando la matriz de urgente e importante [06:30]. Nicolás define cuatro niveles claros para su primer ciclo de desarrollo.

1. Importante y urgente: reemplazar la transferencia manual de datos entre Telegram y Remarkable.
2. Importante pero no urgente: mejorar el mecanismo de búsqueda, ya que Telegram y Remarkable cubren lo básico.
3. Urgente pero no importante: desplegar algo rápido, que pesa menos que aprender a mejorar el flujo.
4. Ni urgente ni importante: agregar notas o comentarios al contenido encontrado.

Esta priorización funciona como filtro para descartar lo que distrae y proteger el alcance del MVP.

¿Qué es un MVP en arquitectura de software? Es un producto mínimo viable, la versión más pequeña que entrega valor real al usuario y permite validar decisiones técnicas antes de escalar.

¿Qué propone la IA como MVP y cómo se modela con C4?

Apoyado en un modelo de IA, Nicolás obtiene un caso de uso y cuatro historias de usuario centradas en enviar información, buscar lo encontrado antes y convertir contenido no textual a formatos compatibles con su lector [07:30].

¿Qué contenedores propone la IA en el primer MVP?

La primera versión sugerida tiene cuatro piezas que se diagraman con el modelo C4, útil para visualizar sistemas, contenedores y componentes.

• Un bot o API de integración con Telegram.
• Una base de datos para guardar y administrar los enlaces.
• Una interfaz web sencilla para gestionar el contenido.
• Un componente que convierte archivos no textuales a PDF y los envía a Remarkable.

En el diagrama hay un solo actor, Nicolás en su rol de lector, y dos subsistemas: la integración con Telegram y la integración con el conversor más Remarkable.

¿Cómo se simplifica el MVP usando integraciones nativas?

Nicolás reduce el alcance aprovechando que Remarkable se integra de forma nativa y bidireccional con sistemas como Google Drive o Dropbox [10:00]. Así, el bot de Telegram solo necesita enviar a esos servicios estandarizados, no directamente al dispositivo.

El diagrama queda con un solo subsistema y una dependencia externa estandarizada. Esto da flexibilidad y simplifica decisiones futuras.

¿Cómo comparar alternativas de arquitectura para elegir bien?

La evaluación final pone tres opciones sobre la mesa [11:00]:

• Sistema externo tipo Pocket: descartado por restricción del cliente.
• MVP propuesto por la IA: cuatro contenedores, cuatro integraciones, varios puntos de seguridad y costo de construcción y operación más alto.
• MVP simplificado con Drive o Dropbox: menos contenedores, menos puntos de falla y menor costo operativo.

Cada alternativa implica decisiones distintas sobre autenticación, transmisión de información y costos de operación. ¿Cuál defenderías como MVP? ¿Qué requisitos no funcionales tendrías en cuenta? ¿Cuál es más fácil de extender cuando el problema crezca?

Deja en los comentarios qué arquitectura elegirías y por qué.