Quién abre la app primero, qué debe seguir compatible la API, luego prototipo, build, pruebas en dispositivos y envío a tiendas.
Fichaje de empleado, recompra de cliente y un catálogo de canal son tres apps. Offline, push y listado son las razones habituales para dejar el navegador. Escribid el primer trabajo antes de elegir un framework.
Los builds viejos siguen en la calle. Diseñad versiones, autenticación y auditoría para que una actualización forzada sea último recurso, no el plan semanal.
Permisos, estados vacíos, fallo de pago y sesiones caducadas. Las pantallas bonitas del camino feliz no sobreviven a los usuarios de tienda.
Probad en el hardware que vais a soportar. Luego enviad con privacidad y material de pago ya escritos. La consola de operador viaja con el cliente: no es una secuela.
El diseño visual puede solaparse con el build. Cuentas de tienda, IDs de comercio y textos de privacidad deben empezar pronto: bloquean la publicación.
En dispositivos y en la API, incluido un build viejo. Un QA solo web es cómo fallan las apps de campo el primer día.
Un texto pequeño puede esperar. Cambios de permiso o de pago suelen significar otra revisión. Lo ponemos en la nota de versión, no en una sorpresa.
Escribid el trabajo del primer minuto y la API que ya tenéis. Lo convertiremos en un build secuenciado en /es/app/.