Herramienta interna · En producción ·
Timetry
El sistema de control de horas del estudio. Lo construimos porque ninguna herramienta del mercado entendía cómo facturamos realmente.
Timetry es la herramienta interna de control de tiempo de Truman Digital, construida porque ninguna solución del mercado entendía cómo factura realmente un estudio que vende paquetes de horas. Gestiona los paquetes contratados por cliente con consumo FIFO cronológico —sin asignación manual, el sistema infiere a qué paquete va cada hora—, respeta la fecha de inicio de cada paquete para no imputar trabajo anterior a su contratación, y avisa automáticamente al alcanzar el 80 % de consumo para convertir una conversación incómoda en una previsible. Su API está diseñada para devolver respuestas y no tablas, de modo que un agente de IA pueda consultarla sin conocer el modelo de datos. Está en producción sobre varios espacios de trabajo.
El problema
Vendemos paquetes de horas: el cliente contrata 50 horas y las consume a su ritmo, en los proyectos que quiera. Suena trivial hasta que intentas responder a la pregunta "¿cuántas horas me quedan?" con una herramienta genérica.
Porque la respuesta correcta depende de cosas que ninguna herramienta modela: qué paquete estaba activo cuando se hizo ese trabajo, si el paquete tenía fecha de inicio, qué pasa cuando un cliente compra el siguiente antes de agotar el anterior.
Las tres decisiones que lo definen
1. Consumo FIFO cronológico, sin asignación manual
La tentación es dejar que alguien asigne cada hora a un paquete. Es un error: nadie lo hace bien y todo el mundo lo pospone. Timetry no pregunta — infiere. Las horas de un cliente se imputan al paquete más antiguo con saldo, en orden cronológico, hasta agotarlo. Cero decisiones manuales, cero discusiones a fin de mes.
2. Los paquetes tienen fecha de inicio, no solo saldo
Un paquete no debe consumir trabajo anterior a su contratación. Parece obvio y es la fuente de la mitad de los errores de facturación: cada paquete arranca en una fecha concreta y solo cuenta lo que pasó a partir de ahí.
3. El aviso automático al 80 %
El dato importante no es el saldo: es el momento en que hay que hablar con el cliente. Cuando un paquete llega al 80 % consumido, salta el aviso. Eso convierte una conversación incómoda ("te has pasado") en una previsible ("te quedan diez horas, ¿renovamos?").
Diseñado para que lo lea una IA
La decisión de la que más contento estoy: la API no devuelve solo datos crudos, devuelve la respuesta. Un endpoint acepta el nombre parcial de un cliente y contesta con el paquete activo, lo consumido, lo restante y el estado — ok, warning, exhausted o exceeded.
Eso permite que un agente de IA responda "¿cuánto le queda a este cliente?" sin necesidad de saber nada del modelo de datos. Es una idea que nos hemos llevado a todo lo que construimos en Seahaven: si el dato lo va a consumir un agente, la API debe hablar en respuestas, no en tablas.
Por qué cuento esto
Porque es el tipo de herramienta que no aparece en ningún portfolio: no es bonita, no la ve ningún cliente y no se vende. Pero es la que hace que un estudio pequeño pueda facturar bien sin dedicar días a cuadrar hojas de cálculo. Casi todo lo que hemos acabado convirtiendo en producto empezó siendo algo así.