Construí una app para acordarme de mi propio trabajo

Un cliente me preguntó qué había hecho para ellos el mes anterior.

Es una pregunta razonable. Llevaba semanas trabajando en eso. Y me quedé mirando la pantalla intentando reconstruirlo desde los commits, el historial de Slack y los tickets cerrados, como un arqueólogo de mi propio mes. Tardé casi una hora en armar una respuesta de cinco líneas que además no estaba seguro de que fuera completa.

No es que tenga mala memoria. Es que nunca escribí nada.

Dónde vive realmente el contexto

Si trabajas en software, la información de lo que haces está repartida más o menos así:

El ticket dice qué te pidieron. El PR dice qué código cambió. Slack tiene la conversación donde se decidió algo, enterrada en un hilo de hace tres semanas. Tu editor tiene una rama con un nombre que ya no recuerdas por qué elegiste. Y el resto — por qué descartaste la otra opción, a quién le estás esperando, qué te bloqueó dos días — está en tu cabeza, que es exactamente el sitio del que se va.

Cada herramienta guarda un fragmento y ninguna guarda la historia. El ticket sabe que se cerró, no sabe que lo cerraste a la mitad porque el equipo de datos cambió el esquema y hubo que rehacerlo.

Y entonces, semanas después, preguntas que deberían ser triviales resultan sorprendentemente caras:

¿En qué estuve ayer?
¿Qué pasó con este ticket?
¿Por qué tomamos esta decisión?
¿Qué estoy esperando?
¿Qué hice para este cliente el mes pasado?
¿Qué digo mañana en el standup?

Ninguna requiere inteligencia. Todas requieren un registro que no existía.

Por qué un gestor de tareas no lo arregla

Mi primer instinto fue el de todo el mundo: esto se arregla con listas. Y probé unas cuantas.

Empecé con Todoist, que es excelente en lo suyo: me dice qué tengo que hacer hoy y me lo recuerda hasta que lo hago. Pero cuando terminaba algo lo tachaba y desaparecía. Al mes siguiente la lista estaba impecable y yo seguía sin poder decir qué había hecho.

Después ClickUp, que es el problema contrario: hace de todo. Estados, sprints, campos personalizados, vistas, automatizaciones. Terminé dedicándole más tiempo a configurar el sistema que a registrar trabajo, y un registro que cuesta mantener se abandona en la primera semana ocupada.

El problema es que un gestor de tareas modela el futuro. Es una lista de cosas que voy a hacer. Lo que yo perdía era el pasado: lo que pasó, y por qué.

Son cosas distintas y se comportan distinto. Una lista de pendientes hay que mantenerla — mover items, actualizar estados, limpiar lo viejo — y esa es una segunda ocupación además del trabajo. Un registro de lo que pasó no se mantiene. Se escribe una vez y ya está.

Hay un detalle que me tomó tiempo entender y que terminó siendo el principio del producto entero:

“Pendiente: revisar el PR de Aurora” es un estado. Hay que actualizarlo, y si no lo haces, miente.

“Aurora me pidió revisar su PR” es un hecho. Fue verdad cuando lo escribí y va a seguir siendo verdad dentro de tres años.

Lo que yo necesitaba era lo segundo. Escribir hechos y dejar que lo demás — qué sigue abierto, qué pasó esta semana, en qué ando — se calcule solo a partir de ellos.

Notion fue el que más cerca estuvo. Es lo bastante flexible para modelar exactamente esto, y ahí sí escribí durante una buena temporada. Su problema no era la forma sino el sitio: vive en la nube, en servidores de otra gente. Y ese fue el que me sacó de ahí.

Por qué archivos de texto en una carpeta mía

Esta parte no la decidí por elegancia técnica. La decidí por desconfianza.

Llevo casi veinte años en esto y he visto morir suficientes herramientas. Servicios que cierran, formatos que se vuelven ilegibles, exportaciones que técnicamente existen y en la práctica te devuelven un JSON que nadie puede leer. Un registro de trabajo tiene que sobrevivir a la aplicación que lo escribe, o no sirve para lo único que tiene que servir: acordarse de cosas viejas.

Así que el registro son archivos Markdown en una carpeta mía. Un archivo por proyecto. Se leen en cualquier editor, se versionan con Git, se buscan con grep, se copian a un USB y se archivan. Si mañana borro la app, el registro sigue ahí y sigue teniendo sentido.

Hay además una razón menos filosófica: esos archivos tienen nombres de clientes y decisiones internas. No quiero subirlos a un servicio ajeno, y no quiero tener que confiar en la política de privacidad de nadie. Que no salgan de mi Mac no es una funcionalidad, es la condición.

Entonces, ¿para qué una app?

Es la pregunta justa, porque durante un tiempo yo tenía los archivos y nada más. Escribía a mano, en Markdown, y funcionaba para escribir.

Dejaba de funcionar para leer.

Con veintisiete proyectos y cientos de eventos, un montón de Markdown plano no te responde qué quedó abierto en todos los proyectos a la vez, ni qué hiciste para un cliente en un rango de fechas, ni cuáles llevan tres semanas en silencio. Esa información está en los archivos, pero está dispersa en cincuenta sitios y leerla a mano cuesta más de lo que vale.

Así que la app no es dueña de nada. Es un lector. Muestra la línea de tiempo día a día, deriva lo que sigue abierto, arma el resumen del último día trabajado, cuenta actividad por semana y busca sobre todo el historial.

Y escribe, sí, pero con reglas estrictas que vienen de la misma desconfianza de antes: solo añade, nunca reescribe líneas que no escribió, rechaza cualquier escritura que no pueda volver a leer, y si edito un archivo a mano desde el editor, se entera sola y se actualiza. Editar el Markdown por fuera no es un caso raro que la app tolera. Es una forma normal de usarla.

Lo que decidí no construir

Esto es la mitad del producto, y quizá la mitad más importante.

Prioridades automáticas. Iba a deducirlas del texto con un modelo local. Lo medí antes de construirlo y el acuerdo con mi propio criterio fue cero — lo conté con los números en La prioridad nunca estuvo en el texto. La función se cayó ahí.

Un editor de Markdown dentro de la app. Poder editar los archivos por fuera es una capacidad del producto, no un hueco que tapar. Si meto un editor, empiezo a competir con el tuyo y termino siendo dueño de los archivos. La app abre el archivo en el editor que ya usas.

Borrar eventos. El registro es append-only a propósito. Es la única operación que no se puede deshacer volviendo a leer el archivo, y un registro que se puede reescribir sin dejar rastro no es memoria, es una opinión actual sobre el pasado.

IA, por ahora. Va a llegar, pero como interfaz para preguntar sobre datos que ya son confiables. No como fuente de hechos que nadie escribió. Esa distinción es justamente lo que midió el otro post.

¿Sirve esto para alguien más?

No lo sé, honestamente.

La construí para mí, resuelve un problema que yo tengo de forma bastante específica, y va por la versión 0.2. Es perfectamente posible que a ti te sobre con un archivo de notas, o que tu empresa ya tenga el proceso resuelto, o que sencillamente no te haga falta.

La prueba real no es si te gusta la captura de pantalla. Es si yo la sigo usando dentro de seis meses, cuando deje de ser un proyecto nuevo y sea solo una cosa más que hay que abrir. Ahí se verá si el hábito se sostiene, que es lo único que hace útil a un registro de trabajo.

Por ahora lo que puedo decir es que la pregunta del cliente ya no me cuesta una hora.

Noonly es para macOS, guarda todo en Markdown que es tuyo y no manda nada a ningún lado. Está en infante.io/noonly.