Cómo preparar una RFP para una app y comparar agencias de verdad

El problema aparece cuando llegan las propuestas

Pides tres ofertas para una aplicación de reservas y recibes tres proyectos distintos. La primera agencia incluye la aplicación del cliente, el calendario del personal y una zona de administración. La segunda da por hecho que todo vendrá resuelto por la web actual. La tercera describe con detalle las pantallas, pero apenas menciona pagos, avisos o soporte. Los tres documentos parecen completos. Solo que no están calculando lo mismo.

Una RFP, o solicitud de propuestas, sirve para evitar ese momento. No es un tecnicismo anglosajón que haya que copiar tal cual ni un pliego burocrático para una empresa privada. Es una forma ordenada de plantear la misma decisión a varios proveedores y pedir que hagan visibles sus supuestos. La agencia conserva espacio para recomendar una solución; tú conservas la posibilidad de compararla.

El documento tiene sentido cuando hay varias personas tomando la decisión, existen integraciones con el negocio actual o se quiere consultar a más de una empresa. Para una idea todavía verde, quizá baste con describirla en el brief para estimar una app y encargar primero una fase de definición. Un concurso aparatoso no convierte una hipótesis débil en un producto claro.

No conviertas la RFP en un falso documento técnico

Antes de escribir, conviene separar cuatro piezas. El PRD ordena el problema, los usuarios y las prioridades del producto. La especificación funcional y técnica describe con más precisión comportamientos, datos e integraciones. La solicitud de propuestas pide a distintas empresas que expliquen cómo abordarían el encargo. Después, la propuesta elegida se aclara y pasa a los documentos contractuales.

Cuando la empresa compradora decide por adelantado hasta el último detalle técnico, pierde parte del criterio que espera contratar. Tiene sentido fijar una restricción real: un sistema corporativo, un proveedor de identidad, alojamiento en una región concreta, accesibilidad o un parque de dispositivos. No tiene tanto sentido exigir una arquitectura porque alguien la vio en otra app.

El modelo de PRD para aplicaciones ayuda a alinear al equipo interno. La plantilla de especificación técnica sirve cuando los flujos ya están más maduros. En la solicitud basta con enlazar esos materiales y señalar qué partes son requisitos y cuáles siguen abiertas.

Haz la consulta en dos vueltas

Preparar una respuesta seria lleva tiempo. Enviar treinta preguntas a quince agencias favorece a quien tiene un departamento comercial grande, no necesariamente a quien entiende mejor el producto.

La primera vuelta puede ocupar dos páginas. Explica el negocio, el problema, el tipo de usuario y la fecha en la que se quiere empezar. Pide dos proyectos relevantes, disponibilidad, composición probable del equipo, idiomas de trabajo y cualquier incompatibilidad evidente. Comprueba la semejanza operativa, no solo el sector: una plataforma con vendedores, devoluciones y disputas puede demostrar más para un marketplace que una app visualmente parecida sin esa complejidad.

Con esa información se forma una lista corta. A esas empresas sí se les envía la solicitud completa, con el mismo calendario, el mismo contacto y las mismas reglas. Así cada participante sabe qué esfuerzo merece la oportunidad y la empresa evita comparar respuestas apresuradas con otras muy trabajadas.

Qué debe contar la solicitud

Una RFP útil puede ser breve, pero no puede esconder las decisiones importantes. Incluye estos bloques:

1. Situación actual. Qué hace la empresa, cómo se resuelve hoy la tarea y por qué se plantea una aplicación ahora.
2. Usuarios y recorridos. Quién entra y qué dos o cinco acciones deben funcionar de principio a fin.
3. Resultado esperado. Qué cambio observable justificaría la primera versión, más allá de "mejorar la experiencia".
4. Límite inicial. Qué es imprescindible, qué se puede proponer como opción y qué queda fuera de forma expresa.
5. Sistemas y materiales existentes. Web, API, CRM, pagos, datos, contenido, diseño, marca y responsables internos.
6. Condiciones reales. Plataformas, países, idiomas, privacidad, accesibilidad, trabajo sin conexión, seguridad o dispositivos cuando sean relevantes.
7. Responsabilidades. Qué aportará tu equipo y quién se ocupará del producto, diseño, desarrollo, pruebas, publicación y soporte.
8. Continuidad. Repositorios, cuentas, archivos editables, documentación, componentes de terceros y entrega si cambia el proveedor.
9. Reglas de respuesta. Índice obligatorio, preguntas, fecha, canal de aclaraciones, demostración y criterios de evaluación.

Describe situaciones, no una colección de sustantivos. "Notificaciones" puede significar casi cualquier cosa. "Avisar de la cita del día siguiente, permitir cambiarla dentro del plazo y alertar al centro cuando se libera el hueco" permite pensar, diseñar y probar.

Obliga a responder con el mismo índice

La creatividad debe aparecer en la solución, no en la ubicación de los datos básicos. Pide que todas las agencias presenten su comprensión del problema, alcance inicial, exclusiones, supuestos numerados, etapas, equipo asignado, dependencias del cliente, enfoque técnico, control de calidad, publicación, riesgos, propiedad, soporte y propuesta comercial en ese orden.

Numerar los supuestos parece una minucia hasta que surge una aclaración. Si el CRM no admite escritura, se puede pedir a todos que revisen el supuesto S-06. Sin esa referencia, el cambio queda repartido entre correos, llamadas y versiones de PDF.

También es útil que cada función se marque como incluida, opcional, pendiente de aclaración o desaconsejada. Una negativa razonada puede revelar más experiencia que una tabla repleta de respuestas afirmativas.

Decide cómo vas a puntuar antes de leer

La matriz se acuerda internamente antes de conocer las propuestas. De lo contrario, es fácil cambiar el peso de los criterios para justificar la presentación que más gustó.

