Volver a casos
Professional Services / Compliance SaaS Redesign + rebuild — 3-4 meses

Firma de servicios profesionales con plataforma de línea ética SaaS

De semanas por cada cambio a una plataforma de línea ética configurable

Una firma de servicios profesionales opera una plataforma de línea ética para una cartera enterprise amplia. Cada cambio simple podía tardar semanas. Las notificaciones y workflows necesitaban más configuración. Diseñamos un rebuild que convierte esa complejidad en configuración segura, sin empezar de cero.

Grabado de sobres anónimos sellados avanzando por una máquina de compliance hacia un registro de auditoría
Resumen

Una firma de servicios profesionales opera una plataforma de línea ética para una cartera enterprise amplia. Cada cambio simple podía tardar semanas. Las notificaciones y workflows necesitaban más configuración. Diseñamos un rebuild que convierte esa complejidad en configuración segura, sin empezar de cero.

Enterprise cartera amplia en la plataforma
semanas → días tiempo por cambio de funcionalidad
Presupuesto acotado rebuild sin romper lo que funciona
El contexto

Qué estaba bloqueando la operación

Imaginá que operás una plataforma de línea ética donde empresas enterprise gestionan denuncias anónimas. Tus clientes incluyen multinacionales con subsidiarias en varios países. Cada una necesita workflows distintos, roles distintos, notificaciones distintas.

01

La situación antes

Imaginá que operás una plataforma de línea ética donde empresas enterprise gestionan denuncias anónimas. Tus clientes incluyen multinacionales con subsidiarias en varios países. Cada una necesita workflows distintos, roles distintos, notificaciones distintas.

01Cartera enterprise amplia usando la plataforma para gestionar denuncias éticas y canales de denuncia anónimos.

02Cambios que parecían de "dos clics" tardaban una semana o más — la complejidad acumulada del código hacía que cada modificación fuera un riesgo.

03Workflows rígidos — la máquina de estados (nueva → investigación → cerrada) no se adaptaba a los flujos reales de cada cliente. Algunos necesitaban 7-10 estados con transiciones configurables.

04Notificaciones poco configurables — no se podía definir con precisión qué roles recibían qué eventos.

05Roles fijos — 6 roles predefinidos sin posibilidad de asignar roles múltiples a un usuario ni crear roles custom por empresa.

06Necesidad de más seguridad de regresión — sin test suite automatizado, cada fix tenía más riesgo del necesario.

07Dependencias técnicas heredadas señaladas en revisiones de seguridad — con una certificación de seguridad en el roadmap, esto requería una base más moderna.

08Dos versiones paralelas (v1 y v2) coexistiendo para distintos clientes — duplicando el esfuerzo de mantenimiento.

09Permisos que necesitaban consistencia en todas las superficies — dashboard, listados, exportaciones y reportes.

02

Timeline

03

Lo que encontramos al entrar

Clientes enterprise activos Cartera amplia
Tiempo por cambio "simple" Semanas
Estados de workflow configurables 0 — máquina de estados fija
Roles configurables por empresa 0 — 6 roles fijos
Notificaciones editables por cliente Pendientes de configurar
Test suite automatizado Pendiente de completar
Versiones paralelas en mantenimiento 2 (v1 + v2)
Consistencia de permisos Requería refuerzo en todas las superficies

Hallazgos

  • El problema de fondo no era visual — el team de la firma inicialmente quería un "refresh" estético. Al bajar a los detalles, descubrimos que lo que necesitaban era flexibilidad de negocio: workflows configurables, roles dinámicos, notificaciones editables.
  • Cada cliente de la plataforma tiene requisitos distintos — una multinacional con subsidiarias en AR/UY/CL necesita residencia de datos por país y que el mismo usuario pueda existir en varias subsidiarias del mismo grupo.
  • Las personalizaciones por cliente (relabeling de campos, hide/show de inputs) creaban fragilidad acumulativa — cada nuevo ajuste aumentaba el riesgo de afectar otro flujo.
  • Faltaba un log completo de auditoría — en una plataforma de compliance, ver quién hizo qué y cuándo es parte de la operación esperada.
  • La landing externa y la aplicación tenían look-and-feel inconsistente — una capa innecesaria que nadie mantenía.
  • El search y las pantallas de listado eran lentas, especialmente para clientes con muchos comités y usuarios.
04

Lo que diseñamos

De una máquina de estados fija a flujos de trabajo personalizables sin tocar código.

Workflows configurables (state machine por cliente)

De una máquina de estados fija a flujos de trabajo personalizables sin tocar código.

  • Estados configurables por empresa (7-10 estados custom vs. los 6 fijos actuales).
  • Transiciones configurables: qué rol puede mover una denuncia de qué estado a qué estado.
  • Reasignación de comités post-derivación — hoy es imposible.
  • Creación inline de comités desde el contexto de la denuncia.
  • Razones de cierre personalizables por empresa (ya parcialmente implementado, ahora con más flexibilidad).

Roles y permisos dinámicos

