Cómo una herramienta boutique se mantiene confiable
Se supone que los equipos pequeños lanzan rápido y rompen cosas. Nosotros elegimos el trato opuesto. Aquí está el porqué, y lo que nos cuesta.
Una pregunta razonable que nos hace cualquiera que evalúa un producto pequeño: ¿de verdad se le puede confiar a un equipo pequeño los datos que mueven mi firma?
Es una pregunta justa. Economía de comisiones, reconocimiento de ingresos, requisitos de clientes. Estos no son datos de juego. Si la herramienta se rompe, se rompe dinero real con ella.
El trato por defecto de un producto pequeño
Moverse rápido. Lanzar todos los días. Disculparse cuando algo se rompe, arreglarlo, seguir adelante. Ese trato es racional para apps de consumo e irracional para software que maneja el dinero de una firma.
Así que hicimos el trato opuesto. Más lento de lo que podríamos avanzar. Menos superficie de la que quisiéramos. Más cobertura de pruebas de la normal para un equipo de nuestro tamaño.
Cómo se ve eso en la práctica
- 1781 pruebas automatizadas. No es un número de vanidad, es un contrato. La suite de pruebas corre con cada cambio, y no lanzamos si alguna falla. La mayoría de las pruebas son sobre dinero: cálculo de comisiones, reconocimiento de ingresos por modelo, lógica de snapshots, acumulados de facturas.
- Cero errores de implicit-any en TypeScript en el código de producción. Tipado estricto en todo el sistema. La clase de bugs que ocurren porque un campo tenía la forma equivocada, esa clase entera está cerrada.
- Una revisión arquitectónica en cada cambio significativo. No una lista de verificación. Una lectura de un segundo ingeniero con la autoridad de decir “no, así no lo hacemos”. Más lento que un pulgar arriba. Atrapa lo que un pulgar arriba no.
- La IA está acotada a dos superficies, y la matemática del dinero no es una de ellas. Usamos Claude en exactamente dos lugares. Sage es un asistente de ayuda que responde desde nuestros propios artículos de ayuda, el Manual de Usuario y el Catálogo de Funciones, y cita la fuente. El convertidor de DRD a FRD propone filas estructuradas de requisitos funcionales para que un solutions engineer las revise y apruebe. Los prompts del sistema no pasan ningún dato del negocio al modelo. Ni un registro de trato, ni una comisión, ni un número de margen, ni un asiento contable.
- La matemática del dinero es determinista y está balanceada por construcción. Cada cálculo de comisión, cada asiento de reconocimiento de ingresos, cada asiento contable enviado a QuickBooks pasa por reglas que podemos explicar. Los asientos de reconocimiento se verifican con débito igual a crédito antes de ser persistidos; un asiento desbalanceado no puede existir, ni siquiera como borrador. Ningún modelo aconseja sobre un número que llega a tus libros.
Lo que cuesta
Es más lento. Cada función toma más tiempo del que tomaría en un equipo que “se mueve rápido”. Hay semanas en que el roadmap parece que no avanzó nada.
Creemos que ese es el costo correcto. El producto es de esos donde un bug silencioso en un pedazo de matemática es peor que una función faltante. Una función faltante es una solicitud. Un bug silencioso es un trato perdido.
Lo que queremos que signifique
Si estás evaluando PartnerView y la objeción en tu cabeza es “son demasiado pequeños para confiarles esto”, la respuesta no es que no somos pequeños. La respuesta es que sabemos exactamente qué tipo de producto es este, y no lo manejamos como una app de consumo de cinco personas.
Una herramienta boutique puede ser una herramienta de alta calidad. Estamos esforzándonos mucho por demostrarlo.