Cómo construimos el sistema de cobros de Gnosis

Queríamos cobrar suscripciones mensuales. Pensábamos que era el paso más fácil del producto. Resultó ser el más educativo.

Esta es la historia de cómo armamos el módulo que permite a un abogado suscribirse a Gnosis con un click, y de por qué esa sencillez aparente nos obligó a poner en juego todo lo que entendemos por ingeniería responsable. La contamos porque creemos que la confianza en software jurídico no se gana con discursos. Se gana mostrando cómo se trabaja cuando nadie está mirando. Si vas a confiarle a una herramienta una parte del oficio que te define, tenés derecho a saber con qué disciplina la construimos.

El problema parecía trivial#

Necesitábamos que un cliente pueda decidir, desde su página de cuenta, suscribirse al plan que prefiera, pagar Gs. 99.000 o Gs. 249.000 al mes, y que la suscripción se renueve automáticamente sin que tenga que volver a ingresar datos. También necesitábamos que, si cancela, mantenga el acceso hasta que termine el mes ya pagado, y que después vuelva al plan gratuito sin sobresaltos.

Para vos como abogado, eso son cinco oraciones. Para nosotros como equipo, son decenas de decisiones técnicas, cada una con sus propios riesgos. ¿Qué pasa si el cliente paga dos veces el mismo día? ¿Qué pasa si cambia de plan a mitad de mes? ¿Qué pasa si el sistema entiende mal a quién corresponde el cobro? ¿Qué pasa si un día el aviso del pago no llega? Cada una de esas preguntas, mal respondida, puede convertirse en un reclamo, una doble facturación o un cliente que perdió acceso a herramientas que necesita para trabajar. En software jurídico, los detalles invisibles importan tanto como los visibles.

El obstáculo que nos hizo parar#

A los pocos días de empezar, descubrimos que el flujo de cobros recurrentes en Paraguay tiene una particularidad que no estaba documentada en ningún lugar accesible. La explicaremos en otro post con más detalle, pero el efecto práctico fue que el camino que pensábamos seguir requería que cada cliente diera un paso adicional que iba en contra de la simplicidad que prometimos.

Frente a eso teníamos dos opciones. Improvisar una solución rápida que ocultara el problema, o parar, entender lo que estaba pasando, y construir el sistema de manera que cuando esa particularidad se resuelva, todo siga funcionando sin tener que reescribir nada. Elegimos la segunda. No fue la opción más rápida, pero sí la que respeta el principio que nos guía: la tecnología debe sumarle al criterio del abogado, no agregarle problemas.

El proceso que aplicamos en lugar de improvisar#

Cuando entendimos la magnitud de lo que teníamos por delante, no empezamos a escribir código. Empezamos a pensar. Y a documentar lo que pensábamos.

Lo primero fue una conversación estructurada que en nuestro equipo llamamos brainstorming. Antes de tocar una sola línea, decidimos juntos qué iba a hacer el sistema y qué cosas explícitamente no iba a hacer. Esa segunda parte, decir qué cosas no, suele ser la más importante. Si un cliente quiere cambiar de plan profesional a estudio a mitad de mes, lo dejamos en pausa para revisarlo a mano. No porque no se pudiera hacer automático. La primera versión del sistema tenía que ser predecible antes que vistosa. La discusión duró varias horas. Quedaron escritas siete decisiones explícitas, cada una con su razón.

A partir de esas decisiones armamos un documento de diseño. Es un texto en lenguaje claro, más parecido a un dictamen que a un manual técnico, que describe exactamente qué campos guarda el sistema, en qué orden valida las cosas, qué pasa cuando una validación falla, y cómo se comunica con la pasarela de pagos. Cualquier persona del equipo puede leerlo y entender el sistema sin abrir el código. Cualquier auditor externo, llegado el caso, tiene el mapa completo. Para nosotros, ese documento es el equivalente de un escrito bien fundado: si necesitás defender una decisión en seis meses, ya está justificada por escrito.

