Ship-a-ton 2026: Build Log #4 — De las pantallas a las descargas

A esta altura del Shipaton, teníamos una idea más aterrizada de BRBito: sabíamos cómo debía funcionar el onboarding, cómo queríamos manejar los recordatorios, qué debía mostrar Home, cómo alguien podía iniciar una pausa y qué debía pasar cuando terminara.

Sin embargo, cuando llega el momento de construir estas soluciones, este tipo de productos digitales que desde afuera parecen una secuencia de pantallas, realmente se convierten en colecciones de estados, permisos, preferencias guardadas, diferencias entre plataformas, bugs y decisiones sobre qué debe pasar cuando las cosas no van saliendo tal como se esperaría.

En esta ocasión quisimos experimentar y nos saltamos la etapa de prototipado tradicional y detallado usando Figma / Affinity, realizada en otras oportunidades para otros proyectos web / desktop. Muchas de las pantallas surgieron a partir de modelos visuales generados con IA, exploraciones en Miro y especificaciones descriptivas del UI respecto a qué debía aparecer, qué contenido necesitábamos, cómo debía comportarse una pantalla, etc.

Aunque esa decisión nos permitió explorar y encontrar ideas muchísimo más rápido, también significó que al momento de desarrollar no teníamos necesariamente componentes perfectamente definidos, medidas consistentes, variantes documentadas o un design system listo para implementar, así que muchas decisiones que normalmente se resolverían antes de escribir código terminaron resolviéndose mientras construíamos: una app no es solo lo que aparece en pantalla, también es su construcción a partir de las reglas, los datos y la interfaz que hacen posible que todo lo demás funcione.

Esta etapa ha sido, sobre todo, el proceso de convertir el BRBito que imaginamos en el BRBito más pequeño que realmente podíamos lanzar.

Lo que realmente llegó a v0.1

Inicialmente soñabamos con salir en la primera versión con varios compañeros virtuales, accesorios, distintos entornos, más familias de pausa, más actividades y una personalización mucho más profunda. Pero notamos que la experiencia central y lo que necesitabamos sacar para el primer MVP era mucho más simple: ¿Puede alguien configurar BRBito, recibir un recordatorio, hacer una pausa corta y volver a su día sin fricción innecesaria?

Para poder llegar a la meta del Shipaton, tuvimos que seguir descartando funciones y decidimos priorizar onboarding, preferencias de recordatorios, notificaciones locales, pausas manuales, timer, estados de finalización, ajustes básicos y soporte en español e inglés. BRBito tendría un solo compañero virtual, un entorno principal, tres familias de pausa y una actividad por cada una. Aunque eso a corto plazo pudiera hacer que la experiencia se sienta algo repetitiva, para nosotros era fundamental asegurarnos de que el flujo principal realmente fuera funcional.

La parte más difícil no fue decidir lo que iría en las pantallas

De los mayores retos que hemos tenido ha sido mantener sincronizado todo el ciclo de una pausa. Queriamos que las personas tuvieran el control y pudieran recibir un recordatorio, ignorarlo, abrir la app más tarde, iniciar una pausa manualmente, salir de la app, volver, terminar antes de tiempo o cambiar la configuración de sus recordatorios. Y en medio de todo eso, BRBito tenia que recordar qué ocurrió y mostrar lo correcto después. El reto terminó siendo mantener alineadas tres cosas:

lo que hizo la persona → lo que BRBito guardó → lo que BRBito muestra

Suena sencillo hasta que la app se cierra, vuelve a abrirse, queda en segundo plano o cambia la programación de notificaciones, y aún cuando la lógica funciona correctamente, lograr que cada pantalla realmente se comporte y se vea como la imaginabamos necesitó varias rondas de implementación, pruebas y ajustes. Una pantalla podía verse clara en una exploración visual, pero al construirla aparecían preguntas que el prototipo no necesariamente respondía:

• ¿qué pasa si el texto ocupa dos líneas más?
• ¿qué tamaño mínimo tiene este componente?
• ¿qué ocurre si una opción está deshabilitada?
• ¿cómo se comporta en una pantalla más pequeña?
• ¿qué elementos realmente son reutilizables?
• ¿qué cambia entre estados?
• ¿qué debería ser un componente y qué debería ser simplemente contenido?

Pasamos de diseñar cómo se veía una pantalla a diseñar cómo se comportaba un sistema.

BRBito recuerda información de forma local

Para esta primera versión, quisimos que BRBito funcionara sin pedirle a las personas que crearan una cuenta. Nuestra hipotesis era que esa decisión podría reducir la fricción durante el onboarding, evitando recopilar datos innecesarios y permitiendo que la experiencia principal funcionara sin conexión a internet. A su vez, eso nos evitó tener que construir autenticación, perfiles, sincronización e infraestructura de backend que no eran esenciales para el MVP.

Usando MMKV (Multi-Process Key-Value), BRBito guarda directamente en el dispositivo las preferencias y el estado de las pausas: idioma, nombre, días activos, horarios de recordatorios, frecuencia, tipos de pausa preferidos y el estado de la pausa actual. Cuando la app vuelve a abrirse, esa información se recupera antes de mostrar la interfaz, y así la experiencia puede continuar sin pedirle a la persona que configure todo de nuevo.

