Saltar al contenidoEasyByte

Guías

Qué preguntar antes de contratar un desarrollo a medida (y qué respuestas son mala señal)

Estás a punto de encargar un software a medida. Una herramienta para gestionar lo tuyo, una app, la plataforma sobre la que vendes. Has pedido presupuesto a un par de sitios, te han contestado con números y palabras que suenan bien, y ahora te toca elegir sin tener ni idea de si te están haciendo un buen trabajo o vendiéndote humo. Es normal que dé respeto: vas a firmar algo caro que no puedes revisar por dentro.

La buena noticia es que no hace falta que lo revises por dentro. Lo que decide si un desarrollo va a salir bien o a darte disgustos casi nunca es la tecnología. Es cómo trabaja quien lo construye, y eso sí lo puedes preguntar.

Respuesta corta

Las preguntas que te protegen no son técnicas: son sobre cómo trabajan. Antes de firmar, pregunta cinco cosas y escucha bien las respuestas: quién va a construirlo de verdad, cómo te lo presupuestan, cada cuánto vas a ver algo que puedas probar, de quién es el código cuando terminéis y qué pasa el día que ellos ya no estén.

Ninguna requiere que sepas programar. Y las respuestas te dicen más de con quién estás hablando que cualquier portfolio o cualquier lista de tecnologías. Si alguien esquiva estas cinco, o te contesta con vaguedades, ya tienes tu respuesta aunque no sepas nada de código. El resto de esta guía es para que sepas qué contestación tranquiliza y cuál debería hacerte dudar.

¿Por qué no van de tecnología?

Porque las preguntas técnicas no te sirven para decidir. Si preguntas "¿en qué lenguaje lo vais a hacer?" y te contestan "TypeScript y Next.js", tú no puedes saber si eso está bien o mal para tu caso. Te quedas igual, pero con la sensación de haber preguntado algo.

Las preguntas que sí funcionan miden otra cosa: si tienes delante a gente que va a responder de lo que construye, o a un comercial que desaparece en cuanto firmas. Eso lo puede juzgar cualquiera. Y es justo lo que separa un proyecto que acaba en producción de uno que se estira, se encarece y termina en un código que nadie se atreve a tocar.

Vamos con las cinco. Primero en una tabla para que la tengas a mano, y luego con detalle.

Las cinco preguntas que sí importan

PreguntaRespuesta que tranquilizaMala señal
¿Con quién voy a hablar durante el proyecto?Con quien construye. Sin comercial de por medio."Te asignaremos un gestor de cuenta" y el que sabe no aparece.
¿Cómo me lo presupuestáis?Cerrado por fases, con alcance concreto por fase.Por horas sin techo, o un número global sin desglose.
¿Cada cuánto veré algo funcionando?Cada pocas semanas hay algo que puedes probar."Te lo enseñamos cuando esté terminado."
¿De quién es el código al acabar?Tuyo, en tu repositorio, con documentación.Se queda en su plataforma o su servidor.
¿Qué pasa cuando terminéis?Cualquier desarrollador serio puede continuarlo."Solo nosotros sabemos cómo funciona."

Cada fila va de lo mismo: ¿este proyecto va a depender de una persona concreta que responde, o de una caja negra que no controlas?

Con quién hablas importa porque en muchos sitios la persona que te vende no es la que programa. Te encandila un comercial, firmas, y a partir de ahí hablas con juniors que rotan y con un gestor que hace de intermediario entre tú y el que de verdad toca el código. Cada pregunta tuya pasa por tres manos y vuelve peor. Si desde el primer email respondes tus dudas técnicas con quien las va a resolver, ya has ganado la mitad.

Cómo te lo presupuestan es el punto donde más gente sale escaldada, y lo vemos aparte porque merece su ejemplo.

Cada cuánto ves algo es tu único control real sobre un proyecto que no entiendes por dentro. Si cada dos o tres semanas puedes tocar algo que funciona, te das cuenta pronto si van por buen camino o si lo que están construyendo no es lo que tú tenías en la cabeza. Si te dicen que lo verás al final, estás firmando a ciegas durante meses.

De quién es el código decide si has comprado algo o lo has alquilado sin enterarte. Si el trabajo se queda en el repositorio del proveedor, el día que quieras cambiar de manos no puedes: empiezas de cero. Pide que sea tuyo desde el principio.

Qué pasa cuando terminen es la misma idea mirando al futuro. Un desarrollo bien hecho lo puede coger otro y seguirlo. Uno hecho con prisa y sin documentar solo lo entiende quien lo escribió, y eso te ata a ellos para siempre, también para las averías.

Las respuestas que son mala señal

