10 Preguntas que Debes Hacer Antes de Contratar a un Desarrollador de CRM o ERP Personalizado

La mayoría de los proyectos CRM y ERP no fracasan porque la tecnología era incorrecta. Fracasan porque no se hicieron las preguntas correctas antes de que se firmara el contrato. He sido parte de suficientes de estos compromisos — en ambos lados de la mesa — para saber que la diferencia entre un proyecto que entrega y uno que se estanca generalmente es visible en la primera conversación, si sabes qué buscar.

Estas son las diez preguntas que uso. No para descalificar a los proveedores, sino para entender cómo trabajan realmente.

Antes de Firmar Cualquier Cosa, Haz Estas 10 Preguntas

Algunas de estas parecerán obvias. Algunas harán que el proveedor se sienta incómodo — y esa reacción vale la pena notar. Ambas te dicen algo útil.

1. ¿Quién es el dueño del código, el modelo de datos y las integraciones cuando termina el compromiso?

Esta es la primera pregunta que hago — y la que genera las respuestas más sorprendentes.

La respuesta debe ser inequívoca: tú eres el dueño de todo. Si un proveedor duda, califica la propiedad con condiciones de licenciamiento o hace referencia a frameworks propietarios a los que no puedes acceder sin ellos, esa es una dependencia contractual que costará dinero más adelante.

Específicamente, pregunta sobre:

• Código fuente — acceso completo al repositorio, no solo un despliegue
• Esquema de base de datos y modelo de datos — tuyo para migrar o extender
• Integraciones API — credenciales, documentación y configuraciones
• Scripts de despliegue y configuración del pipeline — para que otro equipo pueda ejecutar y mantener el sistema

Pide esto por escrito antes de la etapa de propuesta. Si el proveedor lo trata como una solicitud inusual, eso te dice algo sobre su práctica estándar.

2. ¿Cómo manejan los cambios de alcance a mitad del proyecto?

Cada proyecto CRM y ERP cambia después de que comienza. Los requisitos del negocio cambian. Los stakeholders descubren que lo que pidieron no es lo que necesitaban. Las integraciones resultan ser más complejas de lo que nadie estimó.

La pregunta no es si el alcance va a cambiar — lo hará. La pregunta es qué le pasa al cronograma y al presupuesto cuando sucede. Algunos proveedores usan solicitudes de cambio para renegociar todo el compromiso a tarifas premium. Otros tienen un proceso estructurado para evaluar el impacto de los cambios y absorber variaciones razonables dentro de un framework definido.

Pide un ejemplo real: un proyecto donde el alcance cambió significativamente y qué le pasó al cronograma y al costo. La especificidad de esa respuesta te dice más que cualquier documento de proceso que te envíen.

3. ¿Pueden mostrarme un proyecto que fue más difícil de lo esperado — y qué hicieron al respecto?

Cada proveedor te dará su mejor caso de estudio. Eso no es lo que necesitas.

La pregunta más reveladora en cualquier evaluación de proveedor es sobre un proyecto que no fue fluido. No un fracaso — un proyecto que enfrentó obstáculos reales: una migración de datos que tomó tres veces más tiempo de lo planeado, una API de terceros que resultó no estar documentada, un stakeholder del cliente que cambió los requisitos después de la aprobación.

Cómo maneja un equipo la adversidad bajo un contrato activo es un mejor predictor de resultados que cualquier referencia exitosa que voluntariamente ofrezcan. Un proveedor que no puede señalar un proyecto difícil y describir lo que aprendió de él o no ha hecho suficiente trabajo o no está siendo honesto contigo.

4. ¿Cómo se ve tu proceso antes de darnos un precio?

Un proveedor que cotiza un precio dentro de las 48 horas de un envío de formulario está adivinando. Ese número está basado en supuestos sobre tu modelo de datos, tus integraciones, tus sistemas existentes y la capacidad de tu equipo para participar en el proyecto — supuestos hechos sin entender realmente nada de eso.

Un proveedor que hace bien esto ejecuta un proceso de descubrimiento estructurado antes de proponer cualquier cosa — preguntando sobre tus flujos de trabajo actuales, tu stack tecnológico, tus requisitos no negociables y las restricciones que nunca aparecen en el brief inicial.

Cuando CodeBranch trabajó con una empresa de suministros de redes eléctricas en un ERP personalizado, el compromiso pasó por cuatro pasos antes de que se escribiera una línea de código:

1. Selección de tecnología — evaluar qué stack se ajusta a los requisitos reales
2. Diseño de solución — decisiones de arquitectura tomadas antes de que comience la implementación
3. Planificación de entrega — hitos, alcance y criterios de aceptación definidos de antemano
4. Asignación de tareas — quién hace qué, con qué estándar

