TL;DR: Las preguntas más importantes antes de contratar una empresa de software: quiénes van a trabajar en tu proyecto, cómo manejan los cambios de alcance, a quién pertenece el código, qué incluye la garantía y si podés hablar con clientes anteriores. Esta guía tiene las preguntas exactas y qué respuestas esperás.
Qué preguntar antes de contratar una empresa de software
Evaluar empresas de software es difícil si no sos técnico. No podés revisar el código, no podés testear el proceso y es difícil distinguir una empresa excelente de una mediocre en la reunión inicial.
Esta guía te da las preguntas exactas, qué respuesta esperás de cada una y qué señales de alerta reconocer.
Puntos clave
- Las mejores preguntas no son técnicas: son sobre el proceso, las referencias y la gestión de problemas
- La propiedad del código y las cuentas de tiendas es no negociable y tiene que estar en el contrato
- La forma en que una empresa maneja los cambios de alcance dice mucho de su madurez
- Las referencias de clientes anteriores son la mejor fuente de información — pero solo si podés contactarlos directo
- El precio correcto no es el más bajo ni el más alto: es el que corresponde al alcance y al tipo de proveedor
Las preguntas y qué respuestas buscar
Sobre el equipo
Pregunta: "¿Quiénes específicamente van a trabajar en mi proyecto?"
Respuesta buena: Dan nombres y perfiles concretos: "El proyecto lo va a llevar Juan (tech lead, 6 años), con María en diseño (4 años) y dos devs senior que están terminando otro proyecto y arrancan en 3 semanas."
Señal de alerta: Respuestas vagas como "nuestro equipo de profesionales" o "asignamos según disponibilidad". No podés evaluar un equipo sin conocer a las personas.
Pregunta: "¿Cuántos proyectos simultáneos maneja el equipo que trabaja con vos?"
Respuesta buena: "Trabajamos con máximo 2–3 proyectos simultáneos por desarrollador para garantizar calidad." O: "El equipo de tu proyecto va a ser dedicado exclusivamente."
Señal de alerta: No saben cuántos proyectos tiene cada persona, o mencionan una cantidad que parece irreal.
Sobre la propiedad y el acceso
Pregunta: "¿El repositorio de código va a estar en una cuenta mía desde el inicio?"
Respuesta buena: "Sí, creamos el repositorio en tu GitHub/GitLab desde el primer día y vos tenés acceso de administrador."
Señal de alerta: "Al final del proyecto te entregamos el código" o cualquier variante que implique que el acceso es posterior al pago final.
Pregunta: "¿Las cuentas de App Store y Google Play van a estar a nombre de mi empresa?"
Respuesta buena: "Sí, vos creás las cuentas o las tenés que tener antes de publicar. Nosotros necesitamos acceso de developer para publicar, no la propiedad de la cuenta."
Señal de alerta: "Nosotros manejamos eso" sin aclarar que la cuenta queda a nombre del cliente.
Sobre el proceso de trabajo
Pregunta: "¿Cómo funciona el proceso de comunicación durante el proyecto?"
Respuesta buena: Mencionan un canal principal (Slack, Teams), la frecuencia de reuniones de seguimiento (semanal), quién es el punto de contacto del lado de ellos y qué tiempo de respuesta esperan.
Señal de alerta: "Nos comunicamos por email cuando hay algo" o no tienen definido quién es el PM del proyecto.
Pregunta: "¿Con qué frecuencia muestran avance funcional?"
Respuesta buena: "Hacemos demos funcionales cada 2 semanas al cierre de cada sprint. Podés ver lo que se construyó y dar feedback antes del siguiente sprint."
Señal de alerta: "Mostramos cuando hay algo para ver" o "al cierre del proyecto". Sin demos parciales, podés llegar al final y encontrarte con algo muy distinto a lo que imaginabas.
Sobre los cambios de alcance
Pregunta: "¿Cómo manejan los cambios de alcance durante el proyecto?"
Respuesta buena: "Tenemos un proceso de change request: cuando surge un cambio, lo documentamos, estimamos el impacto en tiempo y costo, y lo aprobás vos antes de que se implemente. Los cambios no se absorben en silencio."
Señal de alerta: "Lo que vaya surgiendo lo vamos resolviendo" o insinuación de que el alcance es flexible sin proceso claro. El alcance siempre cambia; lo que importa es cómo se gestiona.
Pregunta: "¿Qué pasó en el último proyecto cuando el cliente pidió un cambio importante fuera del alcance original?"
Respuesta buena: Cuentan un caso concreto con cómo lo manejaron: "El cliente quiso agregar un módulo completo a mitad del proyecto. Le presentamos el impacto en tiempo y costo, acordamos posponer una feature del alcance original para no extender el plazo y cerramos un addendum al contrato."
Señal de alerta: No pueden dar un ejemplo concreto, o la historia que cuentan sugiere que absorbieron el cambio sin proceso claro.
Sobre garantías y post-lanzamiento
Pregunta: "¿Qué incluye la garantía post-lanzamiento?"
Respuesta buena: "Cubrimos corrección de bugs de funcionalidades desarrolladas en el proyecto por 60 días desde el lanzamiento, sin costo adicional. Nuevas funcionalidades o cambios de comportamiento intencionados por requerimientos del usuario no están cubiertos."
Señal de alerta: No tienen política de garantía definida, o la garantía es tan vaga que en la práctica no cubre nada.
Pregunta: "¿Qué pasa después del lanzamiento si necesitamos soporte técnico o nuevas funcionalidades?"
Respuesta buena: Tienen un modelo de mantenimiento claro: tarifa fija mensual, banco de horas, o por proyecto. Dan ejemplos de clientes con quienes tienen relación de largo plazo.
Señal de alerta: El modelo post-lanzamiento es difuso o dan la impresión de que no les interesa el trabajo recurrente.
Sobre referencias
Pregunta: "¿Podés darme 2–3 clientes anteriores que hayan tenido proyectos similares para contactar directamente?"
Respuesta buena: Dan nombres, empresa y contacto directo. Sin el proveedor como intermediario.
Señal de alerta: Dudan, piden tiempo para "consultar con el cliente", solo muestran testimonios escritos que no podés verificar, o proponen presentarlos ellos en una reunión conjunta.
⚠️ Atención
Una empresa que no puede darte referencias directas de clientes anteriores después de 2–3 años de actividad, no tiene clientes satisfechos o no confía en lo que dirían. Es la señal de alerta más grave de todas.
Las preguntas sobre el presupuesto
Pregunta: "¿Qué fases están incluidas en este presupuesto?"
Verificá que esté claro si incluye: discovery, diseño UX, diseño UI, desarrollo frontend, desarrollo backend, testing/QA, deploy y publicación en tiendas.
Pregunta: "¿Qué pasa si el proyecto tarda más de lo estimado?"
La respuesta te dice si es precio fijo (ellos absorben el delay) o tiempo y material (pagás más si dura más).
Pregunta: "¿Cómo está estructurado el plan de pagos?"
Un plan de pagos por hitos (porcentaje al inicio, porcentaje en cada entregable, porcentaje al lanzamiento) es más seguro para el cliente que pagos por fechas del calendario.
Tabla resumen de señales positivas vs señales de alerta
| Señal positiva | Señal de alerta |
|---|---|
| Dan nombres concretos del equipo asignado | Hablan de 'nuestro equipo' sin especificar |
| Repositorio en tu cuenta desde el inicio | Te entregan el código al final del proyecto |
| Demos funcionales cada 1–2 semanas | 'Mostramos cuando hay algo para ver' |
| Proceso documentado para cambios de alcance | 'Lo que vaya surgiendo lo resolvemos' |
| Referencias directas de clientes anteriores | Solo testimonios escritos o referencias filtradas por ellos |
| Garantía post-lanzamiento con alcance claro | Sin política de garantía definida |
| Presupuesto desglosado por fases | Precio total sin detalle de qué incluye |
| Plan de pagos por hitos verificables | Pagos por fechas del calendario |
Preguntas frecuentes
- Tres preguntas no negociables: 1) ¿Quiénes específicamente van a trabajar en mi proyecto? 2) ¿El repositorio va a estar en mi cuenta desde el inicio? 3) ¿Podés darme referencias de clientes anteriores para contactar directamente? Las respuestas a estas tres preguntas dicen más sobre la calidad de un proveedor que cualquier presentación comercial.
- Preguntá por comportamientos concretos, no por capacidades abstractas. En lugar de 'tienen metodología ágil?', preguntá '¿cómo fue el último proyecto que tuvieron problemas y cómo lo resolvieron?'. En lugar de '¿son buenos en React Native?', preguntá '¿cuántos proyectos en React Native entregaron en los últimos 12 meses?'. Los ejemplos concretos revelan más que las respuestas genéricas.
- Sí, es normal por confidencialidad. Pero sí podés pedir ver el repositorio de un proyecto de código abierto que hayan construido, o hacer un mini-proyecto de prueba pagado antes de comprometerte al proyecto completo. También podés pedir que el código de tu proyecto esté en tu repositorio desde el inicio, lo que te da visibilidad del trabajo a medida que avanza.
- Es una señal de alerta seria. Una empresa con trabajo real tiene clientes satisfechos dispuestos a dar referencias. Si la empresa tiene pocos años de actividad, puede no tener muchas referencias, pero debería poder darte al menos una o dos. Si se niegan explícitamente o si los clientes que dan no quieren hablar en privado, es mejor seguir buscando.
- Al menos tres, idealmente de perfiles distintos: un freelancer senior, una agencia pequeña y una agencia mediana. Con tres presupuestos tenés el rango real del mercado para tu proyecto específico. Comparar solo dos no te da el contexto suficiente; comparar más de cinco generalmente no agrega información nueva y consume demasiado tiempo.