12 cosas que comprobar antes de firmar con una empresa de desarrollo de apps

Qué tiene que quedar por escrito

• Una cesión íntegra de la propiedad intelectual a favor de tu empresa en el contrato, no una simple licencia de uso que el proveedor pueda revocar o condicionar.
• El repositorio creado desde el primer commit en una organización de código cuyo titular seas tú, no en la cuenta personal ni en la organización del proveedor.
• Entrega del historial de commits completo, no un volcado final en zip: sin ese historial no puedes auditar quién hizo qué ni revertir cambios con contexto.
• Un listado de dependencias y librerías de terceros con sus licencias declaradas: una GPL mal gestionada te puede obligar a liberar tu propio código, mientras que MIT o Apache no.
• Los scripts de build y pipelines de despliegue incluidos en la entrega, no solo el código de la aplicación: sin ellos no puedes compilar ni desplegar una nueva versión.

Qué tiene que quedar por escrito

• La cuenta de Apple Developer Program (99 USD al año) dada de alta a nombre de tu empresa, con tu CIF o razón social como titular legal, nunca del proveedor.
• La cuenta de desarrollador de Google Play (25 USD de alta única) igualmente registrada bajo tu empresa, no bajo la del proveedor.
• Que el titular legal que aparece en la ficha pública de ambas tiendas sea tu empresa, no una marca comercial del proveedor.
• Acceso de administrador para tu equipo desde el inicio, con capacidad de añadir o revocar usuarios sin depender del proveedor.
• Entrega de los certificados y claves de firma: el keystore de Android y los certificados de distribución de iOS, custodiados por ti y no solo por el proveedor.

Qué tiene que quedar por escrito

• Un alcance cerrado con la lista concreta de pantallas y funcionalidades incluidas, no una estimación abierta por horas que se ajusta sobre la marcha.
• Qué entra y qué no entra en el precio: diseño de interfaz, backend, pruebas, publicación en tiendas y correcciones posteriores al lanzamiento.
• Un procedimiento escrito para cambios de alcance: cómo se solicitan, cómo se valoran y a qué precio se cobran las funcionalidades añadidas a mitad de proyecto.
• Hitos de pago ligados a entregables verificables y funcionando, no a fechas del calendario ni a porcentajes de avance declarados por el proveedor.
• Una garantía de corrección de errores tras la entrega, con su duración explícita y qué tipo de fallos cubre.

Qué tiene que quedar por escrito

• Si la app se construye en nativo (Swift para iOS, Kotlin para Android), en multiplataforma (Flutter, React Native) o como una web envuelta en una carcasa de app.
• Que la elección tecnológica se justifique por el caso de uso real de tu app, no por la tecnología que el proveedor ya domina y le resulta más barata de producir.
• Qué funcionalidades del dispositivo necesita tu app (cámara, geolocalización, notificaciones, pagos) y si la tecnología elegida las soporta de forma nativa o requiere plugins añadidos.
• El impacto en rendimiento y en coste de mantenimiento: una base de código única frente a dos bases nativas separadas que hay que actualizar por duplicado.
• Que la tecnología elegida tenga mercado suficiente de desarrolladores disponibles el día que decidas cambiar de proveedor, y que no dependas de un framework de nicho que solo domina tu proveedor actual.

Qué tiene que quedar por escrito

• El backend corre en una cuenta cloud (AWS, Google Cloud, Azure) a nombre de la empresa cliente, con el proveedor como administrador delegado, nunca al reves.
• La base de datos y sus copias de seguridad son exportables por el cliente en cualquier momento, en un formato estandar, sin depender de que el proveedor genere el volcado.
• La documentacion de la API (endpoints, esquemas, autenticacion) se entrega como artefacto propio, no como conocimiento que solo tiene el equipo de desarrollo.
• Los servicios de terceros contratados para la app — notificaciones push, analitica, pasarela de pago — quedan dados de alta a nombre del cliente, con sus propias claves y facturacion.
• La politica de copias de seguridad especifica frecuencia, retencion y un simulacro de restauracion ya realizado, no solo una promesa en el contrato.

Qué tiene que quedar por escrito

• Los ficheros fuente del diseño (Figma u otra herramienta equivalente) se entregan en una cuenta o espacio de trabajo propiedad del cliente, no solo como capturas PNG o exportaciones en PDF.
• Un sistema de componentes y guia de estilo documentados — colores, tipografias, espaciados, estados de cada elemento — reutilizables para futuras pantallas sin depender del proveedor original.
• Los iconos, splash screen y capturas para las fichas de tienda entregados en todos los tamaños que exigen App Store y Google Play, listos para subir sin retrabajo.
• Los derechos de imagenes y tipografias usadas en la app quedan documentados con sus licencias, para saber que se puede seguir usando y que no.
• La accesibilidad basica (contraste de color, tamaños de texto legibles, soporte de lector de pantalla) queda contemplada en el diseño entregado, no como pendiente indefinido.

Qué tiene que quedar por escrito