Esa estructura hizo posible lanzar con capacidades iniciales de producción en el segundo mes. Ver el caso de estudio del ERP para los detalles completos.

Un proveedor que se salta este paso te costará más de lo que su cotización inicial más baja sugiere.

5. ¿Cómo manejan la migración de datos de sistemas heredados?

Aquí es donde la mayoría de los proyectos CRM y ERP reciben su primera sorpresa real.

Cada empresa que necesita un CRM o ERP personalizado ya tiene datos en algún lugar — hojas de cálculo, un sistema antiguo que han superado, una mezcla de ambos. Mover esos datos a una nueva plataforma rara vez es tan sencillo como suena. Los mapeos de campos no coinciden, la calidad de los datos resulta ser inconsistente y el negocio sigue operando mientras la migración está ocurriendo.

Un proveedor que te da una respuesta confiante de una sola línea a esta pregunta no ha hecho suficientes migraciones. La respuesta correcta describe un proceso: auditoría de datos antes de que comience la migración, un entorno de staging donde se valida la integridad de los datos antes de que nada vaya a producción, y un plan de rollback si algo se rompe. Pregunta específicamente sobre cómo manejan los registros que no se mapean limpiamente — los casos extremos son donde fallan las migraciones.

Gartner predice que para 2027, más del 70% de las iniciativas ERP recientemente implementadas no cumplirán plenamente sus objetivos de negocio originales — y la migración de datos se cita consistentemente como uno de los principales factores que contribuyen a esa tasa de fracaso. No es una nota técnica al pie. Es un riesgo del proyecto que necesita un plan antes del arranque, no durante.

6. ¿Quién trabajará realmente en mi proyecto — y ese equipo se mantendrá consistente?

El equipo presentado durante el proceso de ventas a menudo no es el que aparece después de firmar. Los ingenieros senior generan confianza en las conversaciones iniciales; los desarrolladores junior manejan el trabajo real. En un proyecto CRM o ERP — donde el sistema necesita modelar flujos de trabajo específicos del negocio — la continuidad del equipo importa más que en la mayoría de los otros tipos de desarrollo.

Pregunta directamente: ¿quiénes son las personas específicas que trabajarán en este proyecto? ¿Cuál es su nivel de seniority? ¿Qué pasa si uno de ellos se va durante el compromiso? ¿Hay un proceso de transferencia de conocimiento si el equipo cambia?

7. ¿Cómo se ve tu proceso de QA — y en qué etapa ocurre?

Si la respuesta es “probamos al final”, eso es un problema estructural.

El aseguramiento de calidad que solo ocurre después de que el desarrollo está completo detecta defectos tarde — cuando corregirlos cuesta más. En un proyecto CRM o ERP, donde la lógica de negocio es compleja y un error de datos en producción tiene consecuencias reales, el QA en la etapa final es un riesgo estructural.

Las verificaciones de calidad deben estar integradas durante todo el ciclo, no añadidas al final:

• Pruebas automatizadas en cada commit — no ejecutadas manualmente antes de un release
• Revisiones de código a nivel de pull request — antes de que el código llegue a la rama principal
• Participación de QA desde los requisitos — no introducido al final para verificar lo que los desarrolladores ya construyeron

Pídele al proveedor que describa qué sucede entre que un desarrollador termina una funcionalidad y esa funcionalidad llega a producción. Cada paso que no pueden nombrar es una brecha.

Cuando el QA está integrado de esta manera — usando agentes automatizados para auditar el código y ejecutar ciclos de prueba en tiempo real — los resultados son medibles. En un proyecto de salud reciente de CodeBranch, este flujo de trabajo exacto produjo una reducción del 85% en las tasas de rechazo de QA. El pipeline detectó los defectos antes de que llegaran a la revisión humana, lo que liberó al analista de QA para concentrarse en los casos extremos que realmente requieren juicio.

8. ¿Cómo incorporan la IA en su proceso de desarrollo — y qué significa eso para la velocidad de entrega?

Esta pregunta separa a los proveedores que han pensado seriamente en la IA de los que la mencionan en su presentación sin cambiar cómo trabajan realmente.

La pregunta relevante no es si usan herramientas de IA — la mayoría de los equipos de desarrollo lo hacen en este punto. La pregunta relevante es si la IA está integrada en el pipeline de una manera que produce diferencias medibles en la velocidad de entrega y la calidad del output, o si se usa de forma ad hoc por desarrolladores individuales sin estándares compartidos.

