Adquisición de software a medida: guía del comprador 2026 en 7 pasos
La adquisición de software a medida es el proceso de encargar software a un desarrollador externo: el caso de negocio, el alcance del trabajo, la RFP, la evaluación de proveedores, el contrato y la prueba de aceptación que lo cierra. No es un producto. Es un proceso de compra que diriges tú.
Búscalo en Google y te dará nueve catálogos de herramientas más una página de políticas de la UCLA de 900 palabras. El proceso en sí nadie lo cubre, porque los vendedores de herramientas escriben lo que posiciona. Esta guía responde a la segunda pregunta: ¿cómo compras software que todavía no existe?
Ideas clave:
- La adquisición de software a medida es el proceso de encargar software a un proveedor, no de comprar una herramienta de compras.
- Un proceso completo de adquisición tiene 7 pasos, del caso de negocio a la entrega aceptada, y suele tomar de 10 a 16 semanas antes de desarrollar.
- Nueve cláusulas contractuales protegen tu presupuesto; la propiedad de la PI, los criterios de aceptación y los pagos por hitos son las que más aprietan.
La adquisición de software a medida no es software de compras
El software de compras es una herramienta que automatiza las compras: órdenes de compra, aprobaciones, facturación, catálogos de proveedores. La adquisición de software a medida es el proceso de encargar software a un desarrollador. Uno es un producto que licencias. El otro es un proyecto que diriges, con un contrato y una prueba de aceptación. Esta guía trata del segundo.
La confusión es comprensible: el mercado de herramientas es enorme y está muy cubierto. El directorio de proveedores de Art of Procurement lista más de 200 plataformas en 19 categorías, y la guía de compras 2026 de Brex roza las 4.000 palabras comparando cinco de ellas. Nadie en ese stack explica cómo encargar software desde cero. Ese es el vacío que llena este artículo.
Antes de empezar: ¿de verdad te conviene desarrollar a medida?
Desarrollar a medida es la compra correcta cuando el software es central para tu forma de operar y ningún producto existente encaja en tu flujo de trabajo sin parches. Es la compra equivocada cuando un producto con licencia ya cubre el 80% de la necesidad. Decídelo con honestidad antes de gastar un euro en una RFP de adquisición de software a medida.
| Opción | Gana cuando | Cuidado con |
|---|---|---|
| SaaS listo para usar | La necesidad es genérica (nóminas, CRM, facturación) y un 80% de cobertura basta | Las tarifas por usuario se acumulan; alquilas, nunca eres dueño |
| Personalizar una plataforma | Una plataforma encaja casi toda, y tu caso límite es configuración, no reconstrucción | Deuda de personalización; las actualizaciones rompen tus modificaciones |
| Desarrollo a medida completo | El software es tu proceso, la competencia no puede comprarlo y necesitas la PI | Asumes el riesgo del desarrollo, así que el contrato debe asignarlo |
¿Sigues sin saber en qué fila estás? Nuestro marco de puntuación desarrollar-vs-comprar responde al desarrollar-o-comprar; esta guía responde a la pregunta siguiente, cómo ejecutar la compra una vez que has decidido.
Después, pon el caso de negocio por escrito. Basta con una plantilla de justificación de compra de software de una página:
Problem: What is broken, in one sentence
Current cost: What it costs today (hours per week x rate, or lost revenue)
Outcome: The measurable result the software must produce
Ceiling: The maximum budget, and the date the money runs outIncluso una adquisición de dos personas se beneficia de una política de compras por escrito: un párrafo sobre quién aprueba el gasto y quién firma. Evita el desastre del "el fundador lo aprobó en una llamada" que hunde las aceptaciones.
El proceso de adquisición de software a medida en 7 pasos
El proceso de adquisición de software a medida tiene siete pasos, y seis ocurren antes de que nadie escriba código. El recorrido completo, una línea por paso:
- Necesidad y caso de negocio: demuestra que el problema merece dinero
- Alcance del trabajo (SOW): escribe exactamente qué significa "terminado"
- Escaneo de mercado: preselecciona proveedores que hagan este tipo de trabajo
- RFP / RFQ: envía el mismo brief a todos
- Evaluación de proveedores: puntúa las respuestas con evidencias, no con corazonadas
- Negociación y contrato: pon las nueve cláusulas por escrito
- Entrega y aceptación: prueba contra los criterios del paso 2
Estos rangos son nuestra interpretación de proyectos típicos de pymes, no un benchmark medido: una renovación con proveedor único se resuelve en tres semanas; una licitación regulada tarda seis meses.
| Etapa | Semanas típicas | Artefacto que produce | Quién lo lidera |
|---|---|---|---|
| 1. Necesidad y caso de negocio | 1–2 | Justificación de una página | Tú (comprador) |
| 2. Alcance del trabajo | 2–4 | SOW más criterios de aceptación | Tú, con aporte del proveedor |
| 3. Escaneo de mercado | 1–2 | Lista corta de 5–8 proveedores | Tú |
| 4. RFP / RFQ | 2–3 | Brief enviado y respuestas | Tú, luego los proveedores |
| 5. Evaluación de proveedores | 1–2 | Matriz de evaluación puntuada | Tú |
| 6. Negociación y contrato | 2–3 | Acuerdo firmado | Ambos, más legal |
| 7. Entrega y aceptación | dura todo el desarrollo | Acta de aceptación | Ambos |
| Total antes del desarrollo | 10–16 | Contrato firmado y un SOW testeable | Tú |
1. Necesidad y caso de negocio
Empieza con el documento de una página de arriba. En nuestros proyectos, los que se lo saltan redefinen el alcance a mitad de desarrollo, cuando los cambios cuestan dinero de verdad en lugar de un párrafo. También fija el techo de presupuesto que citas en la RFP.
2. Alcance del trabajo (SOW)
El alcance del trabajo convierte el caso de negocio en una especificación sobre la que ambas partes pueden discutir: funcionalidades dentro y fuera, integraciones, plazos y los criterios de aceptación contra los que se prueba la entrega. Cómo definir el alcance de un proyecto web se paga solo aquí, o define los requisitos con IA para un borrador más rápido.
3. Escaneo de mercado
Construye una lista corta de cinco a ocho proveedores con referencias recientes y relevantes en tu dominio. Pregunta a colegas que hayan entregado trabajo similar; revisa casos de estudio de tu sector, no páginas de inicio. Sáltate los directorios ordenados por comisión de referido.
4. RFP / RFQ
Envía a cada proveedor preseleccionado el mismo brief y exige el mismo formato de respuesta. Una RFP (solicitud de propuesta) pregunta cómo lo desarrollarían; una RFQ (solicitud de presupuesto) pregunta cuánto cuesta un alcance definido. Para la adquisición de software a medida, la RFP va primero.
5. Evaluación de proveedores
Puntúa cada respuesta contra la misma matriz de evaluación, dando más peso a las referencias y al derecho de auditoría de código que al precio. La propuesta más barata suele ser la que menos trabajo ha presupuestado. Llama tú mismo a las referencias.
6. Negociación y contrato
Toma la propuesta ganadora y añádele las nueve cláusulas de abajo. Negocia primero los criterios de aceptación y los pagos por hitos, y el precio al final: el precio es la condición más fácil de mover; la aceptación es la que merece la pena pelear.
7. Entrega y aceptación
Entrega no es "han enviado el código". Aceptación significa que el software pasa los criterios del SOW en tu entorno, con la cesión de PI firmada y el código fuente entregado. Retén el pago del último hito hasta que esa prueba pase.
La RFP que te consigue presupuestos reales
Una RFP sin criterios de aceptación es un presupuesto para un trabajo que nadie ha definido. El esqueleto de abajo es la plantilla de adquisición de software a medida que desearíamos que todo comprador nos enviara. Cópiala, rellena los huecos y cinco proveedores presupuestarán un alcance, no cinco suposiciones.
CUSTOM SOFTWARE RFP
1. Company context
Who you are, team size, the system this replaces or connects to
2. Problem statement
The broken process, what it costs you today, who feels it
3. Scope
In: the features and integrations the first release must ship
Out: anything you have decided to defer
4. Technical constraints
Stack preferences, hosting rules, compliance (GDPR, HIPAA), SSO
5. Timeline
Hard dates, and what happens if you miss them
6. Budget range
A ceiling, not a target. Vendors price to the number you give.
7. Acceptance criteria
The pass/fail tests the final delivery must clear before sign-off
8. Evaluation criteria
How you will score responses, and the weight of price vs. references
9. Response format
Page limits, the questions to answer, and the reply deadlineIncluye sobre todo tres cosas: techo de presupuesto, criterios de aceptación y formato de respuesta. Son lo que convierte propuestas vagas en presupuestos comparables.
Recorta tres cosas: prescripciones de implementación ("usad microservicios"), NDAs antes de la preselección y apéndices de requisitos de 40 páginas. Estás comprando un resultado, no una arquitectura.
Dos notas prácticas: envía a cada proveedor el mismo documento, porque las respuestas uniformes son la única forma de que una matriz de evaluación signifique algo; y declara los pesos de evaluación en la propia RFP. Los proveedores escriben propuestas más afinadas cuando saben que las referencias pesan más que el precio.
¿Cómo se evalúa a un proveedor de software a medida?
Evaluar proveedores significa puntuar cada propuesta contra la misma matriz ponderada por evidencias, para que la decisión resista una segunda mirada. El precio merece menos peso del que la mayoría de compradores le dan: las propuestas que ofertan a la baja suelen haber presupuestado el mínimo de trabajo. La matriz que recomendamos para presupuestos de pyme:
| Criterio | Peso | Guía de puntuación |
|---|---|---|
| Referencias en tu dominio | 25% | 5: dos referencias a las que de verdad llamaste, de tu sector. 1: un muro de logos |
| Derecho de auditoría de código | 15% | 5: acepta por escrito una revisión de código de terceros antes del pago final |
| Salud financiera | 10% | 5: rentable, con trayectoria de varios años. 1: no puede demostrarlo |
| Postura de seguridad | 15% | 5: SDLC documentado, escaneo de dependencias, acceso de mínimo privilegio |
| Continuidad y antigüedad del equipo | 15% | 5: equipo con nombres, baja rotación. 1: "asignaremos personal tras firmar" |
| Cadencia de comunicación | 10% | 5: demo semanal comprometida por escrito. 1: "usamos Slack" |
| Disciplina de PI | 10% | 5: cesión de obra por encargo limpia, sin núcleo propietario reutilizado |
Los pesos son un punto de partida. Muévelos, pero que sumen 100 y anótalos antes de leer una sola propuesta. Cómo clasificamos a las empresas de desarrollo aplica la misma disciplina; lo que realmente incluyen los servicios de desarrollo te ayuda a comparar partidas equivalentes.
Checklist de debida diligencia para la adquisición de software
Haz esto con los dos mejores proveedores antes de firmar, no con los cinco:
- Referencias verificadas con preguntas reales (qué se rompió, cómo lo gestionaron, volverías a contratarlos)
- Derecho de auditoría de código acordado por escrito, antes del pago del último hito
- Salud financiera confirmada (años operando, rentabilidad, concentración de clientes)
- Postura de seguridad revisada (SDLC, control de accesos, historial de incidentes)
- Continuidad de personas clave confirmada (el equipo del pitch es el equipo del proyecto)
- Cesión de PI revisada por tu abogado, no por el suyo
9 cláusulas de contrato que protegen tu presupuesto
La cláusula que protege tu presupuesto no es el precio. Es la prueba de aceptación. La guía de compras de la UCLA, la única página institucional en el top diez de Google para este tema, construye su consejo sobre software a medida alrededor de esa idea: alcance del trabajo, propiedad de la PI, pruebas de aceptación y garantía, antes de que el precio entre en la sala. Nosotros expandimos esa taxonomía a nueve cláusulas para compradores comerciales.
Si estás armando una plantilla de contrato de compra de software, estas nueve filas son la columna vertebral:
| # | Cláusula | Por qué aprieta | Ejemplo de redacción en una línea |
|---|---|---|---|
| 1 | Propiedad de la PI / obra por encargo | Sin ella el proveedor conserva el copyright y te licencia el software | "Todos los entregables son obra por encargo; tras el pago, el comprador posee toda la PI" |
| 2 | Criterios y procedimiento de aceptación | La única definición objetiva de "terminado"; sin ella, las disputas son opiniones | "La entrega se acepta solo cuando todas las pruebas del Anexo B pasan en el entorno del comprador" |
| 3 | Pagos ligados a hitos | Mantiene el efectivo detrás del progreso; elimina el riesgo del 100% por adelantado | "20% al inicio, luego 20% por hito, 20% en la aceptación final" |
| 4 | Control de cambios | Evita que las discusiones de alcance se vuelvan discusiones de facturas | "Los cambios de alcance exigen una orden de cambio por escrito con impacto en precio y plazo firmada por ambas partes" |
| 5 | Periodo de garantía | Obliga al proveedor a responder por el código tras la entrega | "El proveedor corrige sin coste los defectos hallados en los 90 días siguientes a la aceptación" |
| 6 | Protección de precio | Limita el daño de las estimaciones optimistas | "Tarifas T&M fijas 12 meses; techo máximo sin reaprobación por escrito" |
| 7 | Especificaciones de rendimiento | Convierte "va lento" en incumplimiento, no en queja | "Carga de página p95 bajo 2 s; API p99 bajo 300 ms con 500 usuarios concurrentes" |
| 8 | Personal clave | Evita el cambiazo de pitch sénior y desarrollo júnior | "Los líderes nombrados no pueden reasignarse sin consentimiento por escrito del comprador" |
| 9 | Rescisión y depósito de código fuente | Tu salida si el proveedor se estanca, quiebra o abandona | "El comprador puede rescindir por causa con 14 días de preaviso; el código en depósito se libera en caso de insolvencia" |
Si te saltas una cualquiera, estás financiando una esperanza. Si tu abogado tiene tiempo para tres cláusulas, dale la 1, la 2 y la 3.
¿Cuánto cuesta el software a medida y cómo deberías estructurar el pago?
El alcance fija el precio, por eso el SOW existe antes de que cualquier presupuesto signifique algo. El ancla publicada es la estimación de ScienceSoft de 200.000–400.000 $ y unos 10 meses para software de compras a medida de nivel empresarial; ScienceSoft atribuye la cifra de ROI del 315% a un estudio Forrester Total Economic Impact.
Esos son sus números para grandes desarrollos empresariales, no los nuestros. Desarrollos más pequeños de pymes, una herramienta interna, un portal de clientes, una app móvil, caen muy por debajo de esa banda; trata nuestra lectura pyme como interpretación, y pide tres presupuestos antes de creerte nada. Para un ancla por app, nuestro desglose de costes de apps móviles presupuesta por tipo de app.
La estructura del pago importa tanto como el total:
| Modelo | Gana cuando | El riesgo recae en | Uso típico |
|---|---|---|---|
| Precio cerrado | El alcance está congelado y el SOW es hermético | El proveedor (absorbe los sobrecostes) | Primeras versiones bien definidas |
| Tiempo y materiales | El alcance evolucionará y confías en el equipo | Tú (cada hora extra se factura) | Desarrollos con mucho descubrimiento o largos |
| Ligado a hitos | Cualquiera de los dos modelos, con pagos atados a entregables aceptados | Compartido (el efectivo sigue a la prueba) | La mayoría de desarrollos a medida de pymes |
| Comprar vs. licenciar vs. suscribir la PI | Solo eres dueño del código si el contrato cede la PI; licenciar y suscribir SaaS lo alquilan | Dependencia del proveedor con licencia y suscripción | Compra cuando el software es central; suscribe cuando es commodity |
Nuestra recomendación: por defecto, pagos ligados a hitos sobre un alcance cerrado, 20% o menos al inicio, y el tramo final condicionado a la prueba de aceptación. Precio cerrado solo si tu SOW sobrevive a una lectura hostil; tiempo y materiales solo con un proveedor con el que ya hayas entregado antes. Nunca el 100% por adelantado; esa estructura reaparece más abajo.
Señales de alerta: cómo fracasan de verdad las adquisiciones de software a medida
Pagar el 100% por adelantado no te compra prioridad. Te transfiere todo el riesgo de entrega. Cada señal de alerta de abajo le da al proveedor un poder de negociación que no recuperarás:
- SOW vago. "Construidnos un CRM", sin lista de funcionalidades. Cada término sin definir se convierte en una orden de cambio, presupuestada sin competencia.
- Sin prueba de aceptación. "Lo sabremos cuando lo veamos." Entonces nunca lo ves, porque "terminado" jamás se definió.
- Pago del 100% por adelantado. El efectivo es tu única baza tras firmar; gástala toda el primer día y no te queda ninguna.
- Sin control de cambios. El alcance crece, las facturas crecen, nadie firmó el crecimiento.
- Cesión de PI ausente. Pagaste el software y te lo licenciaron de vuelta sin que lo notaras.
- Sin cláusula de personal clave. El equipo sénior que ganó el pitch desaparece la semana después de firmar.
Nosotros respondemos RFPs de software a medida cada trimestre desde el lado del proveedor, y dos patrones se repiten con tanta fiabilidad que los tratamos como la tasa base del fracaso de adquisición: RFPs sin ningún criterio de aceptación, y calendarios de pago que ponen la mayoría por adelantado, dando al proveedor todo el incentivo para despriorizar el proyecto una vez que el dinero aterriza. Nuestra lectura, y es interpretación, no medición: los compradores que más pelean el precio son los que se saltaron las dos cláusulas, aceptación e hitos, que lo habrían protegido.
Los datos del sector apuntan en la misma dirección. The Standish Group lleva tres décadas siguiendo el resultado de proyectos con su investigación CHAOS; su hallazgo recurrente es que los proyectos en apuros, con sobrecoste, retraso o falta de funcionalidades, superan a los éxitos limpios, con los requisitos vagos y el patrocinio débil cerca de los primeros puestos de las listas de causas.
Si solo arreglas una cosa, arregla los criterios de aceptación. Es la cláusula que hace exigibles todas las demás.
Cómo aborda Techsy la adquisición de software a medida
Nuestra recepción sigue los mismos siete pasos desde el otro lado de la mesa. Producimos el SOW y los criterios de aceptación antes de presupuestar una cifra, porque presupuestar contra un brief vago es cómo los proveedores ofertan a la baja y los compradores pagan de más. Los desarrollos corren con pagos ligados a hitos, demos semanales y derecho de auditoría de código en cada contrato. Cuando la aceptación pasa, eres dueño de la PI y del repositorio, no de una licencia.
Límites honestos: si necesitas una herramienta SaaS con licencia que automatice las compras, somos la llamada equivocada. Eso es una compra de producto, no un desarrollo; un vendedor de herramientas te sirve más rápido y más barato. Aceptamos trabajo a medida donde el software es el proceso y la PI importa.
Si tu proyecto cae en ese segundo cubo, pide una consulta gratuita.
Preguntas frecuentes
¿Qué es la adquisición de software?
La adquisición de software es el proceso de adquirir software: definir la necesidad, evaluar opciones, negociar condiciones, aceptar la entrega. Cubre tanto productos con licencia como desarrollos a medida. Esta guía se centra en lo segundo: el proceso que va del caso de negocio a la RFP, el contrato y la prueba de aceptación.
¿Cuáles son los 4 tipos de adquisición?
Los cuatro tipos que se citan habitualmente son la adquisición directa (insumos de producción), indirecta (bienes y servicios operativos), de bienes y de servicios. El software cabalga entre indirecta y servicios: una herramienta con licencia es una compra indirecta; un desarrollo a medida es un encargo de servicios que termina en bienes entregados.
¿Cuál es la diferencia entre software de compras y adquisición de software a medida?
El software de compras es una herramienta que automatiza flujos de compra, como Tradogram o Tipalti. La adquisición de software a medida es el proceso de encargar software a un desarrollador. ¿Buscas la mejor plataforma de compras? Quieres lo primero; esta guía es lo segundo.
¿Cuánto tarda la adquisición de software a medida?
Planifica de 10 a 16 semanas del caso de negocio al contrato firmado en un proyecto típico de pyme, antes de que empiece el desarrollo; trátalo como interpretación, no como benchmark. Una renovación con proveedor único se comprime a semanas; una licitación regulada puede estirarse más de seis meses.
¿Cuánto cuesta el software a medida?
ScienceSoft estima 200.000–400.000 $ y unos 10 meses para software de compras a medida de nivel empresarial, y atribuye una cifra de ROI del 315% a un estudio de Forrester. Los desarrollos más pequeños de pymes caen muy por debajo de esa banda. Para la adquisición de software a medida, el alcance fija el precio: la RFP y el SOW existen antes de que cualquier presupuesto signifique algo.
¿De quién es la PI en el software a medida?
De quien diga el contrato. Sin una cláusula explícita de obra por encargo o de cesión de PI, el proveedor conserva el copyright y te licencia el software. Pon la propiedad por escrito, atada al pago: tras el pago final, el comprador lo posee todo. Ata esa transferencia al tramo final condicionado a la aceptación, no al pago inicial, para que la propiedad solo se mueva cuando el software se mueve.
¿RFP o RFQ, cuál necesito?
Una RFP (solicitud de propuesta) pregunta cómo resolverían los proveedores tu problema; una RFQ (solicitud de presupuesto) pregunta cuánto cuesta un alcance definido. Para software a medida, envía primero la RFP: los proveedores deben proponer un enfoque antes de que un precio signifique algo. La RFQ llega una vez que el SOW está congelado.
¿Precio cerrado o tiempo y materiales?
El precio cerrado te protege cuando el SOW es hermético: el proveedor absorbe los sobrecostes. El tiempo y materiales encaja en trabajo con mucho descubrimiento donde el alcance evolucionará, pero tú cargas con el riesgo de sobrecoste. La mayoría de compradores de pyme obtienen mejores resultados con pagos ligados a hitos sobre alcance cerrado, y el tramo final condicionado a la prueba de aceptación.
¿Qué debe incluir un alcance del trabajo?
Un alcance del trabajo debe nombrar las funcionalidades dentro y fuera del alcance, integraciones, plazos, los criterios de aceptación contra los que se prueba la entrega y los hitos de pago atados a cada entregable. Si una condición no está en el SOW, no está en el proyecto.
Sobre el autor
Mert Batur es cofundador de Techsy.io, donde el equipo entrega agentes de IA, sistemas de automatización y pipelines de voz/SDR para clientes B2B. Escribe sobre el stack de herramientas LLM que el equipo de Techsy usa de verdad en producción. También dirige los proyectos de entrega de software a medida en los que se basa esta guía, desde la respuesta a la RFP hasta la entrega aceptada. Conecta en LinkedIn.
Conclusión
La adquisición de software a medida se reduce a artefactos, no a negociaciones: el caso de negocio de una página, el SOW con criterios de aceptación, el esqueleto de RFP, la matriz de evaluación y el contrato de nueve cláusulas. Clava esos cinco documentos y la conversación con el proveedor se arregla sola. Ejecuta los siete pasos en orden, retén el pago final tras la prueba de aceptación y, si quieres una segunda opinión sobre tu RFP, pide una consulta gratuita.