Los pesos no son una norma. En salud o finanzas, la seguridad y el cumplimiento necesitan más atención. En un prototipo para una campaña, quizá importe más la disponibilidad inmediata y una prueba muy acotada. Lo importante es acordar el significado de una buena respuesta antes de escuchar a un vendedor convincente.

Dos personas deberían puntuar por separado y comentar después las diferencias. Ahí aparece la conversación útil: una pudo premiar el diseño del documento y otra detectar que nunca se nombró al equipo que realmente participaría.

Comparte las aclaraciones que cambian el proyecto

Las preguntas de los participantes descubren huecos en la solicitud. Mantén un registro común y envía a todos las respuestas que afecten al alcance o a las condiciones. Si una agencia sabe por una llamada privada que se permitirá comprar sin registro y las demás no, ya no se comparan propuestas equivalentes.

No hace falta revelar la idea confidencial de un candidato. Se comparten hechos del proyecto: reglas del negocio, datos disponibles, responsabilidades o restricciones. Si la respuesta altera una parte importante, da tiempo para corregir el documento e identificar qué supuesto queda reemplazado.

Una reunión conjunta de presentación puede ahorrar muchas preguntas, pero deja por escrito el resumen. Meses después, nadie recuerda con precisión qué se dijo al final de una videollamada.

Prueba al equipo con un caso incómodo

Tras revisar los documentos, invita a las mejores opciones a resolver una situación realista: el pago se confirma pero no aparece la reserva; dos empleados asignan el último turno; el usuario pierde conexión; o un administrador necesita deshacer una acción peligrosa.

Pide que participen las personas que trabajarían en el proyecto. Una gran exposición comercial no muestra cómo razonan juntos diseño, ingeniería y gestión. Escucha si preguntan primero por el usuario y la operación, si distinguen lo que saben de lo que deben investigar y si proponen una forma razonable de reducir el riesgo.

En una referencia, evita la pregunta genérica "¿quedasteis satisfechos?". Pregunta qué cambió después de firmar, cómo se comunicaron los problemas, si se mantuvo el equipo prometido y qué pudo gestionar el cliente al terminar. Los casos públicos prueban que algo salió al mercado; rara vez explican cómo se tomaron las decisiones difíciles.

Compara supuestos, no solo importes

Traslada cada propuesta a una hoja común: perfiles de usuario, plataformas, servidor, zona de administración, integraciones, diseño, migración, analítica, pruebas, tiendas, documentación y soporte. Junto a cada elemento, registra qué está excluido o depende de tu empresa.

No penalices la incertidumbre bien expresada. "Necesitamos revisar la API antes de confirmar la sincronización" es una respuesta responsable. Lo importante es cómo piensa reducir esa duda: una prueba técnica, un taller de flujos, una muestra de datos o una decisión por etapas.

La guía sobre precio cerrado frente a trabajo por tiempo explica cómo el tipo de acuerdo depende de esa incertidumbre. La solicitud no debe ocultarla; debe hacerla negociable.

La propiedad y la salida se preguntan ahora

Incluye preguntas sobre los repositorios, las cuentas de Apple y Google, el servidor, la base de datos, los dominios, la analítica, las claves y los servicios externos. Pide además una lista de entregables por etapa: código, diseño editable, instrucciones de compilación, dependencias, pruebas y problemas conocidos.

La guía de la OMPI sobre contratos de aplicaciones distingue el código nuevo, los materiales previos del proveedor y los componentes de terceros. No todos se ceden del mismo modo. La solicitud no sustituye a un abogado, pero evita descubrir esta conversación cuando el contrato ya parece cerrado.

La lista de entrega de documentación ayuda a comprobar la continuidad técnica. La guía del contrato de desarrollo recoge los puntos que después deben revisarse legalmente.

Una plantilla corta para empezar

Puedes redactar la primera versión con este índice: contexto y motivo; usuarios y recorridos; resultado esperado; alcance inicial y exclusiones; sistemas actuales; responsabilidades; restricciones; preguntas al proveedor; evidencias solicitadas; proceso de aclaración; formato de respuesta; criterios y calendario de decisión.

Adjunta pocos materiales, pero bien nombrados: un esquema del recorrido, una muestra de datos, la arquitectura actual o una captura de la analítica. Una carpeta enorme sin contexto no aporta precisión; solo desplaza el trabajo de ordenar el proyecto a cada agencia.

Señales de alerta

Desconfía si el documento de respuesta repite tus palabras sin aclararlas, acepta todas las funciones sin prioridades o recomienda una tecnología sin mencionar las restricciones. También preocupa ver perfiles muy sénior en la venta y ningún nombre en la entrega, una frase como "pruebas incluidas" sin método, o una promesa de propiedad sin detallar repositorios, cuentas y componentes externos.

Pide alguna evidencia anonimizada: un criterio de aceptación, un registro de riesgos, una lista de publicación o un índice de entrega. No se trata de coleccionar plantillas. Se trata de comprobar si el proceso que te cuentan deja huellas útiles.

Cómo responde Appfyl a una solicitud útil

Empezamos comprobando si la primera versión forma un producto coherente. Ordenamos recorridos, tareas de la zona de administración, integraciones, estados difíciles y dependencias del cliente. Después explicamos qué entra, qué sigue abierto y qué dejaríamos para más adelante. La tecnología llega después de esas decisiones.

Si todavía no existe un documento, el cuestionario de Appfyl permite recoger las funciones principales y añadir contexto libre. Para las entrevistas, combínalo con las preguntas para una agencia de aplicaciones.

¿Quieres ver cómo Appfyl convierte el alcance en productos lanzados? Ver casos de Appfyl.

Preguntas frecuentes