Contratar el desarrollo de una aplicación requiere 5 garantías contractuales: alcance verificable, pruebas de aceptación documentadas, un proceso de aceptación y cambios, titularidad definida de las cuentas y un plan práctico de continuidad. Una propuesta se puede comparar cuando explica qué se entregará, quién verificará el resultado y cómo se resolverá un desacuerdo.
Estas garantías empiezan antes del desarrollo y continúan hasta la transferencia a operaciones. Pide anexos que permitan a tu equipo probar el comportamiento acordado, distinguir un defecto de una solicitud nueva e identificar al responsable. Revisar el portafolio ayuda a elegir un proveedor. El contrato debe convertir esa elección en responsabilidades observables durante toda la entrega.
La primera garantía es un alcance que describe comportamientos completos
Un alcance verificable describe qué puede hacer cada perfil de usuario, bajo qué condiciones y con qué resultado esperado. «App con pagos» no explica cargos rechazados, cancelaciones, reembolsos, confirmaciones tardías ni conciliación. Especifica las situaciones que afectan al cliente y a quienes administran el servicio.
En un producto hipotético de reservas, el cliente elige una cita disponible, paga y recibe la confirmación. Si el cobro falla, una regla definida libera o retiene la cita. Añade quién puede reprogramarla, cuándo se solicita un reembolso y qué ve el personal en el panel administrativo. Esas decisiones crean una referencia para estimar el trabajo y probar su aceptación.
Documenta también exclusiones, dependencias y supuestos. ¿Quién entrega la identidad visual, el contenido, el acceso al ERP y las credenciales del proveedor de pagos? Si un tercero no ofrece un entorno de prueba, ¿cómo se validará la integración? Cada dependencia externa necesita un responsable y una consecuencia definida en el calendario, en vez de convertirse en una explicación genérica de cualquier retraso.
El anexo no puede anticipar todas las decisiones futuras del producto. Debe permitir reconocer la entrega contratada e identificar los cambios cuando aparezcan. Para la etapa anterior de selección, la guía para elegir una empresa de desarrollo de aplicaciones aborda otro grupo de decisiones.
La segunda garantía son pruebas de aceptación con evidencia conservada
Las pruebas de aceptación verifican si una versión cumple los comportamientos de negocio acordados, con criterios establecidos antes de la demostración. Asigna a una persona del negocio para consolidar las decisiones e involucra a quienes realizan las tareas. De lo contrario, cada departamento aprueba una interpretación distinta y las observaciones importantes llegan cerca del lanzamiento.
Piensa en una app hipotética de servicios con perfiles de cliente, proveedor y soporte. El cliente cancela, el proveedor ve la cancelación y soporte identifica la política aplicable. Registra la versión, los pasos, el resultado esperado y los defectos. Usa datos de prueba adecuados para que reproducir un problema no exija exponer información de clientes innecesariamente.
Una presentación en video demuestra avances, pero el personal también necesita acceso a un entorno de pruebas. Acuerden la frecuencia de entrega, el plazo para comentarios y el registro de incidencias. Megaleios entrega versiones de prueba cada 2 semanas. Esa frecuencia permite revisar el avance; no define la duración completa del proyecto ni elimina la responsabilidad del cliente de participar en la validación.
La tercera garantía es acordar por adelantado la aceptación y los cambios
La aceptación necesita criterios escritos, responsables de las decisiones y reglas para los asuntos pendientes. Separa el incumplimiento de un requisito existente de una nueva decisión de producto. El primero sigue el proceso de corrección; la segunda requiere evaluar alcance, precio y plazo antes de autorizarla.
En una app hipotética de comercio, la versión acordada permite recoger pedidos en un local. Añadir entregas con cálculo de tarifas de transportistas cambia el alcance. Sumar incorrectamente un pedido de recogida es un defecto frente a la regla contratada. Esta distinción sirve más que discutir si un cambio parece pequeño en una pantalla.
| Tema contractual | Promesa poco clara | Compromiso verificable |
|---|---|---|
| Alcance | «App completa» | Flujos, perfiles, límites y exclusiones |
| Pruebas de aceptación | «Presentaciones periódicas» | Entorno, versión, guiones y evidencia |
| Aceptación | «Aprobación del cliente» | Criterios, responsable y tratamiento de incidencias |
| Cambios | «Ajustes incluidos» | Clasificación, impacto y autorización |
| Continuidad | «Entregamos el código» | Momento, materiales y verificación de la transferencia |
Separa desarrollo, pruebas de aceptación, envío y revisión de la tienda en el calendario. Las App Review Guidelines de Apple pertenecen a un proceso externo. Asigna responsabilidades para preparar los envíos y responder preguntas, sin tratar la decisión o el plazo de aprobación como algo que controla exclusivamente el desarrollador.
El acuerdo y su redacción jurídica deben definirse con las personas responsables de la revisión legal. Los criterios de aceptación del negocio ayudan a aclarar la entrega. No sustituyen decisiones sobre propiedad intelectual, responsabilidad, condiciones aplicables ni obligaciones específicas del proyecto.
La cuarta garantía es controlar claramente las cuentas y los accesos
Las cuentas de las tiendas, dominios, alojamiento y proveedores esenciales necesitan un titular, un responsable de facturación y una política de acceso. Da preferencia a cuentas empresariales controladas por el cliente cuando corresponda al producto y a las reglas del proveedor. Resuelve quién recibe los avisos de renovación y quién puede autorizar una publicación antes de llegar a la última semana.
Apple documenta distintos roles de cuenta y Google Play permite configurar permisos de cuenta y aplicación. Utiliza esos mecanismos para conceder accesos adecuados, en vez de depender de una contraseña personal compartida. La configuración también debe corresponder al tipo real de cuenta y a las reglas del servicio.
Mantén un inventario de servicios que identifique titular, administrador, contacto de facturación, método de recuperación y destino de alertas. Especifica quién puede invitar o retirar miembros. Incluye la retirada de acceso del proveedor cuando corresponda, preservando la disponibilidad del servicio. Administrar cuentas y definir la titularidad contractual de los materiales son responsabilidades relacionadas, pero requieren decisiones distintas.
La quinta garantía es la continuidad del código, los datos y la operación
Un plan de continuidad ofrece a otro profesional autorizado material suficiente para comprender, ejecutar y mantener el proyecto bajo los derechos y las condiciones acordados. El código fuente por sí solo no explica cómo desplegar una versión, configurar servicios externos, restaurar datos ni identificar dependencias de terceros.
La lista de entrega debe cubrir repositorios, documentación, configuración del entorno, dependencias y procedimientos operativos relevantes. Define cómo se gestionan credenciales y secretos sin colocarlos en documentos abiertos. Para los datos del negocio, acuerda formatos de exportación y responsabilidades de conservación o eliminación según las necesidades del proyecto.
Verifica la transferencia con una persona autorizada que siga las instrucciones recibidas. Un entorno separado y datos adecuados permiten hacerlo sin convertir la prueba en un incidente de producción. Registra instrucciones o accesos faltantes antes de cerrar la transición. El objetivo es un procedimiento repetible, no una carpeta de archivos que nadie intentó utilizar.
La garantía y la evolución del producto necesitan límites separados. Corregir un comportamiento contratado es distinto de construir otro módulo. Megaleios transfiere el código fuente y la documentación después del pago completo y ofrece 60 días de garantía después del lanzamiento; la evolución posterior se contrata aparte. La propuesta debe expresar estos términos para cada proyecto.
Cinco errores dificultan aplicar el acuerdo
- Firmar solo una lista de pantallas. Añade comportamientos, límites, dependencias y criterios de aceptación para verificar cada flujo.
- Aprobar la apariencia de una demostración. Prueba la versión en el entorno de validación y registra los resultados, incluidas las condiciones de fallo esperadas.
- Aprobar cambios solo de palabra. Documenta la decisión y su impacto antes de incorporar trabajo adicional.
- Dejar cuentas esenciales bajo el acceso personal de alguien. Define titularidad, invitaciones por rol, facturación y recuperación bajo responsabilidad empresarial.
- Pedir documentación solo al final. Especifica desde el inicio los materiales, el momento de entrega y una verificación práctica.
Una propuesta útil cubre todo el proyecto y sus límites
Un precio y un plazo responsables dependen del diagnóstico del alcance y sus dependencias. En el modelo de Megaleios, un MVP puede requerir 4–6 semanas de desarrollo y un producto más complejo, 8–10, sujetos al diagnóstico. Son períodos de desarrollo, no promesas automáticas sobre preparación, aprobación de tiendas ni tiempo total hasta que el producto esté operando.
Fundada en 2012 por Fabiano Belmonte, Megaleios realiza desarrollo de aplicaciones móviles con alcance, precio y plazo acordados después del diagnóstico. El caso CIAB FEBRABAN documenta aplicaciones iOS y Android con panel administrativo y agenda en vivo. Es evidencia de trabajo entregado; cada contrato necesita su propia revisión. El proceso de trabajo explica cómo se organiza el proyecto.
Trae la propuesta y los compromisos que tu equipo todavía no puede verificar. Habla del alcance de tu app con un especialista.