Qué buscar en un proveedor de desarrollo de software en México

Hay cientos de empresas de desarrollo de software en México. Todas prometen calidad, velocidad y resultados. Diferenciarse en la etapa de evaluación es difícil, porque las promesas se parecen. Lo que revela la diferencia real son los criterios correctos de evaluación — y la mayoría de las empresas no los usa.

Esta guía está escrita para directores de TI, CTOs y CEOs que necesitan tomar esta decisión con más criterio que solo "el precio y la presentación".

1. Proyectos en producción, no proyectos entregados

La distinción más importante que puede hacer es preguntar: ¿cuántos de sus proyectos actuales están operando en producción bajo su responsabilidad?

Entregar código es una cosa. Mantener una plataforma en producción — con usuarios reales, carga real, bugs inesperados y requerimientos que evolucionan — es completamente diferente.

Un proveedor con 200 proyectos "entregados" pero sin ninguna responsabilidad posterior no tiene los mismos incentivos ni la misma madurez operativa que un proveedor con 40 plataformas activas que opera y mantiene mensualmente.

Pregunta concreta: ¿Cuántas plataformas están actualmente bajo su operación y mantenimiento activo? ¿Puedo hablar con los directores de TI de 2-3 de esas empresas?

2. El equipo que trabajará en su proyecto, no el equipo de ventas

Es común en la industria que el equipo de ventas incluya al CTO, el arquitecto más senior y los ingenieros más experimentados en las presentaciones de propuesta. El equipo que realmente construye su plataforma es diferente.

Antes de firmar, exija conocer al equipo asignado a su proyecto:

• ¿Quién será el Tech Lead? ¿Cuántos años de experiencia tiene? ¿Puede ver su perfil en LinkedIn?
• ¿Cuántos ingenieros trabajarán en su proyecto? ¿Son dedicados o comparten tiempo con otros proyectos?
• ¿Qué pasa si un ingeniero clave renuncia durante el proyecto? ¿Hay un proceso de transferencia de conocimiento?

Un proveedor que no puede presentarle al equipo antes de la firma, probablemente subcontrata o rota personal constantemente.

3. Metodología observable, no solo declarada

Todos dicen que usan metodología ágil. Eso ya no es diferenciador — es el piso mínimo. Lo que importa es cómo la ejecutan:

• ¿Con qué frecuencia entregan algo funcional? Debe ser cada 1-2 semanas, no al final del proyecto.
• ¿Cómo manejan cambios de alcance? ¿Hay un proceso formal de change request o es una negociación cada vez?
• ¿Cómo se comunican los riesgos técnicos? ¿Hay reuniones regulares donde el equipo técnico habla directamente con su empresa, o todo pasa a través de un gerente de proyecto?
• ¿Cómo se mide el avance? ¿Por funcionalidades entregadas y probadas, o por "porcentaje completado"?

El porcentaje completado es la métrica más inútil en desarrollo de software. Un sistema puede estar "90% completado" por meses. Lo que importa es cuántas funcionalidades están en producción y funcionando.

4. Capacidad de AI-Assisted Engineering

En 2026, un proveedor que no usa inteligencia artificial en su ciclo de desarrollo está entregando resultados más lentos y más caros que sus competidores. Esto no es hype: es una ventaja operativa real.

Preguntas para evaluar esta capacidad:

• ¿Cómo usan IA en el desarrollo diario? No basta decir "usamos Copilot". ¿Hay IA en la revisión de código, en la generación de pruebas, en el análisis de arquitectura?
• ¿Cuánto tiempo tardan en llegar al primer entregable funcional? Los equipos AI-assisted llegan a un MVP en 4-8 semanas. Los equipos tradicionales tardan 3-6 meses.
• ¿Tienen un proceso de QA automatizado? La IA debe generar y ejecutar pruebas automáticamente, no depender solo de testing manual.

Un proveedor que no puede explicar concretamente cómo la IA reduce sus tiempos y errores, probablemente no la está usando de forma significativa.

5. Modelo de soporte con SLA real

El soporte post-entrega es donde la mayoría de las relaciones proveedor-cliente se deterioran. El proveedor que entregó el proyecto pasa a nuevos proyectos, y el cliente queda con un sistema que nadie atiende con urgencia.

Exija un SLA (Service Level Agreement) antes de firmar:

| Tipo de incidencia | Tiempo de respuesta máximo | |---|---| | Crítica (sistema caído, datos comprometidos) | 2 horas | | Alta (funcionalidad principal degradada) | 8 horas | | Media (bug funcional sin afectar operación crítica) | 24 horas | | Baja (mejora, bug cosmético) | 72 horas |

Si el proveedor no puede comprometerse con tiempos específicos, no tiene la capacidad operativa para soportar sistemas críticos.

También pregunte: ¿el soporte está incluido en el precio mensual o es un costo adicional?

6. Transparencia financiera y modelo de contratación justo

Hay señales de alerta financieras que indican que la relación puede ser problemática:

Pagos muy adelantados: Un proveedor que pide el 60-70% del total antes de empezar no tiene incentivo de entregar a tiempo. El modelo sano es pago por hitos verificables (25% inicio, 25% MVP funcional, 25% versión completa, 25% post-entrega estable).

Alcance ambiguo con precio fijo: El precio fijo sin alcance muy detallado garantiza disputas. Los cambios inevitables del proyecto se convierten en negociaciones donde el proveedor siempre tiene la ventaja.

Sin cláusula de propiedad del código: El código generado debe ser propiedad de su empresa desde el primer día, no al final del proyecto o solo si se completa el pago total.

Sin proceso de salida: ¿Qué pasa si quiere cambiar de proveedor? ¿Recibirá todo el código, la documentación, las credenciales de infraestructura? Un proveedor que no define esto explícitamente está creando lock-in por diseño.

7. Alineación cultural e industrial

El último criterio es más difícil de medir pero igualmente importante: ¿el proveedor entiende su industria y su contexto de negocio?

Un equipo que ha construido plataformas fintech anteriormente entiende los requerimientos regulatorios, los patrones de seguridad necesarios y los flujos de usuario específicos del sector. Uno que no tiene esa experiencia aprenderá a su costo — literalmente.

Preguntas para evaluar esto:

• ¿Han construido algo similar a lo que necesito? No en tecnología, sino en lógica de negocio.
• ¿Entienden mi proceso sin que tenga que explicar todo desde cero? Un proveedor con experiencia en su industria hace preguntas más inteligentes desde la primera reunión.
• ¿Pueden identificar riesgos técnicos específicos de mi dominio? El equipo fintech que no menciona AML en un onboarding de clientes, probablemente no tiene la experiencia que dice tener.

Cómo estructurar el proceso de evaluación

Un proceso de evaluación bien estructurado tiene tres fases:

Fase 1 — Filtro inicial (2-3 proveedores)

• RFP con alcance funcional básico
• Referencias verificables de proyectos similares
• Presentación del equipo asignado (no solo de ventas)

Fase 2 — Evaluación técnica

• Workshop de 2-4 horas donde el equipo técnico del proveedor analiza su arquitectura actual y propone enfoque
• Esto le muestra cómo piensan, no solo lo que dicen que harán

Fase 3 — Negociación contractual

• Alcance detallado en documento técnico antes de firmar
• SLA explícito
• Cláusulas de propiedad de código y salida
• Modelo de pago por hitos, no por adelantado

Si quiere evaluar si Newsoft cumple estos criterios para su proyecto específico, agende una sesión de 45 minutos con nuestro equipo técnico.