Cómo construimos algo donde puedes poner tus datos de comisiones.

Por qué existe esta página

Una pregunta razonable que nos hace cualquiera que evalúa un producto pequeño es si se puede confiar a un equipo pequeño los datos que hacen funcionar la firma. Economía de comisiones, reconocimiento de ingresos, requisitos de clientes, términos de subcontratación de socios. 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 es "muévete rápido, lanza todos los días, discúlpate cuando algo se rompa". Eso es racional para apps de consumo e irracional para software que maneja el dinero de una firma.

Nosotros hicimos el trato opuesto.

Calidad de ingeniería, en números

Estos son hechos sobre el código de producción actual, no aspiraciones.

• 1781 pruebas automatizadas. Una suite de pruebas completa que cubre las capas de smoke, integración y aceptación de usuario, más una capa de UAT de recorrido por persona basada en flujos sobre las pruebas aisladas por funcionalidad. La suite corre con cada cambio. No lanzamos si alguna falla.
• Cero errores de TypeScript mantenidos como línea base. Tipado estricto en todo el código. La clase de errores en que un campo tiene la forma equivocada queda cerrada por el compilador antes de que pueda llegar a un usuario.
• 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 visto bueno. Detecta lo que un visto bueno no detecta.
• La mayoría de las pruebas son sobre dinero. Cálculo de comisiones, congelado de tarifas por snapshot, reconocimiento de ingresos por modelo de precio, totalización de facturas. Las cuentas que importan son las que probamos más a fondo.

Una revisión arquitectónica reciente sacó a la luz siete hallazgos: un hueco urgente de escalación de privilegios, una brecha crítica de seguridad transaccional, tres problemas estructurales y dos puntos menores. Los siete se lanzaron limpios en un solo día, cada uno como su propio cambio verificado. Una auditoría de seguridad posterior cerró cuatro huecos adicionales de autorización por bypass de URL en páginas de detalle. El proceso no es "nunca tenemos problemas". El proceso es "los encontramos y los cerramos, en un plazo medido en horas, no en semanas".

Una auditoría aparte de todo el código el 2026-05-15 revisó 464 archivos fuente y 59,876 líneas de código, en 82 páginas, 177 rutas de API y 94 componentes de cliente. La auditoría produjo 47 hallazgos: 0 críticos, 6 altos, 21 medios, 20 bajos. Los 6 hallazgos altos se atendieron en una sola etapa y se lanzaron limpios.

Una segunda auditoría de código el 2026-05-16, después de que se remediaran los hallazgos de la primera, revisó el código nuevo lanzado en la semana intermedia y produjo 23 hallazgos adicionales: 0 críticos, 3 altos, 11 medios, 9 bajos. Los 3 altos y 4 medios marcados como obligatorios de corregir se atendieron en una sola etapa posterior. El patrón es deliberado. Auditamos, corregimos, lanzamos y volvemos a auditar.

Control de acceso, en detalle

Una firma de servicios de socios no es un solo equipo homogéneo. Es personal, contratistas, socios y a veces usuarios del lado del proveedor, todos viendo datos que se traslapan, todos necesitando accesos distintos. El sistema de permisos se construyó para esa realidad, no en contra de ella.

• Acceso basado en roles con seis roles por defecto: Admin, Ventas, Solutions Engineer, Entrega, Finanzas y Contratista Independiente. Cada rol tiene un conjunto sensato de permisos por defecto.
• Claves de permiso granulares. Cada acción significativa del producto tiene su propia clave de permiso. El constructor de roles lee el catálogo de permisos de forma dinámica, así que los permisos nuevos se vuelven interruptores configurables de forma automática.
• Anulaciones por usuario. Los permisos se pueden conceder o revocar encima de cualquier rol, usuario por usuario.
• Aplicación de alcance a nivel de registro, no solo a nivel de ruta. Un usuario con "ver solo los míos" no puede saltar por URL a registros que no le pertenecen. Las rutas de detalle aplican el alcance por registro usando helpers del lado del servidor, no solo controles de rol a nivel de layout. Una auditoría sistemática de páginas de detalle cerró cada hueco de esta clase.
• Los elementos del menú lateral y del dashboard se ocultan cuando quien los ve no tiene permiso. No un error genérico de "sin acceso"; la navegación misma refleja lo que el usuario de verdad puede hacer.
• Jerarquía de permisos de tres niveles: organización, equipo, usuario. El permiso efectivo se resuelve usuario, luego equipo, luego organización. Gana el más específico. La fuente de verdad es la tabla permission_grants.
• 117 claves de permiso cubren cada superficie protegida.
• 18 permisos son pegajosos en admin y no se le pueden revocar a un admin sin un cambio de código. permission_audit_log escribe una fila en cada concesión o revocación con actor, objetivo, alcance, clave, antes / después y razón.
• Los reportes sensibles financieros, de compensación y de gobierno están gateados por permiso tanto a nivel de página como de exportación. Las personas correctas ven los números correctos. Los reportes sensibles (P&L de toda la firma, compensación por persona, gobierno de payouts a socios, exportaciones del registro de auditoría) requieren concesiones de rol explícitas para verse, y un permiso aparte para exportar. No lanzamos un modo en el que todos vean todo.
• Prueba de la matriz de permisos. Una sola prueba de integración asegura que cada superficie protegida está gateada por la clave de permiso correcta. La prueba corre en cada commit. Una superficie sin protección hace fallar a CI antes de poder lanzarse.
• Prueba del alcance de datos del dashboard. Una prueba de integración aparte asegura que ningún widget del dashboard personal expone datos fuera del alcance de visibilidad de quien lo ve. Si la existencia de un registro oculto pudiera filtrarse a través de un conteo o un rollup, la prueba hace fallar a CI.