Un proveedor que ejecuta un pipeline de desarrollo agentic — donde los agentes de IA operan dentro de un flujo de trabajo CI/CD estructurado, con puertas de calidad que detectan patrones de falla específicos de la IA antes de la revisión humana — entregará de manera diferente que un proveedor donde un desarrollador ocasionalmente usa un asistente de código. La Encuesta a Desarrolladores de Stack Overflow 2025 encontró que el 66% de los desarrolladores cita las soluciones de IA que son “casi correctas, pero no del todo” como su mayor frustración. Las herramientas que operan sin un pipeline estructurado a su alrededor producen ese resultado consistentemente.

Para un proyecto CRM o ERP, donde el plazo de entrega afecta directamente cuándo el negocio puede operar en el nuevo sistema, esta pregunta tiene una respuesta financiera real. Pide un ejemplo concreto: un proyecto reciente donde su proceso de IA cambió lo que pudieron entregar, y en qué medida.

9. ¿Qué pasa si el proyecto tarda más o cuesta más de lo proyectado?

Esta pregunta hace sentir incómodos a algunos proveedores — y esa reacción vale la pena notar.

Los sobrecostos y el retraso en los cronogramas son suficientemente comunes en los proyectos CRM y ERP como para que la pregunta no sea si podrían ocurrir — es quién absorbe el impacto cuando lo hacen. Algunos proveedores construyen contratos que transfieren la mayor parte de ese riesgo al cliente a través de facturación abierta de tiempo y materiales. Otros ofrecen compromisos de precio fijo con alcance claramente definido, donde el proveedor es responsable de entregar lo que se acordó sin recargar por sus propios errores de estimación.

Pregunta al proveedor directamente: si el proyecto se extiende un 20% más del cronograma original, ¿qué pasa con el presupuesto? Si la respuesta implica horas facturables por trabajo que debería haber estado en el alcance original, esa es una pregunta de modelo de precios disfrazada de pregunta de riesgo del proyecto.

Los proveedores que se desempeñan bien en esto son los que invierten en un descubrimiento exhaustivo antes de fijar precios — no los que ofrecen la cotización inicial más baja.

10. ¿Cómo se ve la entrega al final del compromiso — y qué podré hacer de forma independiente cuando termine?

Esta pregunta revela si un proveedor construye independencia o dependencia.

Un proveedor que entrega un sistema funcionando pero deja al cliente incapaz de mantenerlo, extenderlo o entenderlo ha creado un tipo diferente de bloqueo — no contractual, sino práctico. El cliente termina de vuelta con el mismo proveedor para cada cambio, cada error, cada nueva funcionalidad, porque nadie más puede navegar lo que se construyó.

Pregunta específicamente:

• ¿Qué documentación se entrega al final del compromiso?
• ¿Está el código base estructurado para que otro equipo pueda retomarlo?
• ¿Qué formación o transferencia de conocimiento está incluida?
• ¿Hay un runbook para operar y mantener el sistema?

Un proveedor que responde estas preguntas claramente — con detalles sobre entregables, estándares de documentación y qué podrá hacer el equipo del cliente de forma independiente — es un proveedor cuyos intereses están alineados con los tuyos después de que termine el contrato, no solo durante él.

Qué Te Dicen las Respuestas

Ninguna pregunta en esta lista es definitiva por sí sola. Lo que buscas es un patrón.

Un proveedor que tiene respuestas claras sobre la propiedad de IP, un proceso estructurado previo al compromiso, verificaciones de calidad integradas y documentación honesta de lo que tendrás al final — es un proveedor que ha construido su práctica alrededor de entregar proyectos, no solo de ganarlos.

Lo inverso también es cierto. Respuestas vagas sobre la propiedad, un precio que llegó antes de cualquier descubrimiento real, el QA descrito como una fase final y ninguna respuesta clara sobre cómo se ve la entrega — cada uno de esos podría ser explicable individualmente. Juntos describen a un proveedor cuyo proceso está optimizado para firmar contratos, no para completarlos.

CodeBranch es una boutique de desarrollo de software agentic con sede en Medellín, Colombia, especializada en pipelines de desarrollo optimizados por IA para equipos de producto en los Estados Unidos. Nos hemos aplicado estas preguntas a nosotros mismos — porque el mismo estándar que hace a un proveedor digno de contratar es el estándar que querríamos que se nos aplicara. Nuestro proceso previo al compromiso está documentado y es público. Si estás evaluando un socio de desarrollo de CRM o ERP y quieres poner estas preguntas a trabajar, empieza por ahí.

Escrito por Jorge A. Mora, Co-fundador de CodeBranch — Medellín, Colombia.