Cómo elegir una software house y en qué fijarte

Al elegir una software house, comprueba tres cosas: la responsabilidad sobre producción, el equipo que realizará el proyecto y las condiciones de entrega del sistema. El portfolio y la tecnología solo ayudan cuando se refieren a una escala, un riesgo y una etapa de vida del producto similares.

Lo escribimos como proveedores, por lo que tienes derecho a desconfiar. Por eso las preguntas siguientes están formuladas para que puedas hacérnoslas también a nosotros y para que una mala respuesta sea reconocible.

Las tres preguntas que más revelan

1. ¿Qué mantenéis hoy en producción y cómo os enteráis de una caída?

«Hemos hecho» y «mantenemos» son competencias diferentes. Preguntar por un sistema en funcionamiento permite evaluar la monitorización, la respuesta a incidentes, las copias y la responsabilidad tras el lanzamiento: elementos poco visibles en un portfolio.

Una buena respuesta es concreta: qué alcance mantiene el proveedor, cómo supervisa el servicio, quién responde, en qué plazo y qué sigue siendo responsabilidad del cliente. La confidencialidad puede impedir dar el nombre del proyecto, pero no debería impedir describir el proceso.

Un ejemplo nuestro es la plataforma analítica basada en TimescaleDB: un sistema desplegado en un VPS, con colectores que trabajan de forma continua, monitorización e informes periódicos. La monitorización debe detectar interrupciones, no prometer una disponibilidad del cien por cien.

2. ¿Quién escribirá exactamente mi código?

La pregunta se refiere a la transparencia del modelo de entrega. Un equipo interno, socios y subcontratistas pueden obtener un buen resultado si se sabe quién responde de la arquitectura, la revisión de calidad, la continuidad y los derechos sobre el código producido.

Pregunta además: ¿la persona que lleva la conversación comercial participará en el proyecto? ¿Cuántos proyectos lleva a la vez? ¿Quién tomará el relevo si esa persona se va de vacaciones?

3. ¿Cómo es la separación?

Es fácil pasar por alto esta pregunta, aunque las condiciones de salida determinan tu dependencia del proveedor. Revisa la salida con el mismo cuidado que la entrada. Al terminar la colaboración, ¿qué recibes?

• un repositorio con historial y derechos sobre el código creado para el cliente, además de la lista de licencias de las dependencias;
• acceso al servidor, dominio y servicios clave en cuentas del cliente, o un procedimiento documentado para transferirlos;
• la documentación necesaria para que otro equipo pueda ejecutar y asumir el alcance acordado;
• los datos en un formato exportable.

Las cuentas de los servicios clave deberían pertenecer al cliente o tener un procedimiento de transferencia acordado. Si por razones operativas el proveedor administra el acceso, el contrato debe describir cómo recuperar el control y exportar los datos.

Nueve preguntas complementarias

4. ¿Cómo presupuestáis y qué ocurre si cambia el alcance? La respuesta «ya avisaremos» aumenta el riesgo de conflicto. Debe acordarse un procedimiento para cambiar el alcance.
5. ¿Qué incluye el «despliegue»? Aclara quién responde de la monitorización, las copias de seguridad, una restauración probada, los certificados y la respuesta a incidentes. La ausencia de estos puntos puede significar un piloto o trasladar obligaciones al cliente; debe ser explícito.
6. ¿Con qué frecuencia veré una versión funcional? Aceptar el trabajo solo al final eleva el coste de detectar tarde las diferencias. Acordad un ritmo de demostraciones ajustado a la duración del proyecto y los momentos en que aún se puede cambiar de dirección.
7. ¿Qué pasa si, tras dos semanas, vemos que la idea debe cambiar? Compruebas si el proceso contempla aprender durante el trabajo.
8. ¿Cómo probáis? No se trata de una lista de herramientas, sino de si la lógica de la que depende el dinero tiene pruebas automáticas y de si alguien las ejecuta antes del despliegue.
9. ¿Quién decide la arquitectura por vuestra parte? Quieres saber si hay una persona responsable de la coherencia o si cada cual programa a su manera.
10. ¿Cómo es el mantenimiento y cuánto cuesta? Pide un alcance de responsabilidad y tiempos de respuesta, no un genérico «estaremos disponibles».
11. ¿Dónde se tratarán nuestros datos? En proyectos con IA es una pregunta especialmente importante; la desarrollamos en seguridad de datos al implantar IA.
12. ¿Podéis describir un proyecto difícil y contar qué cambiasteis en el proceso? El proveedor quizá no pueda revelar al cliente, pero debería describir de forma concreta el problema, la decisión y la salvaguarda implantada. Pide una referencia solo con autorización de quien la emite.

