La app que dejé de desarrollar

Tengo miedo a las alturas, y no es un miedo leve.

Hago senderismo. Llevo años haciéndolo, y me gusta más que casi cualquier otra cosa que hago durante un fin de semana libre. Y en algún momento esas dos cosas dejaron de ser compatibles, porque una montaña es exactamente el lugar donde sentirse cómodo con tu propio cuerpo importa más, y yo no me sentía cómodo.

Así que construí algo para mí.

Kleos Breathe era una aplicación de respiración guiada. La idea era deliberadamente limitada. Cuando estás en un lugar que parece demasiado alto, no estás buscando una biblioteca de meditación ni vas a ponerte a leer. Necesitas algo que te diga que respires, que te explique qué está pasando en tu cuerpo y que no te pida nada.

Era una aplicación pequeña. Hacía una sola cosa. Funcionaba.

Y durante todo su periodo de pruebas cerradas, prácticamente no hubo interacción. No fue una cifra decepcionante. Fue casi nada. Muy pocos comentarios, muy poco uso y muy pocas señales de que hubiera conectado con alguien.

Un día empecé a mirar los resultados de las pruebas de otra manera.

El problema no era un error. Las personas que la estaban probando simplemente no necesitaban una guía de respiración.

Eso era más difícil de solucionar que un error, porque no había nada en el código que estuviera pidiendo ser arreglado.

Por qué era demasiado genérica

El problema no era que respirar no sirviera. Era que había construido una solución para mi propio problema y después la había presentado al mundo como un producto general.

Una aplicación de respiración no es una idea nueva. Hay miles. Mi versión podía estar bien hecha y funcionar correctamente y, aun así, no tener ningún motivo para que un desconocido la eligiera, porque yo no le había dado una razón para escoger esta.

Lo que realmente había construido era una solución para algo específico y personal.

A mí me resultaba útil. Eso no significaba automáticamente que fuera útil para todos los demás.

El fracaso incómodo

Un fallo habría sido un regalo.

Un fallo tiene un stack trace, un modelo de dispositivo, un camino para reproducirlo y un lugar evidente del código donde algo salió mal. Se convierte directamente en trabajo, y el trabajo da la sensación de progreso.

Que nadie vuelva no se siente como nada. No tiene stack trace, no se puede reproducir y sobrevive a cualquier prueba unitaria que pueda escribir, porque no hay nada incorrecto en el código.

Te dice que el problema no es técnico, y los problemas técnicos son los problemas que sé tener.

Esta fue la parte que más tardé en aceptar. Seguí buscando una razón que me permitiera continuar desarrollándola, y la razón que quería encontrar era un error.

Nunca iba a haber uno.

Lo que realmente aprendí

No reconstruí Breathe.

La decisión se volvió mucho más fácil cuando dejé de buscar una explicación técnica que no existía.

Lo extraño es que los comentarios que sí recibimos sobre la aplicación fueron positivos. El onboarding funcionaba bien, la experiencia era clara y no había ningún problema evidente de UX que explicara la falta de uso.

La aplicación podía ser buena y, aun así, no ser necesaria.

Esa distinción cambió mi forma de pensar sobre el desarrollo de aplicaciones.

Es muy fácil preguntarse si una idea se puede construir. Es mucho más difícil preguntarse si alguien tiene una razón para utilizarla.

Breathe respondió a esa pregunta por mí.

La construí porque tenía un problema concreto. La probé con personas que no tenían ese problema. Y entonces aprendí que mejorar la solución no iba a hacer que apareciera el problema.

Sigo pensando que la aplicación era buena. Simplemente no creo que eso importe demasiado.

La distancia entre una aplicación que resuelve por completo mi problema y una aplicación que nadie más necesita es lo más útil que ese proyecto me ha enseñado.

A veces, dejar de desarrollar también es una decisión de producto.