«Pagamos por ello, así que nos pertenece» es la suposición habitual. Que sea cierto depende completamente de lo que estipule el contrato y, en ausencia de una cláusula, la norma predeterminada en muchas jurisdicciones favorece al desarrollador.
Qué debe abarcar la propiedad
Un contrato que gestione esto correctamente aborda cuatro aspectos por separado:
- Código fuente personalizado escrito específicamente para este proyecto.
- Recursos de diseño: pantallas, iconos, ilustraciones y los archivos fuente editables, no solo las imágenes exportadas.
- Datos: todo lo que almacena la aplicación, que debería pertenecer inequívocamente al cliente.
- Documentación: especificación, notas de arquitectura e instrucciones de implementación.
La cláusula que debe buscarse transfiere al cliente la propiedad del trabajo personalizado tras el pago final. Dos detalles son importantes: la transferencia debe producirse con el pago, no en algún momento posterior, y debe especificar claramente que incluye los archivos fuente de diseño, que con frecuencia se olvidan y son difíciles de obtener después.
Qué no puede poseer
Algunos componentes se licencian en lugar de transferirse, y esto es normal:
- Bibliotecas de código abierto. Toda aplicación moderna utiliza muchas. Vienen con sus propias licencias, la mayoría de las cuales permiten el uso comercial libremente. Lo importante es que las licencias sean compatibles con su uso; solicitar una lista de ellas es razonable.
- Componentes comerciales: una biblioteca de gráficos de pago, una fuente con licencia o una plantilla adquirida. Estos elementos tienen licencias que pueden ser por proyecto, por desarrollador o por implementación, y la licencia debe transferirse a usted o volver a adquirirse.
- Código de framework preexistente del desarrollador. Muchas agencias reutilizan herramientas internas entre proyectos. Esto es legítimo y normalmente beneficioso, pero debería concedérsele una licencia perpetua en lugar de dejarlo sin definir; de lo contrario, parte de su aplicación pertenecerá a otra persona.
Las imágenes de stock son un problema recurrente. Las imágenes licenciadas para una maqueta a veces no están licenciadas para su uso en producción, y descubrirlo después del lanzamiento resulta costoso. Merece la pena preguntar de dónde procede cada imagen; solo le llevará cinco minutos.
El paquete de entrega
La prueba de una entrega es sencilla: ¿podría hacerse cargo un desarrollador competente que nunca haya visto este proyecto? Para ello se necesita:
- El repositorio completo con su historial, transferido a una cuenta que controle el cliente. El historial de confirmaciones es importante: es la forma en que un nuevo desarrollador entiende por qué las cosas son como son.
- Instrucciones de implementación lo bastante detalladas como para reconstruir el entorno desde cero.
- Configuración del entorno: qué ajustes existen, para qué sirven y cuáles son secretos.
- Todas las credenciales de las cuentas: alojamiento, dominio, base de datos, servicios de terceros y cuentas de tiendas, transferidas a la propiedad del cliente.
- Esquema de la base de datos y cualquier script de migración.
- Inventario de servicios de terceros con el uso de cada uno y su coste.
- Archivos fuente de diseño.
- Problemas conocidos y elementos aplazados, documentados con honestidad.
Vale la pena solicitar explícitamente este último elemento. Todo proyecto tiene compromisos conocidos, y un desarrollador dispuesto a documentarlos está proporcionando al cliente algo realmente valioso.
Verificar que la entrega funciona
La verificación más sólida consiste en pedir a alguien independiente que implemente la aplicación únicamente a partir del paquete de entrega, en un entorno nuevo y sin preguntar nada al desarrollador original. Si lo consigue, la entrega es real.
Hacerlo mientras la relación aún es buena resulta mucho más sencillo que hacerlo una vez finalizada. Es razonable supeditar una pequeña parte del pago final a este proceso.
Custodia del código fuente
Cuando el desarrollador conserva el código, como ocurre a veces en acuerdos basados en plataformas o suscripciones, la custodia del código fuente deposita una copia en manos de un tercero, que la entrega al cliente bajo condiciones definidas, como que el desarrollador deje de operar.
Cuesta dinero y añade gestión, y resulta principalmente proporcional cuando la aplicación es crítica para el negocio y el desarrollador es pequeño. Para la mayoría de los proyectos pequeños, una transferencia directa de la propiedad junto con una entrega verificada logra más por menos.
Resolverlo antes de empezar
- Quién es propietario del código personalizado y desde cuándo.
- Si se incluyen los archivos fuente de diseño.
- Cómo se licencia el código preexistente del desarrollador.
- Que los datos pertenezcan inequívocamente al cliente, en un formato exportable.
- Qué contiene el paquete de entrega.
- Que las cuentas se creen a nombre del cliente desde el principio.
Servicios relacionados de Manboo
- Desarrollo de aplicaciones Flutter para MVP de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles operativos y gestión del backend.
- Integración de API de IA cuando su producto esté listo para búsquedas inteligentes, chat o automatización.
- Solicite una revisión del alcance y un presupuesto del proyecto cuando esté listo para planificar la primera versión.