Siete señales de alarma

• Presupuesto sin supuestos explícitos. Un intervalo inicial tras un solo correo puede servir para cualificar, pero una oferta vinculante debe describir alcance, exclusiones y el procedimiento de cambio.
• No hacen preguntas sobre el resultado ni los riesgos. Comprueba si el proveedor entiende el problema, los datos, las integraciones y el coste del error, no solo una lista de funciones.
• No hay comprobación técnica antes de comprometerse. Un comercial puede llevar la conversación, pero la viabilidad y los supuestos relevantes deben revisarlos quienes tengan responsabilidad técnica.
• El código y los accesos clave están solo en manos del proveedor y no hay procedimiento de entrega. Véase el tercer punto.
• El stack como único argumento. «Usamos la última tecnología» no responde a tu problema.
• Una fecha sin margen. Prometer «seguro en cuatro semanas» sin reservas indica que nadie ha calculado los riesgos.
• No existe una forma de acordar el alcance. No todo proyecto pequeño necesita un discovery completo, pero antes de programar deben existir al menos criterios de aceptación, supuestos y una persona dueña de las decisiones. Si la incertidumbre es mayor, proponemos discovery.

¿Proveedor grande o pequeño?

No hay una única respuesta. Las diferencias siguientes son modelos organizativos frecuentes, no garantías derivadas del tamaño de la empresa:

	Estudio pequeño	Software house grande
Contacto con una persona técnica	a menudo directo	depende de la composición del proyecto
Cambio de alcance	puede ser rápido, pero menos formalizado	suele tener un proceso formal
Continuidad del equipo	revisa el plan de sustitución y la documentación	revisa la rotación y la garantía de composición
Procedimientos y SLA	pueden adaptarse individualmente	suelen estar estandarizados
Adecuación al proyecto	depende de las competencias y la disponibilidad	depende de las competencias y del tamaño mínimo de contrato

En un estudio pequeño, uno de los riesgos puede ser depender de una sola persona; por eso conviene preguntar por sustitución, documentación y forma de entrega. En nuestro modelo, el repositorio se entrega al cliente en el alcance establecido por contrato; también acordamos para cada proyecto la propiedad de las cuentas y el procedimiento de transferencia de accesos clave. Cualquier traspaso sigue necesitando tiempo para conocer el sistema.

Qué no comprobar

Tres cosas que ocupan mucho espacio en las conversaciones y dicen poco:

• El número de proyectos por sí solo. Cien sitios web corporativos son una prueba débil de la capacidad de crear un sistema con otro riesgo y escala; revisa la similitud de alcance y la responsabilidad sobre producción.
• La lista de tecnologías en la web. Escribir un nombre en el pie de página no cuesta nada.
• El tamaño total del equipo por sí solo. Pregunta por las personas asignadas a tu proyecto, su disponibilidad, responsabilidad y plan de sustitución. El número total de empleados no responde a esas preguntas.

Preguntas frecuentes

¿Merece la pena pagar por un presupuesto?

Una conversación inicial y un intervalo de precio pueden ser gratuitos. Otro producto distinto es el análisis que crea un alcance, una arquitectura o un plan que puede utilizarse independientemente del proveedor. Con nosotros la conversación y el presupuesto son gratuitos; el discovery es de pago.

¿Cómo comparar ofertas que difieren varias veces en precio?

Primero por alcance, supuestos y responsabilidad; solo después por precio. La diferencia suele venir de entender de forma distinta las mismas palabras y de si la oferta incluye llevar el producto a producción. Lo desglosamos en cuánto cuesta una aplicación web.

¿Y si ya tengo proveedor y algo no funciona?

Empieza por tres cosas: dónde está el repositorio, en qué cuentas están los accesos y qué está desplegado exactamente en producción. Las respuestas a estas preguntas definen tus opciones reales.

---

Antes de empezar un proyecto, pide un equipo explícito, responsabilidad sobre la revisión de código y condiciones de entrega. Consulta nuestro proceso, el stack y las aplicaciones creadas desde cero, o haznos esas doce preguntas.