WHY Dynamics · C# · SQL Server · Sistema de almacén
Tenéis un sistema de almacén en C# y SQL Server que funciona. El problema es que nadie sabe exactamente cómo. Hay APIs conectadas entre sí sin documentar, stored procedures que hacen más de lo que su nombre indica, y cambios que se propagan a sitios que nadie esperaba.
Tu situación exacta · Lo que nos describís antes de llamar
La mayoría de estos sistemas no fallaron porque nadie supiera programar. Crecieron sin que nadie llevara el mapa al día. Y cuando no hay mapa, cada cambio es una apuesta.
La API de entrada y el módulo de expedición parecen no tener relación. Pero hay un stored procedure que llama a los dos sin que nadie lo documentara. Nadie lo sabía hasta que se rompió.
El backlog existe. El equipo sabe lo que hay que hacer. Pero el miedo a una regresión en producción lo congela todo. El sistema funciona. El negocio pide cambios. Nadie los toca.
Los stored procedures crecieron durante años y hoy hacen cosas que deberían estar en la capa de negocio. Están en producción, y tocarlos da miedo a todo el mundo.
Cada dev que ha entrado ha añadido algo encima sin entender lo que había debajo. A veces sin saberlo. El sistema crece, pero el entendimiento sobre cómo funciona se reduce.
Sin saber qué toca qué, cualquier integración nueva puede romper algo en un sitio inesperado. Con el mapa de dependencias, sabes exactamente qué vas a impactar antes de escribir una línea.
El equipo no es lento. Es que pasa la mayor parte del tiempo arreglando problemas que el propio sistema genera. El ratio exacto depende de cada caso, pero el patrón es siempre el mismo.
"Tardamos más en entender qué podemos cambiar sin que se rompa algo que en hacer el cambio en sí. Y aun así nos equivocamos."
Director de Desarrollo · Empresa logística · 800 empleados · Sistema C# + SQL Server · 11 años en producción.
Por qué un equipo pequeño y especializado resuelve esto mejor que una consultora grande
Produce más código que nadie va a entender tampoco. Este problema se resuelve con el mapa correcto y sabiendo en qué orden tocar las cosas.
Sin capas de gestión. La persona que habla con vosotros en la llamada inicial es la misma que lee el repositorio y construye el mapa de dependencias.
Una consultora grande puede tardar semanas solo en organizar el acceso al repositorio. Nosotros usamos docdep.cli para leer el sistema completo en días. El diagnóstico es un entregable, no una fase de onboarding.
Empezamos con un diagnóstico de precio fijo. Después, si tiene sentido, una prueba de concepto en un módulo concreto. Sabéis qué vais a recibir y cuánto cuesta antes de firmar nada.
Cuando terminemos, vuestro equipo puede mantener el sistema sin que sigamos ahí. Los tests de regresión, el mapa de dependencias y la documentación son vuestros desde el primer entregable.
Cada cambio va con el mapa de impacto delante. Cada despliegue tiene tests de regresión y rollback documentado. Si algo falla en staging, no llega a producción.
Diagnóstico: precio cerrado. PoC: precio cerrado. Estabilización completa: presupuesto basado en el diagnóstico real. Nunca empezamos una fase sin que tengáis el número exacto.
El proceso · Tres fases, cada una con precio y entregables cerrados
En un sistema con dependencias no documentadas, empezar a cambiar código antes de tener el mapa es lo que convierte una mejora en una crisis. Es el motivo por el que falló el intento anterior.
FASE 01
1–2 semanas · Precio fijodocdep.cli lee el código C#, el esquema SQL Server, los stored procedures, triggers y APIs. Sin entrevistar a nadie. Sin documentación previa. En 1–2 semanas tenéis el mapa que debería haber existido desde el principio.
FASE 02
2–4 semanas · Precio fijoElegimos juntos 1–2 módulos o endpoints con más regresiones. Los refactorizamos con el mapa delante, añadimos tests de cobertura y lo desplegamos en staging con rollback preparado. Veréis el proceso completo antes de comprometer el resto.
FASE 03
Según diagnóstico · Hitos cerradosCon el diagnóstico real y la PoC validada, extendemos el trabajo al resto de módulos priorizados. El objetivo no es reescribir el sistema: es que vuestro equipo pueda modificarlo sin que cada cambio sea una apuesta.
La herramienta que hace posible el diagnóstico en 1–2 semanas
No es un agente genérico. Es una herramienta propia, construida para este tipo de problema: código C# sin documentación, dependencias opacas entre módulos y base de datos, nadie disponible para explicarlo.
Mantiene el contexto completo del sistema: código C#, esquema SQL Server, stored procedures, triggers y APIs. No analiza ficheros de forma aislada. Entiende las relaciones entre todas las partes.
Lo que un equipo senior tardaría meses en mapear, docdep.cli lo hace en días. Sin entrevistar a nadie. Sin esperar documentación que no existe.
Entiende las relaciones entre la capa C# y el esquema SQL Server al mismo tiempo. Detecta cuándo una API llama a un stored procedure que modifica datos que otra API asume constantes. Ahí está la causa de la mayoría de las regresiones.
Rastrea cada llamada, cada referencia, cada uso de cada stored procedure y cada tabla. Antes de tocar X, sabéis exactamente qué otras partes del sistema pueden verse afectadas.
Un equipo senior tardaría meses en hacer este análisis a mano. docdep.cli lo hace en días. Por eso podemos cobrar el diagnóstico a precio fijo y entregarlo en 1–2 semanas: el tiempo de análisis es predecible.
Una vez conoce el sistema, el agente puede ejecutar cambios sabiendo qué tocar, qué no, qué tests correr y qué verificar antes de dar el cambio por bueno. Sin adivinar. Sin zonas grises.
Preguntas directas
¿Cuánto cuesta el diagnóstico y qué incluye exactamente? +
Tiene un precio fijo que os damos antes de empezar, calculado en función del tamaño del repositorio y del esquema SQL Server. Incluye: mapa completo de dependencias, los nodos concretos que explican las regresiones, inventario de stored procedures con lógica de negocio embebida, estimación de esfuerzo por módulo y plan de estabilización priorizado. No hay ningún concepto abierto: sabéis exactamente qué vais a recibir y cuánto cuesta antes de aceptar nada.
¿Qué acceso necesitáis al repositorio y a la base de datos? +
Para el diagnóstico, acceso de solo lectura al repositorio y una copia del esquema SQL Server sin datos reales. No necesitamos acceso a producción ni a datos de clientes. Os decimos exactamente qué permisos necesitamos antes de empezar. Si vuestro equipo de seguridad tiene requisitos de acceso específicos o entornos aislados, nos adaptamos.
¿Cómo aseguráis que no vais a romper nada en producción? +
Nada llega a producción sin pasar por staging con tests de regresión y rollback preparado. Antes de modificar cualquier módulo, tenemos el mapa de impacto completo. En la prueba de concepto empezamos por un módulo que no sea crítico para que veáis el proceso entero —análisis, cambio, tests, staging, rollback si fuera necesario— antes de comprometer nada mayor.
¿Trabajáis con nuestro equipo de desarrollo o en paralelo? +
Como queráis. Podemos trabajar de forma autónoma o codo a codo con vuestros devs. La segunda opción suele generar más valor a largo plazo: el equipo sale del proceso sabiendo cómo funciona el sistema y puede mantenerlo después sin depender de nadie externo. La transferencia de conocimiento no es un extra que se añade al final, es parte del entregable desde la Fase 1.
Somos una empresa de 1000 empleados. ¿Podéis con eso? +
El tamaño de la empresa no cambia nada en este tipo de trabajo. Lo que determina el esfuerzo es el tamaño del sistema, no de la organización. Empresas grandes nos contratan para esto precisamente porque saben que una consultora grande tardaría meses en entender lo que tienen. El diagnóstico + PoC es un trabajo acotado y concreto, independientemente del tamaño de la empresa.
¿Qué pasa si después del diagnóstico queremos seguir a mayor escala? +
El diagnóstico incluye el plan de estabilización completo con estimación de esfuerzo por módulo. Con eso podéis decidir: ejecutarlo con nosotros, con vuestro equipo interno, o con otro proveedor. El mapa y la documentación son vuestros desde el primer entregable. Si seguís con nosotros, bien. Si no, también.
¿Cómo añadís tests en un sistema sin ninguna cobertura? +
Con el mapa de dependencias sabemos qué comportamientos hay que proteger antes de tocar algo. Empezamos por characterization tests: tests que documentan el comportamiento actual del sistema, aunque sea imperfecto, para que cualquier cambio posterior tenga una red de seguridad. Es la forma de añadir cobertura a un sistema legacy sin tener que reescribirlo todo primero.
La primera conversación · Sin propuesta, sin PowerPoint
No necesitáis preparar nada. Describidnos el sistema en dos líneas y hablamos.
MIN 01–05
Nos contáis el sistema
Tecnología, antigüedad, tamaño del equipo, los tres últimos fallos que más problemas causaron. Sin formularios de 30 campos.
MIN 06–15
Identificamos el patrón
Con lo que nos contáis, reconocemos el tipo de problema y cómo suele estar distribuido. Os decimos qué encontraréis probablemente en el diagnóstico antes de pagarlo.
MIN 16–25
Precio del diagnóstico
Os damos el precio fijo del diagnóstico en esa misma llamada. Calculado sobre el tamaño del repositorio que nos describís, no sobre una estimación genérica.
MIN 26–30
Os decimos si no encaja
Si el problema que tenéis no es algo que podamos resolver bien, os lo decimos aquí. Preferimos eso a cobrar un diagnóstico que no va a producir nada útil.
Lo que pensáis antes de escribir. Respuesta directa.
"¿Vais a entender nuestro stack específico?"
Hemos analizado sistemas C# con 10–20 años de capas acumuladas, stored procedures con lógica de negocio embebida y arquitecturas que crecieron sin diseño previo. El patrón de problema es reconocible aunque el sistema sea diferente. Si en 15 minutos de llamada no os estamos aportando algo concreto, os lo decimos.
"Ya tuvimos una consultora y fue peor."
Casi siempre por la misma razón: empezaron a tocar sin entender el sistema. En Fase 1 no tocamos nada. Solo analizamos. La PoC en Fase 2 es sobre un módulo que no sea crítico primero. Si algo falla en staging, no llega a producción.
"¿El diagnóstico no es solo una puerta de entrada a un contrato mayor?"
El diagnóstico es un entregable completo por sí solo. Después podéis ejecutar el plan con vuestro equipo, con nosotros o con otro proveedor. El mapa y el plan son vuestros desde el primer entregable.
"¿Tenéis capacidad para una empresa de nuestro tamaño?"
El tamaño de la empresa no cambia el tipo de trabajo. Lo que importa es el tamaño del sistema. Empresas grandes nos contratan para trabajos concretos y acotados que no quieren meter en un proyecto de transformación de doce meses.
"¿Cuánto tiempo necesitaréis de nuestro equipo?"
Para el diagnóstico: una reunión inicial de una hora y acceso de solo lectura al repo. No necesitamos tiempo de vuestros desarrolladores durante el análisis. Para la PoC, los despliegues a staging se coordinan en ventanas que no afecten a la operativa.
Pedir diagnóstico · Precio fijo · 1–2 semanas
Qué sistema, qué tecnología, cuál es el problema más frecuente. Os respondemos en menos de 4 horas con el precio del diagnóstico. Hablaréis con quien va a analizar el código.
O llamadnos directamente:
918 991 604
Lun–Vie 9h–18h · Madrid y toda España
Además del diagnóstico, ofrecemos una demo de 20 minutos donde docdep.cli analiza vuestro repositorio en directo, construye el mapa de dependencias y ejecuta un cambio de forma autónoma. Con vuestro código, no con uno de ejemplo.