CASO DE ESTUDIO · BRIEFLINE · 2026
De un brief ambiguo a un producto verificable.
Una pequeña agencia gestiona el trabajo de sus clientes en hojas de cálculo y chat. El brief pedía "una herramienta de tareas sencilla". Convertí eso en un producto con límites definidos y después produje la evidencia de que se comporta como se describe.
Contexto y audiencia
Briefline está pensado para agencias de tres a quince personas: un dueño que necesita saber qué va con retraso, gestores de cuenta que hablan con los clientes, y freelancers que solo deben ver su propio trabajo.
El trabajo por hacer no es "gestionar tareas". Es responder, en una sola pantalla, qué está bloqueado, quién es responsable y qué se le prometió al cliente.
Restricciones que fijé
- Un equipo, un espacio de trabajo — sin facturación multi-tenant en v1
- Roles limitados a propietario, gestor y colaborador
- Sin colaboración en tiempo real; conflictos resueltos al escribir
- Los datos de demo deben ser ficticios y reiniciarse cada día
Las decisiones que dieron forma al sistema
El contrato va primero
La API se describe en OpenAPI 3.1 antes de implementarla. Los tipos del cliente, la validación del servidor y los tests de integración se generan a partir de ese documento o se verifican contra él, así que un cambio incompatible se ve en la revisión, no en producción.
PATCH /tasks/{id}
If-Match: obligatorio
200 → tarea actualizada + nueva versión
409 → estado actual del servidor + campos cambiados
403 → permiso denegado, sin escritura parcialLos permisos viven en el servidor
La interfaz oculta lo que no puedes hacer, pero cada regla se vuelve a aplicar en la API y está cubierta por tests. Un colaborador que adivina una URL recibe un 403, no una sorpresa.
Una actualización obsoleta nunca gana en silencio
Cada cambio se versiona y se escribe de forma atómica junto a su entrada de historial. Si dos personas editan la misma tarea, la petición más tardía se rechaza con el estado actual, así la interfaz puede mostrar lo que realmente pasó en vez de sobrescribir a un compañero.
Los estados que la mayoría de herramientas posponen
Vacío, cargando, denegado, en conflicto y sin conexión se diseñaron junto al camino feliz, no después. El foco de teclado es visible en cada elemento interactivo y se revisó a mano, no solo con una auditoría automática.
El objetivo de accesibilidad es WCAG 2.2 AA: encabezados secuenciales, campos de formulario etiquetados, errores asociados a su campo, y ninguna información transmitida solo por color.
Evidencia que puedes comprobar
Cifras del 12 de agosto de 2026. Los datos de demo son ficticios y se reinician cada día, así que la demo que abres se comporta igual que describen los tests.
203
tests unitarios
206
tests de integración sobre PostgreSQL
74
tests end-to-end con Playwright
AA
objetivo WCAG 2.2, revisado por teclado
Decisiones de compromiso y qué dejé fuera
- Concurrencia optimista en vez de sincronización en tiempo real — más simple de razonar, a costa de algún diálogo de conflicto ocasional.
- Sin constructor de workflows personalizados — cuatro estados cubren el caso de la agencia y mantienen útil el historial de auditoría.
- Listas renderizadas en servidor en vez de scroll infinito — rendimiento predecible y una URL que se puede compartir.
Resultado y qué cambiaría
El producto hace lo que dice este caso de estudio, y cada afirmación de esta página se corresponde con un test, un contrato o una pantalla que puedes abrir. Escribir el contrato primero fue la decisión que más tiempo ahorró.
La próxima vez invertiría antes en la experiencia de conflicto: el comportamiento de la API fue correcto desde el principio, pero la interfaz necesitó tres iteraciones para explicarlo en lenguaje llano.
¿Quieres el mismo rigor en tu producto?
Cuéntame qué está pasando, qué debería pasar en su lugar y qué has probado ya. Te responderé con el siguiente paso más útil.