Cómo se protegen las cuentas de dinero

Esta es la parte del producto donde los errores cuestan más. Está construida con eso en mente.

• Snapshots de tarifa de comisión. Al cerrar el trato, la regla de comisión activa se congela sobre el trato. Un cambio de regla posterior aplica solo a tratos cerrados después de él. Los tratos cerrados son inmutables. La clase de error en que "un cambio de regla alteró retroactivamente las comisiones del trimestre pasado" queda cerrada por diseño.
• Las operaciones de escritura múltiple son atómicas. Las operaciones que tienen que escribir en varias tablas a la vez (la aceptación de una cotización, el traspaso de un trato a proyecto, la aprobación de una orden de cambio) van envueltas en transacciones de base de datos. O se completan del todo o se revierten del todo. No hay estado a medias.
• Los agregados en caché se recalculan al escribir. Las horas de proyecto, el uso de periodo de retainer y otros totales derivados se recalculan dentro de la misma transacción que actualiza los datos de origen. El número en caché nunca está desactualizado ni por un instante.
• Migraciones de base de datos versionadas. Los cambios de esquema preservan los datos, no los recrean. Catorce migraciones versionadas lanzadas hasta la fecha.
• Flujo de bloqueo de periodo de tiempo. Los periodos semanales pasan de abierto a enviado, a aprobado, a bloqueado. Los periodos bloqueados rechazan escrituras con HTTP 423. El desbloqueo por admin requiere una razón escrita y se escribe en un registro de auditoría de solo agregado. El estado del periodo y el historial de rollover son reportables.
• Field Guide. Cada entidad, ruta, tabla y clave de permiso está documentada como un esquema autoderivado en /admin/field-guide. El Field Guide se genera desde el código, así que no puede separarse de lo que realmente está lanzado.

Endurecimiento del inicio de sesión

• Cutover al inicio de sesión con OTP por email a nivel de aplicación. El puente SSO de Cloudflare Access se retiró en favor del propio camino de OTP de la app, así que la cadena de auditoría es de una sola fuente.
• Política de inicio de sesión por organización. Longitud del código OTP configurable, expiración y umbrales de rate-limit por email y por IP en /admin/settings/auth.
• Notificación de nuevo dispositivo. El primer inicio de sesión desde una huella de dispositivo no vista antes escribe un elemento en el inbox dentro de la app y le envía un correo al usuario.
• Desbloqueo por admin en /admin/users/[id]/unlock para usuarios con bloqueo. Se requiere una razón escrita. El desbloqueo se escribe en el registro de auditoría de inicio de sesión.
• Registro de auditoría de inicio de sesión en cada éxito y cada fallo. El registro completo de quién inició sesión, desde dónde y qué falló es consultable.

Borrado, retención y restauración

• Soft-delete en cada entidad. 14 políticas de retención cubren leads, tratos, proyectos, tareas, tiempo, gastos, facturas, pagos, cotizaciones, escalaciones, cierres de escalación, action items, comentarios, adjuntos y filas de auditoría. Cada una tiene una ventana por defecto más una anulación por entidad a nivel admin.
• Cascada de borrado. Al borrar un padre se borran sus hijos, registrado por fila con el id de la corrida de cascada de origen. Al restaurar al padre se restauran los hijos en cascada que se fueron con él.
• Cron diario de purga automática a las 04:00 UTC barre cada tabla de entidades, elimina de forma definitiva las filas que pasaron el umbral de su política y emite una fila de auditoría resumen.
• Snapshot al purgar. Cada fila a punto de eliminarse de forma definitiva primero se serializa en una tabla purge_snapshots con un plazo de recuperación de 30 días. La restauración de emergencia rehidrata la fila a través de un endpoint solo para admin dentro de esos 30 días.
• Retención de facturas por defecto de 7 años. Ajustarla a la baja requiere una anulación de admin con una razón escrita en el registro de auditoría.

