Lo que de verdad cuesta una versión 2: 206 commits de estados honestos

La mayoría de los lanzamientos "versión 2" son un montón de funciones nuevas con un número más grande encima. La v2 de GeekBye fue lo contrario. Casi no aportó ninguna capacidad nueva de cara al usuario. Sus 206 commits apuntaban a una sola idea, poco vistosa:

La app nunca debe mostrarte un estado que no sea cierto.

Suena obvio hasta que cuentas de cuántas formas una app de escritorio miente en silencio. Muestra un tick en una subida que aún va en camino. Dice "conectado" sobre un socket que murió hace un minuto. Se queda callada mientras tu transcripción se pierde por el desagüe. Nada de esto son cierres. Son peores que los cierres, porque la app parece estar bien mientras se equivoca — y solo te enteras más tarde, cuando la grabación que necesitabas no está.

La v2 fue el lanzamiento en el que salimos a cazar cada una de esas pequeñas mentiras.

La mentira que más odiábamos: la subida que "funcionó"

GeekBye puede respaldar tus grabaciones en Google Drive. En la v1, la conexión con Drive se trataba como un detalle en segundo plano — si funcionaba, genial; si no, el fallo era casi invisible. La app seguía pareciendo conectada. Dabas por hecho que tus grabaciones estaban a salvo. A veces no lo estaban.

La v2 reconstruyó esto en torno a estados de conexión honestos. Drive está ahora siempre en uno de unos pocos estados explícitos y veraces — conectado, reconectando, desconectado — y la app difunde cada cambio de ese estado a toda la interfaz en el instante en que ocurre. Cuando la conexión está caída, un banner global de reconexión te lo dice, en todas partes, con claridad. La app ya no finge que una subida funcionó cuando no fue así. Si tu copia de seguridad no puede hacerse ahora mismo, lo sabes ahora mismo — no la semana que viene, cuando vayas a buscar el archivo.

Por debajo, esto es una pequeña arquitectura, no un eslogan: una única fuente de verdad para la conexión, un evento que se despliega hacia cada parte de la interfaz cuando cambia, y un banner que lee directamente de ese estado. No hay ningún camino en el que la conexión esté caída y la interfaz parezca estar activa, porque ambas leen del mismo hecho.

La mentira de la grabación perdida

El segundo gran arreglo de honestidad fue la recuperación de grabaciones. La transcripción en tiempo real necesita una conexión viva. En la v1, si esa conexión tenía un tropiezo a mitad de sesión — un parpadeo de Wi-Fi, un túnel, una reconexión de VPN — el audio durante ese hueco podía simplemente desaparecer. La transcripción tenía un agujero, y nada te avisaba.

La v2 cambió el contrato: el audio se conserva en local durante un corte de conexión y se reconcilia después. Cuando el enlace se cae, GeekBye mantiene el audio a salvo en tu máquina; cuando vuelve, ese audio en búfer se envía y se cose a la transcripción en el lugar correcto. Treinta segundos malos de red ya no te cuestan treinta segundos de reunión. Este es el cimiento sobre el que se construyeron directamente los lanzamientos de fiabilidad posteriores — la maquinaria de reconexión y búfer de por qué tu notetaker con IA se detiene con mal Wi-Fi es la misma idea, endurecida.

La mentira de la tormenta de popups

Hay una deshonestidad más sutil en cómo las apps reportan los problemas: los sobre-reportan. Un solo momento inestable de red puede disparar el mismo error cinco veces, y de repente tienes una pila de avisos rojos idénticos enterrando el único mensaje que importa. Eso tampoco es honesto — es ruido haciéndose pasar por información.

Así que la v2 añadió dosificación de avisos por categoría y enrutamiento de errores. Los errores se agrupan por lo que realmente son, y cada categoría se limita en frecuencia para que un único problema subyacente produzca un mensaje claro, no una descarga. Un problema de límite de tasa se enruta a un mensaje de límite de tasa; un problema de conexión se enruta a un mensaje de conexión. La app te dice qué es cierto, una vez — la misma disciplina que después impidió que un 429 se hiciera pasar por un cierre de sesión en el día que nuestra app se hizo DDoS a sí misma.