Los recordatorios hicieron que BRBito empezara a sentirse real

Quisimos que BRBito utilizara notificaciones locales según el horario que cada persona pudiera elegir. Calculamos los momentos de los recordatorios, los programamos en el dispositivo y los actualizamos en caso de que el usuario cambie sus días, horarios, frecuencia, idioma o preferencias de notificaciones.

También consideramos integrar OneSignal para notificaciones push remotas, pero vimos que requería más tiempo de implementación y pruebas del que teníamos disponible. Como las notificaciones locales ya cubrían el flujo principal, decidimos dejar esa integración para una versión futura.

Para Mike, llegar al primer recordatorio a la hora correcta fue uno de esos momentos en los que BRBito dejó de sentirse como un conjunto de pantallas y empezó a sentirse como un producto real. Para Gia, fue el poder abrir la app en su propio celular después de semanas de trabajo y ver que finalmente todas las piezas se comportaban como se quería.

Una sola base de código, dos plataformas

Estamos construyendo BRBito con React Native y Expo, compartiendo la mayor parte del código entre iOS y Android, y aunque tener una base de código compartida ayuda muchísimo, la experiencia final todavía necesita atención específica por plataforma. Encontramos diferencias en selectores de hora, comportamiento del teclado, espaciados, iconos, controles de navegación y permisos de notificaciones. En frontend, particularmente, uno de los mayores retos ha sido lograr que la misma composición se sienta clara en diferentes celulares: Imágenes, espaciados, cards y botones que se veían bien en un dispositivo podían necesitar ajustes en otro.

El pixel art también nos trajo problemas técnicos

Nuestra implementación visual inicial duplicaba algunos fondos y elementos de interfaz entre distintas pantallas, lo que hacía que la app fuera más pesada y más difícil de mantener. El cambiar la arquitectura para separar el fondo y el compañero virtual en capas diferentes, nos permitió reutilizar escenarios mientras el sprite de los personajes también podría cambiar de forma independiente. Eso nos dio mucha más flexibilidad para tener distintas poses, ambientes y futuras opciones de personalización sin tener que reconstruir escenas completas.

Otro de nuestros bugs más útiles apareció con la tipografía. La fuente con estilo pixel se veía bien en iPhone, pero en pantallas Android más pequeñas —especialmente con tamaños de texto de accesibilidad más grandes— algunos mensajes dejaron de caber dentro de sus globos. Eso nos obligó a replantear tanto la tipografía como la flexibilidad del componente, reforzando una idea importante:

Una decisión visual no termina cuando se ve bien en un prototipo. Tiene que sobrevivir contenido real, dispositivos reales y configuraciones reales.

En nuestro caso, eso fue todavía más evidente porque muchos de esos prototipos no habían llegado al nivel de detalle de un sistema de diseño completo. No tuvimos tiempo para definir cada token, variante o componente antes de empezar a desarrollar, así que varias reglas visuales terminaron consolidándose durante la implementación. Quizás no fue proceso ideal, pero sí fue una consecuencia directa de construir bajo las restricciones del Ship-a-ton.

El stack detrás de BRBito

Nuestro stack actual es relativamente pequeño:

• React Native + Expo — iOS y Android desde una base de código compartida
• Expo Router — navegación
• TypeScript — integración más segura entre datos y componentes
• MMKV — preferencias locales y estado de las pausas
• Expo Notifications — recordatorios locales
• i18next — español e inglés
• Firebase — analítica, diagnósticos y errores

También estamos integrando RevenueCat, pero hablaremos de la monetización en nuestro próximo Build Log.

Tener la app funcionando es distinto a estar listos para lanzarla

Otra sorpresa fue descubrir cuánto trabajo existe además de programar la app. App Store Connect y Play Console nos pidieron descripciones, screenshots, información de privacidad, páginas web de soporte, configuración de releases, pruebas y otros materiales específicos de cada tienda.

Para nuestro proceso de publicación en Android también tuvimos que contemplar un periodo de pruebas de catorce días con doce testers. En iOS enviamos una versión temprana y pasamos por varios intentos de revisión.

Si empezáramos de nuevo

• Dedicaríamos más tiempo desde el principio a una arquitectura de interfaz reutilizable y tendríamos aún más presente los tiempos de revisión de las tiendas desde el día uno.
• Separaríamos mejor reglas, datos, pantallas y assets para facilitar futuras iteraciones, y protegeríamos más el tiempo de implementación.
• Research, diseño, desarrollo, contenido, marketing y Build in Public ocurrieron al mismo tiempo, y aunque nos permitió vivir una experiencia mucho más completa de construcción de producto, también significó que todas esas cosas estaban compitiendo por las mismas seis semanas.

BRBito todavía no está “terminado”, pero su loop principal ya existe fuera de Miro: recuerda preferencias, programa recordatorios, puede recuperar una pausa activa, y, cada vez más, se comporta como el compañero virtual que imaginamos al principio, en lugar de sentirse como una colección de pantallas.

Actualmente, estamos integrando RevenueCat, experimentando con una pequeña capa de personalización visual de pago, y algunas decisiones interesantes sobre qué cosas deberían permanecer siempre gratuitas de las que hablaremos en nuestro próximo Blog.