Recién con esa base armamos el plan de ejecución. Dividimos la obra en diecinueve tareas chiquitas, cada una con su propio criterio de éxito. La primera era crear una tabla en la base de datos. La última era escribir un manual para el equipo sobre cómo resolver casos que requieran revisión humana. En el medio, cada pieza se construyó de manera aislada para poder probarla por separado antes de conectarla con el resto.

Y acá viene la parte que distingue cómo trabajamos. Cada una de esas diecinueve tareas no la escribió una sola persona. La escribió un agente especializado, dedicado solo a ese trabajo, sin la distracción del resto del proyecto. Y cuando terminaba, la revisaba otro agente que no la había escrito, con el mandato explícito de buscar errores y desviaciones del diseño.

Los tres errores que nadie hubiera visto#

El proceso valió la pena por algo muy concreto. Los revisores atraparon tres errores que ningún cliente jamás habría detectado, pero que habrían generado problemas reales con el tiempo. Vale la pena contarlos porque ilustran el tipo de detalle que cuidamos.

El primero era de tipo invisible. Estábamos por usar una instrucción para actualizar los datos del usuario en su cuenta. Esa instrucción, en lugar de modificar solo los campos que nos importaban, borraba todo lo demás. Si un administrador del estudio se suscribía a un plan, perdía su rol de administrador en ese mismo momento. Nadie lo habría notado hasta que ese administrador intentara entrar a una pantalla restringida y descubriera que ya no tenía permisos. La corrección fue cambiar una palabra en el código. La dificultad técnica no es el punto. El punto es que sin un segundo par de ojos con la misión explícita de revisar, ese error habría llegado a producción.

El segundo era de coherencia. En un punto del sistema escribíamos en la base de datos un valor que no estaba permitido por su propia definición. Funcionaba en las pruebas porque las pruebas no validaban contra esa restricción. Habría fallado silenciosamente la primera vez que un cliente intentara pagar. El sistema le habría dicho que la operación fue exitosa, pero el registro nunca se habría guardado. Cuando el cliente reclamara, no habría rastro del pago de su lado. El revisor lo detectó antes de que ningún cliente llegara a esa pantalla.

El tercero era de claridad documental. Un comentario en el código decía que cierta función todavía no estaba implementada cuando en realidad ya lo estaba. Para vos como cliente esto no significa nada, pero para el equipo que mantiene el sistema dentro de un año es la diferencia entre confiar en lo que lee o tener que verificar todo desde cero. Lo corregimos. Tres líneas. La misma higiene que un abogado prolijo aplica cuando relee un escrito antes de firmar.

Por qué importa cuando elegís tu legaltech#

Cuando hagas click en el botón "Suscribirme" dentro de Gnosis, no vas a ver nada de esto. Vas a ver un botón que funciona. Detrás hay veintiséis cambios documentados, ochenta y dos pruebas automatizadas y cinco capas de validación. Cada decisión que se tomó durante la construcción quedó registrada con su justificación. Si mañana algo se comporta distinto a lo esperado, tenemos exactamente el mismo tipo de trazabilidad que un expediente bien llevado: quién decidió qué, cuándo, y por qué.

Esto no es un detalle decorativo. Una mala práctica en el procesamiento de pagos no afecta a tu estudio la semana que viene. Afecta cuando hay un reclamo dos años después y nadie puede explicar por qué tu cuenta pasó a otro plan ese mes. Una herramienta que no respeta la integridad de tus datos se nota recién cuando los necesitás en serio. Es la diferencia entre un proveedor que entiende que vos vas a tener que defender lo que tu sistema hizo, y uno que no.

En Dikaia tratamos el código con la misma minuciosidad con la que un abogado prepara un escrito clave. No porque tengamos que hacerlo. Lo hacemos porque construimos para un usuario que va a usar nuestra herramienta para producir trabajo del que es responsable profesionalmente. La única manera de estar a esa altura es no permitirnos atajos.

Cuando elegís un proveedor de legaltech, también estás eligiendo cómo trata los problemas que vos no ves. Por eso, antes de pedirte confianza, te mostramos cómo trabajamos.

Si querés entender más a fondo cómo pensamos la calidad en Dikaia, podés leer el Protocolo Dikaia: los cuatro compromisos que guían cada decisión de producto.