El número 206 es lo importante

Estados honestos, banner de reconexión, recuperación de grabaciones, enrutamiento de avisos — eso son cuatro ideas. El lanzamiento fueron 206 commits. ¿A dónde fue el resto?

A la larga cola poco vistosa que realmente exige "nunca mostrar un estado falso". Cada lugar donde la vieja interfaz podía desincronizarse de la realidad tuvo que encontrarse y recablearse para leer de la verdad en vez de de una copia rancia. Cada ruta de reconexión tuvo que hacerse actualizar el estado compartido en vez de adivinar en local. Docenas de pequeños arreglos de fiabilidad a lo largo de grabación, transcripción y subidas — cada uno cerrando un hueco concreto donde la app podía parecer correcta mientras se equivocaba.

Esto es lo que cuesta una "versión 2" de verdad cuando el objetivo es la confianza en vez de las funciones. No hay un único commit protagonista. Hay 206 pequeños, y el lanzamiento solo se siente como una sola cosa — calma — porque los 206 tiran en la misma dirección.

El lanzamiento casi no sale

Aquí está la batallita, y es buena, porque va sobre nuestra propia app mintiéndonos a nosotros.

Cuando cortas un lanzamiento, un script de cambio de versión estampa el número nuevo por todo el proyecto. En la v2.0.0 actualizó la versión de la app — pero el package-lock.json, el registro exacto de dependencias de npm, se quedó apuntando a la versión antigua, 1.9.0. En local, todo iba bien; nadie reinstala dependencias solo para compilar. Pero CI ejecuta npm ci, y el trabajo entero de npm ci es negarse a continuar si el lockfile no concuerda con el manifiesto. Es una función de rigor — e hizo exactamente lo que debía, fallando la compilación del lanzamiento más grande que jamás habíamos cortado.

Luego un segundo, más traicionero, asomó por debajo. Un npm más nuevo había podado una dependencia transitiva opcional — el paquete encoding que arrastra node-fetch — del lockfile por considerarla innecesaria. Salvo que la instalación limpia de nuestro CI sí la necesitaba, así que la instalación se rompió de una forma que no tenía nada que ver con nuestro código y todo que ver con el registro estando sutilmente equivocado.

Ambos eran arreglos de una línea: resincronizar el lockfile a la versión real, restaurar la entrada podada. Ambos son también ejemplos perfectos y humillantes de justo aquello de lo que iba la v2 — un estado que decía ser cierto y no lo era. Se supone que el lockfile es el registro honesto de lo que la app depende. Cuando derivó de la realidad, la compilación hizo exactamente lo que nuestra app hace ahora por los usuarios: se negó a fingir que todo iba bien. Lanzar un lanzamiento de fiabilidad resulta ser un problema de fiabilidad hasta el fondo.

Tres cosas que nos enseñó la v2

1. Los fallos peligrosos son los silenciosos. Un cierre se anuncia a sí mismo. Un falso "conectado", una subida exitosa fantasma, una transcripción con un agujero invisible — esos te cuestan confianza precisamente porque nada parece ir mal. Caza las mentiras silenciosas.
2. La honestidad es una arquitectura, no un mensaje. No puedes atornillar "di la verdad" a una interfaz como un banner. El banner tiene que leer de la misma única fuente de verdad que todo lo demás, o se convierte en una cosa más que puede estar equivocada. Un hecho, desplegado — nunca dos copias que puedan discrepar.
3. Una versión 2 que merezca el número es en su mayoría invisible. Si tu v2 es una lista de funciones, es una v1.5 con marketing. Una v2 de verdad son 206 commits que nadie puede señalar individualmente, sumando un producto que simplemente deja de mentirte.

La v2.0.0 de GeekBye es el cimiento sobre el que ha construido cada lanzamiento desde entonces. Para lo que ese cimiento sostiene, mira por qué tu notetaker con IA se detiene con mal Wi-Fi, el día que nuestra app se hizo DDoS a sí misma (v2.0.1) y transcripción en directo cuando el firewall bloquea los WebSockets (v2.0.8). Para la calma al servicio de la cual estuvo todo, las novedades de GeekBye v2.