De 6 roles fijos a un sistema de permisos granular y configurable.

  • Roles custom por empresa — cada cliente define los suyos.
  • Asignación de múltiples roles a un mismo usuario.
  • Modelo de grupo económico: un usuario puede existir en múltiples subsidiarias de un mismo holding sin duplicación.
  • Permisos consistentes en todas las superficies: dashboard, listados, exportaciones, reportes.

Notificaciones configurables

De emails poco configurables a un sistema de preferencias por usuario.

  • Panel de preferencias de notificación por usuario y por rol.
  • Templates de email editables por empresa — copy y triggers customizables.
  • Control de frecuencia para evitar exceso de notificaciones por denuncia.
  • Alertas configurables por tipo de evento (nueva denuncia, respuesta, cambio de estado, vencimiento).

Test suite automatizado

No podés reconstruir una plataforma de compliance sin tests. Cada deploy necesita una red de seguridad.

  • Suite de tests automatizados como deliverable del proyecto — no como nice-to-have.
  • Cobertura de permisos y filtros de datos como prioridad.
  • Testing de regresión automático antes de cada deploy — para que un fix no rompa otra cosa.

Funnel analytics y auditoría

La plataforma genera datos valiosos que hoy nadie puede ver.

  • Funnel analytics en el formulario de denuncia — dónde abandonan los denunciantes, dónde hay fricción.
  • Log completo de auditoría: quién hizo qué, cuándo, descargable.
  • Trazabilidad de acciones masivas (bulk close, bulk reassign).
05

Impacto diseñado

El cambio fundamental: lo que hoy requiere código y semanas de trabajo pasa a ser configuración que un admin puede hacer en el día.

De semanas a días por personalización

El cambio fundamental: lo que hoy requiere código y semanas de trabajo pasa a ser configuración que un admin puede hacer en el día.

Tiempo para agregar un workflow customSemanas de desarrolloTiempo para crear un rol nuevoImposible (fijo en código)Notificaciones por clientePoco configurablesTest suiteManual e incompleto
  • Cada nuevo cliente que necesita un workflow distinto deja de ser un proyecto de desarrollo — es una configuración.
  • El equipo técnico deja de ser cuello de botella para personalizaciones de negocio.
  • El product lead puede iterar sin depender del dev para cada cambio.

Postura de seguridad fortalecida

La plataforma maneja denuncias anónimas de multinacionales — la seguridad no es opcional.

Dependencias heredadas señaladasMúltiples en revisionesLog de auditoríaPendiente de completarPermisosRequerían consistencia transversalReadiness de seguridadLimitada por stack heredado
  • Las dependencias heredadas que aparecían en revisiones de seguridad se eliminan con el rebuild.
  • El log de auditoría completo es un requisito para el camino de certificación — ahora existe.
  • Los permisos se validan en todas las superficies (dashboard, exports, listados) por diseño.

Credibilidad del equipo técnico interno

El tech lead y el product lead de la firma estaban atrapados en un ciclo de ajustes acumulados. El rebuild les devuelve la capacidad de proponer mejoras reales.

  • El dashboard previamente entregado ya había generado feedback positivo del equipo: una victoria visible que validó la capacidad de ejecución.
  • El framing del rebuild pasó de "restyling cosmético" a "mejoras reales a la herramienta" — el tech lead lo adoptó como visión propia.
  • El test suite automatizado les da confianza para deployar sin miedo a romper lo que funciona.
06

Por qué este caso importa

No propusimos tirar todo y empezar de cero. Mapeamos qué funciona (el modelo de permisos, la lógica de anonimato, el formulario de denuncia) y qué necesitaba más flexibilidad (workflows, roles, notificaciones, tests). El rebuild preserva la inversión existente y reemplaza la rigidez por configuración.

Rebuild, no rewrite — preservar lo que funciona

No propusimos tirar todo y empezar de cero. Mapeamos qué funciona (el modelo de permisos, la lógica de anonimato, el formulario de denuncia) y qué necesitaba más flexibilidad (workflows, roles, notificaciones, tests). El rebuild preserva la inversión existente y reemplaza la rigidez por configuración.

De "restyling" a flexibilidad de negocio

El cliente vino pidiendo un refresh visual. Empujamos la conversación hasta donde importaba: si tus workflows no se adaptan a cada cliente, si tus roles son fijos, si cada cambio tarda semanas — el problema no es cómo se ve. Es cómo funciona.

Compliance-first: tests, auditoría, permisos

En una plataforma de línea ética, los flujos de denuncia necesitan seguridad de regresión. El test suite automatizado, el log de auditoría completo y los permisos consistentes no son features; son requisitos de existencia.

Presupuesto acotado que desbloquea

El presupuesto está pensado para desbloquear la flexibilidad que la plataforma necesita para seguir creciendo, no para una reescritura larga que nunca llega a producción. Eso evita el cementerio de pilotos: proyectos caros que mueren en el camino.

Lo que viene

  • Cerrar el acuerdo y comenzar la implementación del rebuild (3-4 meses estimados).
  • Migrar los workflows, roles y notificaciones de los clientes existentes al nuevo modelo configurable.
  • Implementar el funnel analytics del formulario de denuncia para optimizar conversión.
  • Preparar la documentación de seguridad y arquitectura para el proceso de certificación.
  • Evaluar la migración de base de datos como fase posterior al rebuild core.