Hasta aquí las buenas contestaciones. Ahora las que deberían encender una luz, más allá de la tabla.

  • "Sí, sin problema" a todo. Un proyecto real tiene partes que no se saben todavía. Quien no te pone ni un pero, ni te dice "esto habría que verlo", o no ha entendido lo que necesitas o te está diciendo lo que quieres oír para cerrar.
  • El comercial que no sabe responder nada técnico y te tranquiliza con un "eso ya lo ve el equipo". Si quien te vende no puede explicarte cómo van a abordar tu problema, la distancia entre lo que te prometen y lo que se construye la vas a pagar tú.
  • El presupuesto-globo. Un número redondo y grande, sin desglose y sin fases. No sabes qué estás pagando ni cómo comprobar que avanza. "Depende" a todo tampoco vale: acotar es su trabajo, no el tuyo.
  • "El código está en nuestra plataforma." Suena cómodo. Significa que no es tuyo y que dependes de ellos para cualquier cosa, incluida la factura del mes que viene.
  • Plazos sin margen y sin condiciones. "En seis semanas lo tienes" dicho sin preguntarte apenas nada es una promesa que no pueden sostener. Un plazo honesto viene con un "si el alcance es este" delante.

Ninguna de estas es ilegal ni te van a estafar necesariamente. Pero cada una traslada un riesgo hacia ti. Y el que más dinero mueve es el del presupuesto, así que vamos con números.

¿Y el precio? Un ejemplo con números

Pongamos un caso tipo, sin nombres. Un negocio que necesita una herramienta interna para dejar de gestionar sus pedidos en un Excel que ya se rompe. Pide dos presupuestos.

El primero llega por horas: "estimamos unas 200 horas a 45 € la hora, unos 9.000 €, aunque puede variar según lo que salga". Suena detallado. Pero léelo otra vez: el "puede variar" significa que si el trabajo se alarga, pagas tú. Y las 200 horas no las puedes auditar. No tienes forma de saber si algo llevó ese tiempo o el doble. El riesgo de que el proyecto se estire está entero de tu lado.

El segundo llega cerrado por fases: "primera fase, la gestión de pedidos funcionando, 3.500 € cerrados; cuando la tengas y la pruebes, presupuestamos la siguiente". Aquí el número no se mueve. Si a ellos les lleva el doble de lo que pensaban, es su problema, no tu factura. Y como la primera fase es pequeña, arriesgas poco para ver cómo trabajan antes de comprometer el resto.

El segundo casi siempre te conviene más, y no por el importe (podrían acabar costando parecido). Es por dónde cae el riesgo. Son cifras de ejemplo para que veas la lógica; los números reales dependen de tu proyecto. Lo que no cambia es la pregunta: ¿quién paga si esto se complica? En un presupuesto cerrado por fases, no eres tú.

¿Cómo evalúo una respuesta técnica sin ser técnico?

Te va a pasar: preguntarás algo y te contestarán con palabras que no controlas. No pasa nada, porque no tienes que juzgar el contenido técnico. Tienes que juzgar la forma de la respuesta.

Una buena respuesta a algo técnico casi siempre tiene esta pinta: te explica la decisión en tu idioma, te dice qué gana y qué pierde, y admite lo que todavía no se sabe. "Lo haríamos así por esto, tiene esta pega, y esta parte no la podemos cerrar hasta ver tus datos reales." Eso, aunque no entiendas el detalle, es alguien que ha pensado tu problema.

Una mala respuesta se reconoce igual de fácil: o te abruma con jerga para que no repreguntes, o te lo simplifica tanto que no dice nada. Si sales de la conversación sin haber entendido nada pero con la sensación de que "saben mucho", desconfía. Saber explicarlo simple es parte del oficio.

Al final, todas estas preguntas miden lo mismo: si tienes delante a alguien que responde de lo que hace. Nosotros trabajamos así a propósito, con presupuesto cerrado por fases y hablando siempre con quien construye, porque es lo que a nosotros nos gustaría encontrar al otro lado. Si tienes un proyecto en la cabeza y quieres hacer estas preguntas en voz alta antes de decidir, escríbenos a [email protected] y las respondemos sin compromiso.

Preguntas frecuentes

¿Tengo que saber de tecnología para contratar bien un desarrollo?

No. Las preguntas que te protegen no son técnicas: son sobre cómo trabajan. Con quién vas a hablar durante el proyecto, cómo te lo presupuestan, cada cuánto verás algo que puedas probar, de quién es el código al final y qué pasa cuando ellos ya no estén. Todo eso lo puedes evaluar sin saber programar.

¿Es mejor un presupuesto por horas o cerrado?

Para ti, cerrado por fases casi siempre. Por horas, quien paga el riesgo de que el trabajo se alargue eres tú, y el número de horas no lo puedes auditar. Un presupuesto cerrado por fases pone ese riesgo del lado de quien construye: si se pasan, es su problema, no tu factura. La pega es que exige acotar bien el alcance antes de empezar, y eso es justamente lo que quieres.

¿Por qué es importante de quién es el código?

Porque si el código se queda en la plataforma o el repositorio del proveedor, dependes de ellos para siempre. El día que quieras cambiar de manos, empezar de cero o simplemente que otro lo revise, no puedes. Pide que el código sea tuyo, en tu repositorio, con documentación. Es la diferencia entre haber comprado algo y haberlo alquilado sin saberlo.

¿Qué respuesta debería hacerme dudar de un proveedor?

Cualquiera que no tenga un solo pero. Un proyecto real tiene partes que no se saben todavía, decisiones con contras y cosas que dependen de datos que aún no existen. Quien te dice que sí a todo, sin acotar y sin admitir ninguna incertidumbre, o no ha entendido tu problema o te lo está ocultando para cerrar la venta.

Todas las guías