Soluciones
Una aplicación para Android y iOS, no dos desarrollos en paralelo.
Desarrollo multiplataforma con Flutter: una base de código, dos tiendas y el mismo equipo respondiendo por las dos.
Cuándo hace falta
Señales de que el navegador ya no alcanza.
Una aplicación no se justifica por tenerla. Se justifica cuando pasa algo de esto:
- El uso ocurre fuera del escritorio: en campo, en piso de venta o en movimiento.
- Hace falta algo que el navegador no da: notificaciones, cámara, ubicación o trabajo sin conexión.
- Ya existe una plataforma web y los usuarios entran desde el teléfono todos los días.
- Hay dos aplicaciones —una por sistema operativo— que llevan meses separándose entre sí.
- La aplicación actual dejó de recibir actualizaciones y la tienda empieza a advertirlo.
- Hay que distribuir una herramienta al equipo interno sin publicarla al público.
Qué construimos
Tipos de aplicación.
Operación en campo
Captura, evidencia fotográfica, firmas y estados con sincronización cuando vuelve la señal. El trabajo no se detiene porque se cayó la conexión.
Portal de cliente en el teléfono
Consulta de estado, documentos, avisos y trámites. La misma información que el portal web, en la pantalla donde de verdad se mira.
Herramientas internas
Aplicaciones para el equipo, distribuidas por canal privado o por las tiendas con acceso restringido.
Contenido y aprendizaje
Cursos, evaluaciones, seguimiento de avance y descarga para consultar sin conexión.
Segunda pantalla de una plataforma
Cuando el sistema ya existe, la aplicación consume la misma API y no duplica reglas de negocio.
Rescate de una aplicación existente
Diagnóstico de una base heredada, actualización de dependencias y cumplimiento de los requisitos que hoy exigen las tiendas.
Cómo se construye
Una base de código, y decisiones nativas donde de verdad importan.
Una base de código, y decisiones nativas donde de verdad importan.
Flutter no se elige por moda: se elige porque dos equipos construyendo la misma aplicación producen dos aplicaciones distintas, y la diferencia aparece justo en las funciones que menos se prueban. Lo que sí es específico de cada sistema —permisos, notificaciones, publicación— se trata como tal y no se esconde bajo una capa que finge que no existe.
- Una base de código en Flutter, con la capa nativa aislada y declarada.
- La lógica de negocio vive en el servidor, no repartida entre dos aplicaciones.
- Estado sin conexión con resolución de conflictos definida, no «se sincroniza solo».
- Cuentas de tienda a nombre del cliente, con los accesos entregados y documentados.
- Versionado y despliegue por canales: interno, prueba y producción.
- Registro de fallos en producción, para enterarse antes de que lo reporte un usuario.
- Flutter
- Dart
- Android
- iOS
Cómo se entrega
De la idea a las dos tiendas.
Discovery
Qué hace la gente hoy, en qué momento y con qué en las manos.
Prototipo
Un flujo navegable en el teléfono, criticable antes de construirlo.
Construcción
Entregas revisables por canal interno, no una única versión al final.
Publicación
Fichas, revisiones de tienda, permisos y política de privacidad.
Operación
Actualizaciones, seguimiento de fallos y compatibilidad con versiones nuevas.
Flutter está en nuestro stack declarado y el desarrollo móvil forma parte del trabajo del equipo, pero todavía no hay una aplicación publicada que podamos enseñar con nombre en /casos. Preferimos decirlo en esta página y no en la segunda reunión.
¿Tiene sentido una aplicación en tu caso?
Cuéntanos dónde y cómo se usa hoy. A veces la respuesta es que no hace falta.