Diseñé la app móvil con una herramienta gratuita: ¿se la entrego a una agencia o la hago de cero?

El código que exportan las herramientas gratuitas suele ser un espagueti lleno de librerías innecesarias y con un consumo de memoria altísimo. Si la app se cuelga a primera hora de la mañana cuando los restaurantes están metiendo pedidos, pierdes clientes directamente. Usa tu diseño como referencia visual, pero que programen el código limpio.

Al evaluar presupuestos exige tres cosas por contrato: 1) La propiedad del código fuente se transfiere a tu empresa desde el primer día, 2) La gestión de aprobación en Apple y Google va incluida, 3) Al menos tres meses de soporte técnico gratuito tras el lanzamiento para corregir fallos.

El del presupuesto de 12.000 SAR dejará de coger el teléfono en dos meses y ahí entenderás por qué la agencia pedía 40.000 SAR. El software barato siempre se acaba pagando al menos dos veces.

Saca captura de cada pantalla del prototipo y monta un PDF con el diagrama de flujo. Preséntalo como pliego técnico al pedir presupuesto a las agencias. Así les quitas la excusa para meterte costes extra fuera de alcance.

En Yeda mandamos hacer una app B2B de logística desde cero. Como llevábamos nuestro propio prototipo, la agencia bajó el presupuesto de 55.000 SAR a 34.000 SAR porque el tiempo de análisis se redujo a la mitad. El prototipo es una baza buenísima para negociar.

Según la normativa del Ministerio de Comercio de Arabia Saudita, la propiedad del código fuente debe especificarse claramente en los contratos de software. De lo contrario, el código puede considerarse propiedad intelectual de la agencia. Elijas la propuesta que elijas, haz que incluyan en el contrato que el acceso al repositorio de código se abra a nombre de tu empresa.

¿De verdad los restaurantes necesitan una aplicación móvil? ¿No les bastaría al principio con un panel web adaptado a móviles para notificaciones y facturación? ¿Tuvieron en cuenta las comisiones de las tiendas y los gastos anuales de la cuenta de desarrollador?

Ha sido una buena idea abrir este hilo. Tomar notas durante dos semanas da mejores resultados que estimar seis meses.

Yo seguiría por ese camino.

No sabía eso.

De acuerdo, incluso me gustaría recalcarlo. El calendario de pagos debe vincularse a las fases del proyecto, no a fechas fijas.

Lo importante no es la cifra, sino en qué se basa esa cifra. Lo dejo como nota, por si sirve.

yo también tengo curiosidad.

Guardado. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Hay un punto que me genera dudas. Si no lo pones por escrito desde el principio luego surgen discusiones.

Si no se definen los criterios de aceptación, cuándo termina el trabajo es discutible. Ánimo.

Estoy de acuerdo. El código sin documentación de instalación, aunque lo tengas, no es tuyo.

Ha sido una buena idea abrir este hilo.

Yo no me apresuraría. Establecer un proceso de solicitud de cambios no ralentiza el trabajo lo agiliza.

También me gustaría saber si alguien lo hace de otra manera.

Voy a resumir el tema, porque se han dado varias respuestas diferentes. Un informe semanal por escrito funciona mucho mejor que preguntar por fechas.

Si tenéis dudas, escribid, os responderé en la medida de lo posible.

¿Y cómo resolvieron esto? Establecer un proceso de solicitud de cambios no ralentiza el trabajo, lo agiliza.

Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla. Espero que le sea útil.