Historial de entidades (cada escritura, cada diff)

• Cada insert, update, soft-delete y restauración escribe un snapshot de la fila posterior a la escritura en entity_history con el actor, el timestamp, la acción y el JSON completo de la fila.
• Resumen changed_fields por snapshot permite que los feeds de historial y los diffs se rendericen sin parsear el JSON en cada fila.
• Vista de diff. A nivel de campo, a nivel de palabra para texto largo, resúmenes de arreglos hijos para partidas y action items.
• Restauración por lote entre entidades vía change_batch_id. Una sola acción de usuario que editó un trato, su cotización y tres tareas se puede rebobinar como una sola transacción.
• Retención por defecto de 365 días, anulación por tipo de entidad en /admin/entity-history-policies, purga diaria a las 04:00 UTC con vista previa dryRun=1.

Respaldos diarios fuera de sitio

• Cron diario de respaldo a R2 a las 06:00 UTC. Retención de 7 días. Disposición de carpetas por entorno (producción, staging, dev).
• Consola de admin en /admin/backups lista cada snapshot.
• Botón de respaldo forzado protegido con admin.force_backup (pegajoso en admin).
• Restauración en modo dry-run muestra una vista previa de tablas y conteo de filas antes de que el botón de restaurar escriba cualquier cosa.
• Registro de auditoría de respaldos captura cada corrida forzada e intento de restauración.

Disciplina del registro de auditoría

• Filas de auditoría de solo agregado en concesiones de permisos, ediciones de configuración, ediciones de políticas de retención, ciclos de bloqueo/desbloqueo, eventos de borrado/restauración/purga y lotes de importación.
• Retención de 3 años por política.
• Ninguna ruta de UI o API puede mutar o eliminar una fila de auditoría.
• Visor de auditoría en /admin/audit-log con filtros.

Lo que deliberadamente no lanzamos

Una lista corta de cosas que no haremos, aunque algunas de ellas ayudarían a vender el producto.

• Nada de IA en las cuentas de dinero. Cada sugerencia que el producto muestra (el panel de Insights en cada proyecto, por ejemplo) es una regla determinista que podemos explicar en una sola oración. El dinero no debe ser asesorado por un modelo que no puede mostrar su trabajo. Si alguna vez lanzamos algo respaldado por un modelo, será en lugares donde acertar importa menos que ser interesante.
• Nada de fallas silenciosas. Las fallas no fatales aparecen como advertencias, no como errores ocultos. Si una plantilla no se aplica durante el traspaso de un proyecto, ves un banner amarillo que dice exactamente qué salió mal. El sistema no finge que las cosas funcionaron cuando no fue así.
• Nada de afirmaciones de "todo en uno" que no podamos respaldar. PartnerView es un CRM y un PSA. No es un reemplazo de tu sistema contable, tu almacenamiento de archivos ni tus herramientas de comunicación. Lo decimos a propósito.

Lo que todavía no hemos hecho

En el mismo espíritu, estos son huecos reales. Están en el roadmap. No están hechos.

• Auditoría SOC 2. Actualmente sin certificación. Los controles de ingeniería que respaldarían una auditoría SOC 2 ya están en su lugar; la auditoría misma no.
• Google SSO. Planeado. La autenticación actual es con usuario y contraseña.
• Portal de clientes. Planeado. Hoy los clientes ven reportes de estado y aprobaciones a través de enlaces que les envías, no de un portal al que inician sesión.

Los listamos aquí porque fingir que existen sería exactamente lo opuesto al sentido de esta página.

Cómo queremos que se sienta esto

Si estás evaluando PartnerView y la objeción en tu cabeza es "son demasiado pequeños para que les confíe esto", la respuesta no es que no seamos 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 de boutique puede ser una herramienta de alta calidad. Estamos esforzándonos mucho por demostrarlo.

Para más detalle sobre cualquiera de lo anterior, las field notes cubren varios de estos temas a mayor profundidad. El catálogo de funcionalidades lista cada capacidad ya disponible sin barniz de marketing.