Elegir mal a la empresa que va a construir tu próximo sistema cuesta caro. Caro en plata, caro en meses perdidos y caro en confianza interna del equipo. Lo más costoso de un proyecto fallido no es el dinero pagado al proveedor que no entregó: es el tiempo que tu empresa estuvo paralizada esperando una solución que no llegó.
En este checklist te dejamos los criterios que usamos para evaluar a un proveedor de desarrollo de software a medida en Chile, redactados desde la vereda del cliente. Sirve igual si nos estás evaluando a nosotros o a cualquier otra empresa.
Lo primero: descartá a los rojos
Antes de comparar, descarta sin culpa cualquier proveedor que muestre estas señales:
- Cotiza sin diagnóstico. Si te tiraron un precio en la primera reunión sin entender tu operación, no están vendiendo software a medida. Están vendiendo horas o un producto enlatado disfrazado.
- No tiene casos verificables. Pide nombres de clientes y, si es posible, llama a uno. Una empresa seria con varios años en el mercado tiene clientes dispuestos a hablar.
- El equipo es 100% subcontratado. Subcontratar puntualmente está bien, pero un proveedor que no tiene a nadie suyo en el proyecto es solo un broker que multiplica tu riesgo.
- No firma SLA ni define mantenimiento por escrito. Si después del go-live “vemos cómo seguimos”, vas a quedar atado o desamparado.
- Promete plazos sospechosamente cortos. Si todos cotizan 6 meses y uno te dice 2, no es porque sea más eficiente: es porque no entendió el alcance o piensa entregarte algo a medio hacer.
- Te presiona con descuentos por firmar rápido. Las tácticas comerciales agresivas son de empresas que viven de cerrar al lead, no de servir al cliente.
Con eso ya filtras al 60% del mercado.
El checklist de evaluación
1. Casos similares al tuyo
No alcanza con que tenga “muchos proyectos”. Pregunta específicamente: “¿Han hecho un proyecto del tamaño y complejidad del que les estoy pidiendo?” Una empresa que solo ha hecho landing pages no debería liderar tu ERP, y viceversa.
Pide ver 2-3 casos similares con: problema original, solución entregada, plazo real (no el cotizado), tecnologías usadas y resultado de negocio. Si no pueden mostrarlo, no tienen.
2. Proceso de trabajo definido
Pregunta cómo trabajan. Una empresa profesional te describirá:
- Fase de diagnóstico (cuántas horas, qué entregables)
- Cómo definen alcance y proponen 2-3 opciones de inversión
- Cadencia de reuniones con el cliente (semanal, quincenal)
- Cómo manejan cambios de alcance (siempre van a haber)
- Cómo es el go-live y qué incluye el período de garantía
- Cómo se estructura el mantenimiento posterior
Si la respuesta es “vamos viendo en el camino”, corre.
3. Equipo identificable
Pregunta quién va a liderar tu proyecto y quién va a programar. Idealmente conoce a esas personas antes de firmar. En empresas chiquitas con un equipo de 3-8 personas suele ser fácil; en agencias grandes a veces te muestran al PM estrella en la venta y después te asignan a un junior. Pide compromiso por escrito de quién está asignado.
4. Stack tecnológico actual
No es necesario que sepas lo que cada palabra significa, pero sí que el stack propuesto no sea anticuado. A 2026, lo razonable para sistemas nuevos:
- Frontend: React, Vue, Astro, Next.js
- Backend: Node.js (Fastify, Express, NestJS), .NET, Python (FastAPI), Java moderno
- Base de datos: PostgreSQL, MySQL/MariaDB, MongoDB para casos específicos
- Mobile: React Native, Flutter o nativo
- Hosting: Cloud (AWS, GCP, Azure) o VPS bien gestionado, Cloudflare, Vercel
Si te proponen tecnologías de los 2010 sin justificación clara (PHP nativo sin framework, jQuery, ASP.NET WebForms para un sistema nuevo), pide explicación. A veces hay razones válidas, pero la regla es que el proveedor pueda defender técnicamente la decisión.
5. Propiedad del código
El código debe quedar en un repositorio al que tú tengas acceso desde el día uno. GitHub, GitLab o Bitbucket en cuenta tuya o compartida, no en una cuenta privada de la empresa. Si no aceptan esa condición, no firmes.
Pregunta también por la documentación: README, documentación técnica, manual de despliegue. Si te entregan un sistema sin documentación, dependes para siempre del proveedor.
6. Plan de mantenimiento por escrito
Antes de firmar el desarrollo, define el mantenimiento. ¿Cuántas horas mensuales incluye? ¿Qué SLA tiene (respuesta en 4 horas, 24 horas, 72 horas)? ¿Quién paga las correcciones de bugs en el primer año? ¿Cómo se cobran nuevas funcionalidades?
Una empresa seria te entrega esa propuesta junto con la del desarrollo, no después de que lanzaste.
7. Integración con tu equipo
¿Hablan tu idioma? Si tu equipo no es técnico, el proveedor debe traducir. Si trata a tu jefa de operaciones como si fuera ingeniera, va a haber malentendidos costosos. Evalúa la primera reunión: ¿salieron sintiendo que entendieron y los entendieron, o que asintieron sin captar la mitad?
8. Manejo financiero
Cómo cobran importa. Cuidado con dos extremos:
- 100% por adelantado: demasiado riesgo para ti.
- Mensualidades fijas sin hitos: si la empresa quiebra o se va, perdiste todo.
Lo razonable: hitos contra entregables, con pagos asociados a aprobaciones del cliente. Una estructura típica es 20-30% al inicio, 40-50% repartido en hitos intermedios, y 20-30% al go-live.
Las preguntas que debes hacer en la primera reunión
Lleva esta lista escrita y haz cada pregunta sin pena. Si la empresa se incomoda, ya tienes tu respuesta.
- ¿Cuántos años llevan operando? ¿Qué tamaño tiene el equipo?
- ¿Pueden mostrarme 2-3 proyectos similares al mío con resultados?
- ¿Quién va a liderar mi proyecto y quién va a desarrollar?
- ¿Qué stack proponen y por qué?
- ¿Cómo manejan los cambios de alcance?
- ¿Cómo es el período de garantía después del go-live?
- ¿Qué incluye el mantenimiento y cuánto cuesta?
- ¿Dónde queda el código? ¿Qué documentación entregan?
- ¿Cuál es la forma de pago propuesta?
- ¿Pueden conectarme con un cliente actual para que les pregunte?
Si responden con claridad las 10, son candidatos serios. Si esquivan dos o más, sigue buscando.
Errores típicos del lado del cliente
No todo lo malo es culpa del proveedor. Estos errores los cometen los clientes y arruinan proyectos buenos:
- Elegir solo por precio. El más barato no suele ser el mejor, especialmente en software.
- No participar. Si no asignas tiempo a las reuniones de definición, el proveedor adivina y se equivoca.
- Cambiar el alcance sin acordar plazos ni costos extra. Cada cambio tiene impacto. Acéptalo y negocialo.
- No leer la propuesta entera. Lee la letra chica, las exclusiones, los plazos de pago.
- Tomarse demasiado tiempo en aprobaciones. Si tardas 3 semanas en aprobar un wireframe, el proyecto se descalabra.
Empresas grandes vs chicas
¿Mejor una agencia grande con 50+ personas o una empresa más chica con 5-15? No hay respuesta universal:
- Agencia grande: más estructura, más recursos, mayor capacidad de absorber rotación. Pero suele ser más cara, menos flexible y a veces el cliente mediano queda como un proyecto B en su pipeline.
- Empresa mediana especializada: más cerca, más involucrados, mejor relación calidad-precio para proyectos medianos. Riesgo si pasa algo con el equipo principal.
Para una mediana chilena en proyectos de USD 15.000-100.000, una empresa especializada del tamaño correcto suele entregar mejor relación valor-precio. Para proyectos enterprise sobre USD 200.000 con cumplimientos regulatorios fuertes, una agencia grande tiene más espalda.
Sobre Codelan
Codelan es una empresa chilena que desarrolla software a medida y automatización de procesos. Trabajamos con un proceso de 11 etapas que incluye diagnóstico, demo, propuesta con 3 opciones, desarrollo, deploy, manual y soporte. Cada proyecto tiene un equipo asignado y todo el código queda en repositorio del cliente.
Si quieres evaluarnos contra otros proveedores, agenda un diagnóstico de 45 minutos. El diagnóstico es gratuito y te entregamos una propuesta con tres opciones de inversión.
Conclusión
Elegir bien una empresa de desarrollo de software no es magia: es checklist disciplinado y preguntas directas. Filtra los rojos, evalúa con criterios claros, pide referencias y escucha a tu instinto en la primera reunión. Si después de cumplir todo eso aún tienes dudas, contrata por una primera fase chica (un MVP, una prueba de concepto) antes del proyecto completo. Es la mejor manera de probar al proveedor sin jugarte el flujo de caja.
