RFP para desarrollo de software: por qué la mayoría de los founders no técnicos está usando el instrumento equivocado
Una founder con la que hablamos el trimestre pasado mandó el mismo RFP de 11 páginas a cinco estudios de software. Empresa pre-seed, dos pilotos enterprise firmados, una ventana de seis semanas para poner una v1 funcionando frente al primer cliente que paga. El RFP era un template que había descargado de un blog de procurement: company background, project goals, scope of work, technical requirements, evaluation criteria, deadline. Se veía profesional. Se veía como lo responsable.
Tres estudios no respondieron. Los dos que sí mandaron propuestas que se diferenciaban en 90.000 dólares sobre el mismo alcance. Ninguno hizo la pregunta que importaba, que era si ella realmente necesitaba todo lo que había escrito. Eligió el más barato. Seis meses después iba por su tercer project manager y el cliente seguía usando una hoja de cálculo.
Así se ve un RFP para desarrollo de software cuando el instrumento no calza con el trabajo. Es también lo que la mayoría de los artículos que rankean en esa búsqueda se pierde: la pregunta no es cómo escribir el RFP, es si el RFP es lo correcto para escribir.
Qué es realmente un RFP para desarrollo de software
Un RFP, o Request for Proposal, es un documento formal de procurement. Un comprador lo envía a una shortlist conocida de vendors describiendo qué necesita construir, en qué plazo, bajo qué restricciones y cómo se evaluarán las propuestas. Los vendors responden con una propuesta estructurada: alcance, equipo, cronograma, precio, referencias. El comprador evalúa las respuestas contra los criterios del documento y elige la propuesta ganadora.
El instrumento existe porque hacer procurement a escala es difícil. Cuando un departamento de TI de la Fortune 500 compra un CRM, una agencia regulada contrata a un integrador, o una red hospitalaria selecciona un EHR, el RFP impone tres cosas: cancha pareja para los vendors, rastro documental para la decisión y alcance contractual definido para que el comprador no quede en la lona cuando el proyecto se tuerce. Para ese tipo de compra, el RFP es el documento correcto.
Para un fundador no técnico que contrata una construcción custom de software en pre-seed, seed o Serie A, esas tres propiedades no aplican. Los proveedores son una comunidad chica, no un mercado de procurement. No hay comité de auditoría al que rendirle cuenta. Y el alcance todavía no está definido. No puede estarlo, porque la razón por la que el founder está tercerizando es justamente que, al nivel de requisito, no sabe qué construir.
Por qué los founders igual recurren a un RFP
Suelen ser tres gatillos. Ninguno es “un RFP es el mejor instrumento para este trabajo.”
El primero es herencia profesional. El founder pasó diez años en finanzas, consultoría o un cargo corporativo senior antes de fundar la empresa. Cada decisión de procurement en su vida anterior usó un RFP. Es la memoria muscular del “estamos gastando dinero de verdad y hay que tener cuidado.” Cuando el presupuesto es 150.000 dólares y el proyecto va a sobrevivir a la próxima ronda, el RFP se siente como la versión adulta de “pedir tres presupuestos.”
El segundo es miedo de ser engañado. Dolor #2 del ICP: cada freelancer le quemó la mano. Amigos levantaron pre-seed, le pagaron a una agencia 200.000 dólares y recibieron una app a medio funcionar. El founder recurre al RFP porque el documento se siente como protección: alcance claro, entregables claros, penalidades claras.
El tercero es óptica frente al inversor. Un miembro del board o un advisor le dijo “pedí tres cotizaciones.” Un CFO que nunca trabajó en producto sugirió formalizar el proceso. El RFP es el artefacto que prueba que hubo due diligence.
Los tres gatillos son legítimos. El error es concluir que el RFP es la respuesta a cualquiera de ellos. Cautela, protección y due diligence en pre-seed no se parecen casi en nada al procurement empresarial.
Tres problemas del RFP para software custom en etapa temprana
Problema 1: el problema del alcance
Un RFP le pide al comprador que especifique qué quiere construido. La Sección 3 es siempre “Alcance y Requisitos del Proyecto.” Para software de paquete esto funciona: el comprador sabe que quiere un CRM que haga X, Y y Z, y los vendors cotizan contra esas features. Para software custom en etapa temprana, el founder todavía no sabe qué quiere. Sabe el dolor del cliente, sabe el resultado de negocio que necesita, y tiene una hipótesis sobre la primera capa del sistema. El punto entero de trabajar con un partner es comprimir la distancia entre la hipótesis y el producto entregado.
Cuando el RFP fuerza al founder a escribir 40 requisitos que no validó, pasan dos cosas malas. Sobreespecifica, porque dejar celdas vacías en la sección de requisitos se ve poco profesional. Y los vendors cotizan contra el alcance sobreespecificado, no contra el problema real. Los 40 requisitos se convierten en contrato, y cualquier desvío se convierte en adicional. El founder endureció una corazonada en entregable antes de hablar con un solo ingeniero.
Los estudios que entienden esto (los buenos) le dirían al founder que tire la sección de requisitos y arranque del problema del cliente. No se lo van a decir dentro de la propuesta, porque el formato de propuesta no tiene espacio para “tu documento tiene la forma equivocada.”
Problema 2: el problema de la cotización
Los RFP juntan propuestas. Las propuestas se comparan. La cotización calificada más barata suele ganar, a veces ajustada por los pesos de evaluación que el comprador definió antes.
Esto funciona para trabajo commodity. Si necesitas diez mil tornillos torneados a norma ISO, la cotización calificada más barata es la respuesta correcta, porque el trabajo es genuinamente idéntico entre vendors. Software custom es lo opuesto. El trabajo no es idéntico. El estudio que hace cinco preguntas afiladas sobre el problema y cotiza un número más alto está haciendo algo que el más barato no está, pero ni el RFP ni el formato del bid capturan esa diferencia.
Peor: el formato selecciona contra los estudios con los que querrías trabajar. Los buenos o no se molestan en responder (prefieren 30 minutos de conversación a tres días llenando un formulario), o inflan alcance para protegerse del drift que van a sufrir, lo que hace que la cotización se vea cara. Los estudios que responden rápido con números bajos están haciendo una de tres cosas: subestimando con optimismo para ganar el deal, planeando facturar adicionales hasta que aparezca el margen, o usando la build como entrenamiento de equipo junior. El mecanismo selecciona a los partners equivocados.
Problema 3: el problema de la relación
El RFP encuadra el engagement como vendor y comprador. El vendor entrega; el comprador acepta o rechaza. El contrato enumera penalidades por hitos perdidos. El trabajo es opaco entre checkpoints. El comprador tiene visibilidad sólo en las puertas que el documento definió desde el día uno.
El software custom necesita la forma opuesta: visibilidad semanal, iteración rápida, decisiones compartidas sobre trade-offs que el founder no tenía cómo anticipar en la semana cero. Un estudio que es partner de verdad dice “tenemos que repensar el hito tres con base en lo que aprendimos en el dos.” Un vendor bajo un contrato derivado de RFP dice “el hito tres está en alcance; si querés cambiarlo, acá está el adicional.” El mismo estudio hace una u otra cosa según el contrato debajo. El RFP casi siempre produce la segunda forma.
Por eso source code escrow, las cláusulas de lock-in y las provisiones elaboradas de salida aparecen tanto en contratos de agencia: son los mecanismos de protección que una relación de vendor exige. Cuando la relación es una verdadera sociedad, la mayoría de ellos sobra.
Qué mandar en su lugar: el brief de partnership en cinco párrafos
Reemplazá el RFP por un documento de una página. Cinco párrafos cortos. Mandalo a dos o tres estudios que ya tenés en shortlist por referencia, no a cinco que encontraste en Google.
Párrafo 1. El problema de negocio en lenguaje llano. ¿Qué te está pagando tu cliente por resolver? Dos o tres frases, sin jerga. “Corredores independientes de seguros en São Paulo gastan 6 horas por póliza reconciliando estados de comisión de 14 aseguradoras. Les cobramos una suscripción para hacerlo en 10 minutos.” Más útil que 40 requisitos. El estudio aprende más de ese párrafo que de la sección de requisitos entera de cualquier template de RFP.
Párrafo 2. La primera cosa que lanzarías. ¿Cuál es la versión más chica del sistema que hace que un cliente pagante lo use de verdad? No el MVP de marca, la primera versión que estarías orgulloso de poner frente a un cliente pagante. Mirá nuestro artículo sobre cómo briefear a un desarrollador para startup para el encuadre. Un párrafo, tres o cuatro capacidades centrales. Si todavía no podés escribir ese párrafo, el trabajo de discovery no está listo.
Párrafo 3. Tu rango de presupuesto. Un número real, no un piso anclado bajo. “Reservamos entre 80.000 y 120.000 dólares para la primera build.” O: “Tenemos 60.000 dólares y necesitamos saber qué se puede entregar con eso.” Esconder el número no te trae mejor precio; te trae propuestas calibradas contra el encuadre equivocado. Si no sabés el rango correcto, nuestro artículo sobre precio cerrado vs. tiempo y materiales cubre las preguntas estructurales.
Párrafo 4. Tu cronograma y qué lo está empujando. “Necesitamos la v1 en producción antes del 30 de agosto porque el piloto de nuestro primer cliente enterprise arranca el 1 de septiembre.” La restricción es la información real. Un cronograma tirado al aire (“nos gustaría lanzar en Q4”) no le dice nada al estudio sobre qué trade-offs estás dispuesto a aceptar.
Párrafo 5. Tres preguntas que querés que el estudio responda por escrito. No “contame sobre tu empresa.” Cosas como: ¿Construyeron algo parecido para una empresa en una etapa similar? ¿Quién, por nombre, estaría en este proyecto, y cuál es su background? ¿Cuál es la primera cosa con la que estarían en desacuerdo en este brief? La tercera pregunta separa partners de vendors más rápido que cualquier otro estímulo.
Un estudio que no puede o no quiere responder ese documento en 48 horas no es fit. Un estudio que responde con tres preguntas afiladas propias es exactamente con el que querés seguir hablando.
Cuándo un RFP sí es el instrumento correcto
Tres situaciones estrechas, en su mayoría fuera de la compra de software custom en etapa temprana.
Comprando software de paquete. Estás eligiendo un CRM, un ERP, una plataforma de customer data, un HRIS. El alcance lo define el producto mismo. Los vendors son objetivos reales de procurement con equipos comerciales que responden RFP como práctica habitual. El RFP funciona.
Industrias reguladas con reglas de procurement. Sistemas de salud, instituciones financieras a partir de cierto tamaño, compradores cercanos al gobierno. Tu equipo de contratos te va a decir que el RFP es obligatorio y no hay argumento real para evitarlo. Usá el instrumento que cabe en el entorno regulatorio. Sólo entendé que es la política la que está empujando el documento, no la naturaleza del trabajo.
Trabajo genuinamente commodity con un spec terminado. Ya construiste v1, el sistema está en producción, y necesitás un alcance conocido de features adicionales que no exige discovery en formato de partnership. El RFP es razonable acá porque el trabajo realmente se volvió commodity. La mayoría de los founders no está en ese estado y no debería fingir que sí.
Si no estás en uno de esos tres casos, el brief de partnership es el documento correcto.
Qué preguntar en la primera conversación que ningún RFP va a sacar a la luz
El brief en cinco párrafos es el filtro. La primera conversación de 30 minutos es donde pasa la selección real. Cuatro preguntas que ningún documento de procurement va a sacar:
1. “Contame el último proyecto al que le dijiste que no.” Estudios que nunca le dijeron que no a un cliente le están diciendo que sí a todo. Esa es la peor señal. Los estudios que valen la pena pueden nombrar el engagement que rechazaron y explicar por qué.
2. “¿Con quién de tu equipo voy a estar hablando en la semana 4 del proyecto?” Si la respuesta es el fundador o el vendedor, el equipo que viste en el pitch no es el equipo que está construyendo. El nombre de un ingeniero senior específico es la respuesta que querés.
3. “¿Qué te parece que está mal en mi brief?” Un estudio que dice “nada, está perfecto” está vendiendo. Un estudio que apunta al párrafo 2 y dice “la primera cosa que lanzaría no es la que vos pensás” está haciendo el trabajo dentro de la conversación.
4. “¿Cuál es el engagement más chico por el que podríamos empezar?” Los partners de verdad proponen un sprint de scoping o discovery de dos a cuatro semanas antes de cotizar la build completa. Los estudios que cotizan 180.000 dólares en la primera llamada están adivinando.
Esas respuestas no salen de una respuesta escrita de RFP, por más elaborada que sea la rúbrica de evaluación.
FAQ
¿Qué es un RFP en desarrollo de software? Un Request for Proposal es un documento formal de procurement que el comprador envía a vendors describiendo lo que quiere construido, las restricciones y cómo se evaluarán las propuestas. El instrumento se originó en el procurement de TI corporativo y de gobierno, donde la selección estandarizada de vendor es obligatoria. Funciona bien para compra de software de paquete y procurement regulado, y mal para software custom en etapa temprana donde el alcance todavía está emergiendo. La entrada de Wikipedia sobre Request for proposal cubre la definición formal y la historia.
¿Debería mandar un RFP a varios estudios de software? Para una build custom en pre-seed o seed, no. Mandá un brief de partnership de una página a dos o tres estudios que ya tengas en shortlist por referencia. El patrón RFP-a-cinco-estudios selecciona estudios que ganan inflando bid, no por craft.
¿Cuál es la diferencia entre un RFP y un SOW en desarrollo de software? Un RFP es un documento de procurement usado antes de la selección del vendor: lo mandás a varios vendors, juntás propuestas y elegís uno. Un Statement of Work es un documento contractual firmado con el vendor que elegiste: define alcance, entregables, cronograma y precio del engagement real. Muchos founders los confunden porque los templates online los mezclan. El RFP va primero si lo usás; el SOW siempre va después de la selección.
¿Puedo usar un template de RFP que encontré online? Podés. La mayoría está escrito para procurement de TI corporativo y va a sobreespecificar tu proyecto en un orden de magnitud. Si decidís que el RFP sigue siendo el instrumento correcto para tu situación, vaciá la sección de requisitos y reemplazala con un statement del problema y un párrafo de la-primera-cosa-a-lanzar. Mejor todavía: saltate el template y mandá el brief de cinco párrafos.
¿Y si un estudio me pide que le mande un RFP? Algunos estudios prefieren el proceso estructurado de respuesta porque les deja rutear la propuesta por su pipeline interno. Es una preferencia legítima. Mandales el brief de partnership primero y dejá que ellos lo traduzcan a cualquier artefacto interno que necesiten. Si insisten en que el brief tiene que estar en forma de RFP antes de engancharse, esa es una pequeña señal sobre cómo va a sentirse el engagement. Pesado de proceso, con forma de vendor, lento para iterar. Leelo en consecuencia.
¿Qué tan largo debe ser un RFP para desarrollo de software? Si decidís mandar uno, dos páginas. El brief de cinco párrafos en el formato de arriba, más media página de criterios de evaluación. Cualquier cosa más larga vino del template y no está haciendo trabajo útil. Los RFP de grado procurement corren de 20 a 40 páginas porque tienen que pasar revisión política y legal. Nada de eso aplica a tu build.
El instrumento importa porque le da forma a la conversación. El RFP para desarrollo de software fue construido para un tipo de compra; casi nada en él calza con la compra que un fundador no técnico está haciendo en pre-seed. Mandá el documento que se ajusta al trabajo, no el que se ve más profesional desde afuera.