Dos propuestas para el mismo software no se pueden comparar por el precio mientras no respondan a lo mismo. Una incluye la migración de tus datos y la otra ni la menciona; una te entrega el código y la otra no dice de quién es; una cierra el precio y la otra lo estima. Lo único que se parece es la cifra del final.
Para que se parezcan en algo más hacen falta once preguntas, y el momento de hacerlas es la primera reunión, cuando aún no has firmado nada y preguntar sale gratis. Van en el orden en que suele discurrir esa conversación —qué se va a construir, qué va a costar, de quién será y quién lo hará—, cada una con la respuesta que deberías oír. Y, donde viene al caso, con la que doy yo cuando me la hacen a mí.
Qué se va a construir
¿Qué queda fuera?
La lista de lo que incluye un proyecto siempre parece completa. La que de verdad lo delimita es la otra, la de lo que no incluye: un alcance que solo enumera lo que entra deja abierto todo lo demás. Pide las exclusiones por escrito: qué integraciones no se tocan, en qué dispositivos no tiene que funcionar, qué informes se dejan para más adelante.
¿Cómo sabremos que está terminado?
Cada funcionalidad debería llevar un criterio de aceptación: una frase que los dos podáis comprobar sin discutir. Si la respuesta es «cuando funcione», todavía no hay criterio. Uno de verdad se parece a este:
Dado un pedido con tres líneas y un cupón válido,
cuando el cliente confirma el pago,
entonces el sistema emite la factura, descuenta el stock
y envía el correo de confirmación en menos de un minuto.
Con criterios así, aceptar una entrega deja de ser una cuestión de opiniones.
¿Qué voy a ver, y cuándo?
Cuanto antes pruebes lo construido, antes se corrige el rumbo y más barato sale corregirlo. Pregunta cada cuánto recibirás algo que funcione y dónde podrás probarlo. Hay una respuesta que no quieres oír: «al final».
Yo monto un entorno de pruebas en el primer sprint y entrego cada semana, con su informe de progreso.
Qué va a costar
¿Qué pasa si cambio de idea?
Cambiarás de idea, y no pasa nada: un sistema se entiende mejor cuando se empieza a usar. Lo que importa es qué ocurre entonces. Averigua cómo se pide un cambio, cuánto tarda en presupuestarse y si mueve el calendario.
Como trabajo por sprints de una semana a 1.190 €, cada uno con su alcance y su precio cerrados, un cambio entra en el sprint siguiente sin deshacer el anterior. Si amplía el proyecto, te propongo por escrito los sprints que hacen falta, con su coste, y tú decides si seguimos.
¿Cómo y cuándo se paga?
El calendario de pagos dice quién asume el riesgo: tú, si lo pagas todo por adelantado; quien desarrolla, si cobra todo al final. Lo razonable está en medio: que los pagos acompañen a las entregas y que ninguno adelante mucho más trabajo del que ya has visto.
Mis sprints se facturan en bloques de dos, la mitad al empezar el bloque y la otra mitad al terminarlo; un sprint suelto se paga entero antes de empezar. En ningún caso adelantas más de una semana de trabajo.
¿Qué voy a seguir pagando después?
Un software a medida no termina el día de la entrega: quedan el alojamiento, el dominio, las licencias de los servicios externos, las copias y las actualizaciones de seguridad. Pide la cifra mensual antes de firmar, partida a partida, y pregunta a nombre de quién va cada una. Lo que está a tu nombre te lo llevas; lo que no, depende de otro.
Si el sistema se despliega en tus servidores, conmigo no queda ninguna cuota. Si lo alojo yo, el alojamiento entra en un plan de mantenimiento dimensionado para ese sistema y desglosado en la propuesta.
De quién es
¿De quién es el código?
La respuesta que deberías oír es «tuyo». La ley, sin embargo, no te lo regala. La Ley de Propiedad Intelectual atribuye a la empresa los derechos sobre un programa cuando lo escribe un empleado suyo; de un proveedor externo no dice lo mismo. Con un proveedor, los derechos de explotación son de quien escribe el código hasta que un contrato los cede.
Y esa cesión tiene letra pequeña. Si el contrato no fija un plazo, la ley lo deja en cinco años; si no fija un territorio, lo reduce al país donde se firma. Una cláusula bien hecha cede en exclusiva todos los derechos de explotación, incluido el de modificar el programa, para todo el mundo y por todo el tiempo que la ley permite.
Todo lo que desarrollo y entrego es tuyo: el código completo con su documentación y, si lo quieres, el repositorio a tu nombre. Con el código, el repositorio y los accesos en tu poder, el proyecto sigue con quien tú decidas.
¿Qué dice el contrato, además del precio?
Un contrato de desarrollo no necesita ser largo. Sí necesita tocar estos puntos:
- El alcance, con sus exclusiones y sus criterios de aceptación.
- El precio, el calendario de pagos y qué ocurre si el proyecto se detiene a mitad.
- La cesión de los derechos de explotación, con plazo y territorio.
- La entrega del código fuente, de la documentación y de las credenciales de todos los servicios.
- Las piezas de terceros que lleva el sistema, como las librerías de código abierto, que conservan su propia licencia.
- La confidencialidad de lo que compartes.
- El contrato de encargado del tratamiento que exige el RGPD, si el sistema maneja datos personales.
Lo que cuento aquí es información general del oficio; la redacción de un contrato concreto corresponde a un abogado.
¿Qué documentación voy a recibir?
La documentación útil es la que permite que otro desarrollador retome el trabajo: cómo se despliega el sistema, dónde están los datos, qué configuración pide cada entorno, qué hace cada tarea programada. Más vale una breve y al día que una extensa que nadie mantiene.
Quién lo hace
¿Quién va a escribir el código?
Pregunta quién va a programar el sistema y si podrás hablar con esa persona. Cuando una explicación pasa por varias manos antes de llegar a quien programa, algo se pierde en cada una.
En mi caso no hay manos intermedias: quien analiza el encargo es quien lo construye y quien da la cara después.
¿Qué necesitas de mí?
Un proyecto a medida también te pide tiempo a ti: decidir, aportar ejemplos reales, probar cada entrega. Averigua cuántas horas a la semana y en qué momentos. A mí me basta con una persona de referencia que valide cada entrega; pero esa persona tiene que existir, y tener hueco para hacerlo.
Y ahora, el precio
Vuelve a las dos propuestas del principio. Con las once respuestas de cada una sobre la mesa, o describen lo mismo o se ve dónde se separan, y la cifra del final por fin significa algo: sabes qué compra cada euro.
Si quieres ver precios con su alcance al lado, en Cuatro ejemplos de software a medida cuento cuatro encargos reales con sus semanas y su precio.
La lista, en una página
Las once preguntas, para llevarlas a la primera reunión:
- ¿Qué queda fuera del alcance?
- ¿Cómo sabremos que cada funcionalidad está terminada?
- ¿Qué voy a poder probar, y cada cuánto?
- ¿Qué pasa si cambio de idea?
- ¿Cómo y cuándo se paga?
- ¿Qué voy a seguir pagando después de la entrega, y a nombre de quién?
- ¿De quién es el código, y dónde lo dice el contrato?
- ¿Qué dice el contrato, además del precio?
- ¿Qué documentación voy a recibir?
- ¿Quién va a escribir el código, y voy a poder hablar con esa persona?
- ¿Cuánto tiempo mío va a necesitar el proyecto?
Preguntas frecuentes
¿Qué debe incluir un contrato de desarrollo de software a medida?
Como mínimo, el alcance con sus exclusiones, los criterios de aceptación, el precio y el calendario de pagos, la cesión de los derechos de explotación del código, la entrega del código fuente y de la documentación, la confidencialidad y, si el sistema trata datos personales, el contrato de encargado del tratamiento que exige el RGPD.
¿De quién es la propiedad intelectual de un software hecho por encargo?
De quien lo escribe, salvo que el contrato diga otra cosa. La Ley de Propiedad Intelectual solo atribuye los derechos a la empresa de forma automática cuando el programa lo crea un empleado suyo. Con un proveedor externo hace falta una cláusula de cesión por escrito; si no fija plazo ni territorio, la ley la limita a cinco años y al país donde se firma.
¿Es mejor contratar a un desarrollador por horas o a precio cerrado?
El precio cerrado deja el riesgo de la estimación en quien la hace, que es quien puede controlarlo. Yo presupuesto por sprints de una semana a 1.190 €, cada uno con su objetivo y su precio cerrados: el coste se conoce antes de empezar y el proyecto puede pararse al cierre de cualquiera de ellos.
¿Qué hay que preguntar antes de contratar a un desarrollador de software?
Qué queda fuera del alcance, cómo se comprueba que una entrega está terminada, qué ocurre cuando cambian los requisitos, cuánto costará mantener el sistema después, de quién es el código y con quién vas a hablar durante el proyecto. La lista completa está al final de este artículo.
¿Debo firmar un acuerdo de confidencialidad antes de explicar mi proyecto?
Si para preparar la propuesta hace falta compartir información sensible, es razonable pedirlo. Firmo los acuerdos de confidencialidad que necesites, también antes de la propuesta inicial.
