Cuándo una app móvil sí hace falta
El teléfono ya es el lugar donde tus clientes resuelven casi todo. Eso no significa que cada negocio necesite una aplicación instalada. Muchas veces un sitio rápido, o una aplicación web que se abre en el navegador, cubre la tarea sin pedirles que descarguen nada ni que tú pagues dos cuentas de tienda.
Devstoremx propone una app móvil cuando aparece al menos una de estas necesidades: uso con mala señal, cámara o sensores del teléfono, avisos que tienen que llegar aunque la persona no tenga el sitio abierto, o un flujo que se repite tanto que un ícono en la pantalla de inicio cambia el hábito. Si ninguna de esas es cierta, te lo decimos y cotizamos el canal que sí corresponde.
El trabajo es remoto, con negocios en cualquier parte de México. No hace falta una oficina en la misma ciudad para revisar pantallas: se prueban en teléfonos reales y se comentan en llamada.
Qué se construye
El alcance se escribe en pantallas y tareas, no en “la app”. Una primera versión sana suele tener:
- Acceso: crear cuenta, entrar y recuperar el acceso, si la app no es anónima.
- La tarea principal y nada más. Pedir, consultar, escanear, registrar una visita, ver un estado.
- Los estados vacíos y los errores. Sin conexión, sin resultados, sin permiso de cámara.
- Avisos, solo si hay un evento que la persona no puede perderse. Los avisos decorativos se terminan apagando.
- La publicación en la tienda que se haya elegido, con los textos, ícono y capturas que esa tienda pide.
- Una forma de que el negocio vea la información, casi siempre un panel web chico, no otra app para el administrador.
El panel de administración, si la operación es de escritorio, se parece más a una aplicación web y se puede entregar en el navegador. Obligar al gerente a usar la misma app del cliente suele ser un error.
iOS, Android y las tiendas
Cada tienda revisa la app con sus reglas. Un rechazo alarga la fecha y no se resuelve “apretando”. Por eso la cuenta de desarrollador se abre a nombre del negocio desde el principio, y los textos de privacidad y de permisos se redactan con lo que la app hace de verdad. Pedir acceso a contactos o ubicación “por si acaso” es una forma habitual de que la revisión se detenga.
Las cuotas de las tiendas las cobra Apple o Google, no Devstoremx. Van aparte de la propuesta de desarrollo. También va aparte lo que cueste el servidor si la app habla con uno.
Si solo uno de los dos sistemas operativos concentra a tus usuarios, empezar por ese reduce el alcance. El segundo se puede planear cuando el primero ya se usa. Hacer los dos “para que esté completo” antes de saber si alguien abre la app es la forma cara de aprender.
Qué no prometemos en la primera versión
No prometemos que la tienda la destaque, ni un número de descargas, ni que sustituya a tu página web. La gente te sigue buscando en Google por el nombre del negocio. La app es para quien ya decidió usarla.
Tampoco metemos en la primera versión el programa de puntos, el chat, la tienda completa y el modo offline si el negocio todavía no tiene el flujo básico. Cada una de esas piezas se puede hacer. Juntas, sin un uso real, producen una app que tarda y que el equipo no alcanza a operar.
Las conexiones con tu tienda, tu CRM o tus avisos de correo se cotizan como integraciones, con el sistema nombrado.
Cómo sabremos si vale la pena seguir
En la planeación se elige una señal simple: citas creadas desde la app, pedidos repetidos, registros de campo completos. Si esa señal no se puede nombrar, el proyecto todavía no está listo para construirse. Preferimos una llamada que termine en “aún no” a una app instalada que nadie abre.
Cuando sí está lista, la propuesta trae pantallas, sistemas operativos, qué entra en la tienda y qué se deja fuera. El calendario considera la revisión de la tienda, no solo los días de programación.
