Contrato de desarrollo de una app: lista de control para clientes
Una lista práctica, no jurídica, para convertir alcance, propiedad, aceptación, soporte y entrega en condiciones verificables.
Un contrato de desarrollo de una app debe definir el alcance de la primera versión, los entregables, las responsabilidades, los supuestos del calendario, los pagos por hitos, las pruebas de aceptación, el procedimiento de cambios, los derechos sobre código y diseño, la titularidad de cuentas críticas, el uso de componentes de terceros, las obligaciones sobre seguridad y datos, la corrección de defectos, la terminación y la entrega final. Esta lista sirve para preparar la revisión con un profesional jurídico; no sustituye el asesoramiento aplicable al país y al contrato.
Estima tu app con un breve cuestionario
EmpezarDoce áreas que deben quedar claras
| Área | Pregunta que debe resolver | Evidencia práctica |
|---|---|---|
| Alcance | Qué perfiles, plataformas, recorridos e integraciones entran | Requisitos aprobados con versión y exclusiones |
| Entregables | Qué app, backend, panel, diseño, pruebas y documentación se entregan | Repositorios, archivos, entornos y cuentas identificados |
| Responsabilidades | Qué aporta cada parte y en qué fecha | Responsable y vencimiento por dependencia |
| Plazo | Qué supuestos sostienen cada hito | Cronograma con dependencias |
| Pagos | Qué hecho permite facturar cada parte | Hito aceptado u otro desencadenante definido |
| Aceptación | Cómo, cuándo y con qué pruebas se valida | Casos de prueba, versión y resultado escrito |
| Cambios | Cómo se modifica alcance, coste y fecha | Solicitud aprobada con impacto |
| Derechos | Quién puede usar, modificar y transferir cada activo | Cesión o licencia descrita por categoría |
| Cuentas | Quién controla tiendas, nube, dominios y proveedores | Cuentas empresariales y permisos por rol |
| Seguridad y datos | Qué controles y obligaciones se aplican | Anexo de seguridad y tratamiento cuando corresponda |
| Soporte | Qué es defecto y qué es mantenimiento | Niveles de gravedad, canal y límites |
| Salida | Qué ocurre si el proyecto termina antes | Paquete de entrega y asistencia de transición |
Una respuesta pendiente no significa necesariamente que la agencia sea mala. Significa que ambas partes están confiando en una suposición que conviene cerrar.
El alcance tiene que poder probarse
El contrato puede remitir a un documento de requisitos de producto y a una especificación técnica. Lo importante es identificar la versión válida.
No basta con escribir “módulo de reservas”. Hay que indicar si incluye horarios por empleado, depósitos, cancelaciones, zonas horarias, recordatorios y reembolsos. Describe perfiles, recorrido principal, reglas, estados e integraciones.
Las exclusiones también protegen el proyecto. Migración, textos, tablets, traducciones, web o soporte continuo deben aparecer como incluidos o no incluidos. Lo mismo ocurre con los supuestos sobre APIs, contenido y credenciales.
Los cambios necesitan un procedimiento sencillo
Durante el desarrollo aparecerán datos nuevos. Prohibir cualquier cambio no es realista; aceptarlos todos sin medirlos tampoco.
Cada solicitud debería indicar el resultado buscado, el alcance afectado, la variación de coste y fecha y qué tarea se aplaza si el presupuesto permanece fijo. Solo las personas autorizadas deberían poder aprobarla.
En un proyecto ágil se puede cambiar la prioridad del backlog sin abandonar el control comercial. El contrato debe explicar cuándo basta con sustituir una tarea y cuándo se necesita una nueva estimación.
Pagos y aceptación deben mirar el mismo resultado
Un primer pago puede reservar al equipo y cubrir el arranque. Los siguientes son más comprensibles si corresponden a resultados visibles: diseño aprobado, recorrido principal funcionando en pruebas, candidata de lanzamiento o entrega completa.
“Backend al 80 %” no es un hito que el cliente pueda comprobar. Es más útil probar que una persona se registra, reserva, paga en modo de prueba y que el negocio puede encontrar y reembolsar la operación.
Define el periodo de revisión, los fallos que bloquean la aceptación y cómo se registra la versión aceptada. El contrato también debe aclarar el efecto del silencio, del uso en producción o de una respuesta tardía según la legislación aplicable.
“Ser propietario de la app” no es una cláusula suficiente
Una aplicación reúne código móvil, backend, infraestructura, base de datos, diseño editable, ilustraciones, documentación, textos y materiales de tiendas. El acuerdo debe distinguirlos.
Para cada grupo hay que saber si existe cesión, licencia exclusiva o permiso limitado; cuándo entra en vigor y si el cliente podrá modificar, encargar mantenimiento a otra empresa, operar en nuevos países o transferir el producto.
Separa el trabajo creado para el proyecto de las herramientas anteriores de la agencia. También hay que identificar SDK, tipografías, imágenes y código abierto. Nadie puede ceder derechos que no posee.
La OMPI reúne materiales específicos sobre propiedad intelectual y contratos de aplicaciones. Son útiles para entender que una app contiene varias capas jurídicas y técnicas, no solo líneas de código.
La entrega del código debe permitir trabajar
“Se entregará el código fuente” puede significar un ZIP incompleto. Conviene nombrar los repositorios, historial, ramas, instrucciones de compilación, dependencias, configuración de publicación, pruebas y documentación.
El cliente puede tener acceso al repositorio durante el proyecto. Si se transfiere después, GitHub conserva muchos elementos, pero documenta excepciones en permisos, paquetes y páginas. También hay que revisar la propiedad de la organización y la facturación.
La prueba más útil consiste en pedir a una persona que no participó en el desarrollo que genere una versión de prueba. La lista de entrega y documentación explica cómo comprobar el resto de activos.
Las cuentas críticas deberían pertenecer al negocio
App Store Connect, Google Play Console, dominio, nube, proveedor de pagos y servicios esenciales deberían estar bajo una identidad empresarial estable. El equipo recibe permisos adecuados, no un único usuario compartido.
Apple y Google permiten transferir aplicaciones, pero no todos los datos o ajustes se mueven igual. Es más seguro acordar la propiedad antes de publicar que convertir una transferencia compleja en el plan normal.
Registra también quién paga las renovaciones, quién recibe alertas y quién puede modificar producción. Una app entregada puede quedar fuera de servicio por una tarjeta caducada en una cuenta personal.
¿Tienes una idea de app y quieres el siguiente paso?
Revisar mi ideaComponentes externos y costes recurrentes
Solicita una relación de dependencias importantes, licencias y servicios de pago. Para un producto pequeño puede ser una lista sencilla; para sectores exigentes puede ser un inventario formal de componentes.
El contrato debe indicar quién aprueba un proveedor nuevo y qué ocurre si cambia de precio, licencia o deja de existir. El código abierto sigue sujeto a condiciones concretas.
No tiene sentido exigir a la agencia la propiedad de un SDK ajeno. Sí tiene sentido asegurar que el cliente conoce la licencia, controla la cuenta necesaria y puede sustituirlo.
Seguridad, privacidad y acceso a datos
Conviene traducir “desarrollo seguro” en requisitos: autenticación, permisos, cifrado, registros, copias, tratamiento de vulnerabilidades y aviso de incidentes. Los productos sensibles pueden necesitar un anexo y pruebas específicas.
Si el proveedor trata datos personales por cuenta del cliente en la UE o el EEE, puede ser necesario un contrato de encargado del tratamiento conforme al RGPD. La Comisión Europea publica cláusulas tipo para responsables y encargados.
Aclara qué entornos pueden contener datos reales, quién autoriza el acceso, qué subencargados intervienen y cómo se devolverán o eliminarán los datos al terminar.
Defecto, cambio y mantenimiento no son lo mismo
Un defecto incumple el alcance aceptado. Un cambio añade o modifica comportamiento. El mantenimiento cubre trabajo posterior, como nuevas versiones de iOS y Android, SDK, vigilancia y mejoras.
Define el periodo de corrección, las gravedades, el canal y las exclusiones. Un soporte gratuito e ilimitado resulta tan poco claro como considerar cambio cualquier fallo.
Después del lanzamiento conviene acordar capacidad, prioridades y responsables. La guía de mantenimiento de aplicaciones móviles explica qué tareas siguen existiendo.
Preparar la salida evita un bloqueo
El proyecto puede parar por estrategia, financiación, rendimiento o acuerdo mutuo. La cláusula de terminación debería tratar trabajo terminado y en curso, facturas, licencias, datos, credenciales y reservas de equipo.
Pide una entrega mínima después de cada hito pagado: código actualizado, diseño editable, documentación disponible, entornos y problemas conocidos. Define el tiempo y la tarifa de cualquier transición adicional.
Al finalizar, el cliente debe poder retirar permisos sin romper producción y el proveedor debe poder demostrar la devolución o eliminación acordada de secretos y datos.
Señales de alerta
Revisa con cuidado frases como “el cliente será propietario de la app” sin enumerar activos; aceptación decidida solo por el proveedor; entrega del código tras un “pago final” no definido; cuentas de tiendas personales; ausencia de proceso de cambios; licencias de terceros ocultas o soporte sin límite.
Comprueba también que la propuesta, el anexo de alcance y el contrato no se contradicen. Un listado comercial detallado sirve de poco si el documento principal lo declara meramente orientativo.
Cómo prepara Appfyl el control del proyecto
Antes de la revisión jurídica, Appfyl organiza la primera versión por perfiles, recorridos, operaciones internas, integraciones y dependencias del cliente. Así, el anexo de alcance puede describir hechos concretos.
También acordamos cuentas empresariales, demostraciones por hitos y materiales de entrega desde el inicio. Se revisan recorridos funcionales, no porcentajes abstractos.
La guía de preguntas para una agencia de desarrollo ayuda a comparar proveedores. El brief de estimación de Appfyl permite ordenar las funciones antes de cerrar la documentación comercial.
¿Quieres ver cómo Appfyl convierte el alcance en productos lanzados? Ver casos de Appfyl.
Convierte la investigación en un plan
Appfyl convierte tu idea en un plan claro, una lista de funciones y el primer tramo de trabajo.
Hablar del plan de la appPuntos clave
- Vincula alcance, pago y aceptación a resultados verificables.
- Distingue trabajo nuevo, herramientas previas y componentes de terceros.
- Mantén tiendas, infraestructura y proveedores bajo control empresarial.
- Separa defectos, cambios y mantenimiento.
- Exige una entrega utilizable en cada hito importante.
- Utiliza esta lista para preparar asesoramiento jurídico, no para sustituirlo.
Enlaces útiles
Preguntas frecuentes
La cesión o licencia prevista debe quedar escrita y revisarse bajo la legislación aplicable. El cliente suele necesitar derechos y materiales suficientes para operar, modificar y cambiar de proveedor, mientras que herramientas anteriores y componentes externos pueden tener licencias separadas.
Solo si el hito se puede comprobar. El pago por tiempo también puede funcionar cuando existen límite de presupuesto, prioridades y seguimiento. Muchos proyectos combinan alcance inicial con cambios valorados aparte.
La versión, entorno, casos de prueba, periodo de revisión, defectos bloqueantes y forma de firma. Debe probar recorridos completos y operaciones administrativas relevantes.
En una app encargada por una empresa, suele ser más resistente que la propia empresa controle las cuentas y conceda permisos al equipo. Así conserva identidad jurídica, acuerdos y facturación.
Sirve como inventario inicial, pero no conoce la arquitectura, el modelo comercial, el país ni los datos del proyecto. Reúne primero los hechos y encarga a un profesional la adaptación y revisión.