• Un plan de pruebas y criterios de aceptacion escritos y acordados antes de empezar a desarrollar, no improvisados al final del proyecto para justificar la entrega.
• Una matriz de dispositivos y versiones de sistema operativo reales sobre las que se prueba la app, no solo un simulador en el ordenador del desarrollador.
• Cobertura de pruebas automatizadas sobre los flujos criticos del negocio — registro, pago, funcion principal de la app — para detectar roturas en cada entrega.
• Un canal de pruebas previo a produccion activo (TestFlight en iOS, canal interno o cerrado en Google Play) donde el cliente prueba cada version antes de que llegue al usuario final.
• Quien valida cada entrega y con que criterio se considera aceptada, con un proceso claro para rechazar una entrega que no cumple lo pactado.

Qué tiene que quedar por escrito

• Quien hace el envio a revision en App Store y Google Play, y quien responde en caso de rechazo, con plazos de reaccion pactados en el contrato.
• El cumplimiento de las guias de revision de Apple y de las politicas de Google Play revisado antes de cada envio, no descubierto tras el primer rechazo.
• Las etiquetas de privacidad de la ficha (Privacy Nutrition Labels en Apple, formulario de Seguridad de los datos en Google Play) rellenas correctamente, con responsable claro de mantenerlas actualizadas en cada version.
• Los permisos sensibles que pide la app (camara, ubicacion, contactos) justificados uno a uno, porque un permiso sin justificar es motivo habitual de rechazo.
• Un plan para las actualizaciones obligatorias cuando Apple o Google suben la version minima del SDK exigida, para que la app no deje de estar publicable de un dia para otro.

Qué tiene que quedar por escrito

• Quién es responsable del tratamiento (tu empresa) y quién encargado del tratamiento (el proveedor), con el contrato de encargo firmado antes de que la app procese un solo dato real.
• Cada permiso que pide la app —ubicación, cámara, contactos, notificaciones, micrófono— justificado uno a uno, y solicitado en el momento en que el usuario lo necesita, no todos de golpe al abrir la app.
• Cómo se gestiona el consentimiento y el rastreo publicitario, incluyendo el cumplimiento de App Tracking Transparency en iOS antes de cualquier SDK de medición o publicidad.
• Un listado de los SDK de terceros integrados en la app y qué datos envían fuera, revisado por alguien de tu lado y no dado por bueno porque "lo trae el framework".
• La política de privacidad y de retención de datos publicada, y que coincida con lo que la app hace de verdad, no con una plantilla genérica copiada de otro proyecto.

Qué tiene que quedar por escrito

• Qué entra dentro del mantenimiento contratado y qué se factura aparte, con ejemplos concretos de cada categoría para que no haya interpretación el día que llega la factura.
• Correctivo y evolutivo separados en el contrato: arreglar un error que impide usar la app no es lo mismo que pedir una funcionalidad nueva, y no deberían costar ni tramitarse igual.
• Los tiempos de respuesta y de resolución por severidad, con una definición escrita de qué es crítico, qué es grave y qué es menor, no un "lo antes posible" sin más.
• Quién paga las actualizaciones obligatorias que exigen iOS y Android cada año para seguir publicada en las tiendas, y con qué antelación se planifican.
• Un sistema de monitorización de errores en producción y a quién le llega la alerta cuando algo falla, para no enterarte por un usuario enfadado en una reseña de tienda.

Qué tiene que quedar por escrito

• Que el desarrollo inicial es solo una parte del coste total, y que el presupuesto de la propuesta no representa lo que vas a pagar a lo largo de la vida de la app.
• El coste de infraestructura cloud, servicios de terceros y licencias recurrentes —hosting, backend, APIs de pago, mapas, notificaciones push— desglosado por servicio, no como una partida genérica.
• Las cuotas de las tiendas: el Apple Developer Program cuesta 99 USD al año y el alta de una cuenta de Google Play es un pago único de 25 USD, ambas necesarias para que la app siga publicada.
• El coste de las dos o tres actualizaciones anuales obligatorias por cambios de plataforma, presupuestadas desde el inicio y no como sorpresa el primer año.
• El coste interno de la persona o equipo que gestiona al proveedor, revisa entregas y coordina prioridades, que rara vez aparece en la hoja de cálculo pero consume tiempo real.

Qué tiene que quedar por escrito

• Un plan de transferencia escrito y firmado desde el contrato inicial, no negociado el día en que decides romper la relación y ya no tienes margen de maniobra.
• La entrega de código, credenciales, claves de firma, cuentas de tienda, documentación de despliegue y datos exportados, con formato y plazo concretos, no un "os lo pasamos cuando podamos".
• Un periodo de acompañamiento a la salida y a qué precio, para que el traspaso al nuevo proveedor no dependa de la buena voluntad del anterior.
• Que el conocimiento del proyecto no viva solo en la cabeza de una persona del proveedor, sino documentado y accesible para cualquiera que retome el desarrollo.
• Que ningún componente crítico de la app sea propietario del proveedor ni quede bajo una licencia que él pueda revocar en el momento en que te vas.