Descubrimiento y acompañamiento de comerciales
Acompañamiento en campo con gestores regionales, mapeo de la cobertura sin conexión, revisión del enfoque RGPD + CCPA para los registros de clientes, requisitos de acceso basado en roles por territorio.
Caso de éxito · AgTech · Herramientas internas
Caso de éxito Farm: app de ventas en campo offline-first para agricultura
Caso de éxito Farm: cómo lanzamos Farm, una app interna nativa para iOS y Android destinada a un distribuidor de productos agrícolas cuyos gestores de ventas en campo pasan los días en bodegas, almacenes y explotaciones sin cobertura de Estados Unidos y la Unión Europea. Construida sobre un almacén SQLite offline-first, un back office en Laravel + React y una capa de informes de plan frente a real que resiste el escrutinio del RGPD y la CCPA, y que se ha mantenido en uso continuo en producción durante tres años.
El reto: un conjunto de herramientas de ventas en campo que funciona sin señal
El equipo de producto de Farm llegó con un problema operativo concreto. Sus gestores de ventas regionales cubrían territorios agrícolas de Estados Unidos y la Unión Europea, y el flujo de trabajo diario no tenía nada que ver con lo que presupone cualquier app móvil de CRM estándar. Un comercial conducía noventa minutos hasta la explotación de un cliente, perdía la señal móvil dentro de un establo o de una bodega de almacenamiento de fertilizantes, hablaba de precios durante cuarenta y cinco minutos, cerraba un trato y después necesitaba registrarlo, con frecuencia todavía sin cobertura. Las herramientas existentes perdían el informe en silencio o exigían que el comercial se acordara de volver a presentarlo desde el coche. Reconstruimos el flujo de trabajo desde cero como una app interna nativa para iOS y Android: un espejo SQLite offline-first del catálogo de productos, un registro de tratos que se pone en cola localmente y se concilia de forma determinista, y un panel regional de plan frente a real que el director sénior abre al comenzar cada semana. El resultado es un conjunto de herramientas de ventas internas que se despliega en EE. UU. y la UE con las expectativas del RGPD y la CCPA / CPRA desde el primer día, forma parte de la cartera de YuSMP Group de trabajos de desarrollo de aplicaciones móviles y lleva ya tres años funcionando en producción sin supervisión.
Aspectos destacados del proyecto
Clientes nativos para iOS y Android
Catálogo SQLite offline-first
Sincronización de tratos sin conflictos
Informes de plan frente a real
Paneles regionales en React
Back office de administración en Laravel
Acceso basado en roles
3 años en producción · EE. UU. y la UE
En cifras
Un resumen de lo que aportó el desarrollo de Farm en iOS, Android y un back office con Laravel + React durante su primer ciclo de producción y los tres años de explotación posteriores.
2plataformas nativas: iOS en Swift y Android en Kotlin, con bases de código totalmente separadas y optimizadas para cada sistema operativo
3 añosde uso continuo en producción en territorios de ventas en campo de EE. UU. y la UE con telemetría estable
100%de los tratos registrados sin conexión se concilian de forma determinista en la siguiente sincronización correcta, sin duplicados
9 mesesplazo del desarrollo inicial desde el descubrimiento hasta el primer despliegue en producción en ambas tiendas
4categorías de producto principales —fertilizantes, semillas, agentes químicos y equipamiento— en el catálogo estructurado
14–20 sem.plazo de entrega típico de una app interna comparable de ventas en campo en ambas tiendas
Por qué iOS y Android nativos en lugar de una capa multiplataforma
La decisión de plataforma pesó más que cualquier otra decisión de arquitectura. Elegimos Swift nativo en iOS y Kotlin en Android frente a un único shell multiplataforma porque las ventajas e inconvenientes en una ventana de producción de tres años encajan con claridad con la vía nativa. Los clientes nativos nos dieron acceso de primer orden al stack nativo de la plataforma, Core Data y SQLite en iOS y Room sobre SQLite en Android, la base de cualquier arquitectura móvil offline-first defendible. La semántica de la sincronización en segundo plano difiere lo bastante entre BGTaskScheduler en iOS y WorkManager en Android como para que envolver ambos en una única abstracción nos hubiera costado la previsibilidad que necesitaba el equipo de operaciones para comerciales sin supervisión.
Se evaluaron y descartaron los shells multiplataforma —React Native, Flutter, la cola de Xamarin—. Sus abstracciones sobre el trabajo en segundo plano y sobre el SQLite nativo de la plataforma tenían la forma equivocada para un flujo de trabajo de comerciales que pasa horas sin conexión. Elegir lo nativo supuso que todo el stack —interfaz, almacén local, motor de sincronización, entrega de notificaciones push— es propia por plataforma y citable de principio a fin frente a la documentación de desarrollo del propio Apple y Google.
| Criterio | Swift / Kotlin nativos (Farm) | React Native | Flutter |
|---|---|---|---|
| Acceso a SQLite sin conexión | Elemento básico: Core Data y Room | Con puente: WatermelonDB o de terceros | Con puente: sqflite o Drift |
| Sincronización en segundo plano | BGTaskScheduler / WorkManager directos | Envuelta: fiabilidad variable | Envuelta: fiabilidad variable |
| Perfil de batería en sesiones largas sin conexión | Ajustable por plataforma | Más pesado: coste del puente JS | Más ligero que RN, aunque sigue abstraído |
| Coste de mantenimiento a tres años | Dos bases de código estables sobre API del fabricante del SO | Vaivén de actualizaciones del framework | Vaivén de actualizaciones del framework |
| Accesibilidad nativa | VoiceOver / TalkBack de primer orden | Aceptable: con lagunas parciales | Aceptable: con lagunas parciales |
| Fiabilidad de las notificaciones push | APNs / FCM directos | Con puente: Notifee / RNFB | Con puente: firebase_messaging |
| Comportamiento de teclado / configuración regional por SO | Nativo del SO | Envuelto: casos límite | Envuelto: casos límite |
Referencias de la plataforma: documentación de Apple BGTaskScheduler, referencia de Android WorkManager.
Desarrollo para iOS: Swift, Core Data y el flujo de registro de tratos
El cliente de iOS está construido en Swift con SwiftUI para la capa de interfaz y Core Data sobre SQLite para el almacén local. Toda la superficie de registro de tratos se reduce a una única máquina de estados —borrador, en cola, sincronizando, conciliado— y el comercial nunca ve un error de red en el flujo de usuario, porque el informe ya se ha guardado localmente antes de que la pantalla termine su animación de cierre. La búsqueda de clientes se ejecuta contra el almacén del dispositivo sin ida y vuelta por la red, el catálogo se pagina en una lista perezosa y los precios se resuelven a partir de la versión de la lista de precios en caché local que era la vigente en la última sincronización correcta del comercial.
La vía de conciliación es donde la mayoría de las apps internas de ventas pierden corrección, y donde dedicamos un esfuerzo de ingeniería desproporcionado. El flujo es: escribir el informe en Core Data con una marca de tiempo monótona del cliente y una clave de idempotencia UUID, ponerlo en cola en BGTaskScheduler, intentar sincronizar en cada transición de conectividad y dejar que el servidor devuelva el registro canónico de derechos de acceso. Los duplicados son imposibles porque la clave de idempotencia es la correlación principal, y una venta cerrada en una bodega en Suecia y reabierta en un tren dos horas después se concilia sin problemas. Toda la superficie de iOS se entrega como parte de nuestra práctica de ingeniería para iOS y Android.
Desarrollo para Android: Kotlin, Room y el motor de sincronización
El cliente de Android está escrito en Kotlin con Jetpack Compose para la interfaz y una capa de Room sobre SQLite para el almacén local. WorkManager gestiona la programación de la sincronización en segundo plano con una semántica de reintento con espera que respeta el modo Doze y los optimizadores de batería de Samsung, Xiaomi, OnePlus y Pixel; sin un servicio en primer plano, el motor de sincronización moriría en silencio en pocos minutos dentro de un contenedor OEM agresivo, rompiendo el contrato implícito de que un informe sin conexión acaba apareciendo en el panel del gestor. Una notificación persistente mínima mantiene viva la sincronización larga en las familias de dispositivos desde Android 10 hasta Android 14.
El motor de sincronización es donde el cliente de Android demuestra su valor. El delta del dispositivo se envía a una API de Laravel en cada transición de conectividad, el servidor devuelve la lista de precios y el listado de clientes de referencia, y la resolución de conflictos es determinista: el servidor prevalece en precios y registros de clientes, y el cliente prevalece en las notas de campo y los metadatos adjuntos por el comercial. Tras un traspaso de Wi-Fi a LTE, el motor retoma automáticamente el último token de sincronización, y la actualización del catálogo es incremental en lugar de una recarga completa: un comercial con un almacén local de 250 MB no vuelve a descargar el catálogo cada lunes. El mismo equipo de ingeniería lleva iOS y Android en paralelo como parte de nuestra práctica de desarrollo de aplicaciones móviles.
Back office, plan frente a real y enfoque listo para auditoría
El back office de Farm se apoya en una API de Laravel con un panel de administración en React y conserva solo los datos imprescindibles: listado de clientes, catálogo de productos, lista de precios, cuotas de ventas trimestrales y el flujo de informes de tratos que llega desde el campo. No hay seguimiento de la ubicación por comercial, ni captura de pulsaciones de teclado en tiempos de inactividad, ni canal de metadatos hacia un proveedor de observabilidad de terceros. Los contadores que alimentan el panel regional de plan frente a real se agregan en el servidor y se envían como series numéricas anónimas; los identificadores por cliente no salen de la tabla de clientes.
La identidad de facturación de los propios clientes del distribuidor —las explotaciones y cooperativas agrícolas que compran el producto— se conserva en el mismo almacén de Laravel, pero con acceso controlado mediante un modelo de permisos basado en roles para que un comercial de campo vea solo los clientes de su territorio. Las políticas de infraestructura como código hacen cumplir los invariantes de acceso: cualquier pull request que amplíe el alcance de lectura de un comercial o introduzca un registro de ubicación por comercial falla en CI. El enfoque está pensado para alinearse con las obligaciones del RGPD para los usuarios de la Unión Europea y con las obligaciones de la CCPA / CPRA para los usuarios de California y del resto de Estados Unidos, y para que una futura revisión independiente de preparación sea un ejercicio de documentación y no una reforma de la arquitectura.
Enfoque de cumplimiento: alineado con el RGPD · preparado para ISO 27001 · SOC 2 Type II en curso · apto para HIPAA · CCPA contemplada.
Metodología de entrega
Un desarrollo en cinco fases que llevó a Farm de las entrevistas de investigación de territorio a producción en iOS, Android y un back office con Laravel + React.
Catálogo y modelo de sincronización
Esquema del catálogo de productos, precios estructurados, diseño del token de sincronización, contrato de claves de idempotencia para los informes de tratos, esqueleto de la API de Laravel, estructura base del panel de administración en React.
Desarrollos de plataformas
Cliente iOS en Swift / SwiftUI sobre Core Data + BGTaskScheduler; cliente Android en Kotlin / Jetpack Compose sobre Room + WorkManager; máquina de estados del registro de tratos.
Refuerzo de seguridad listo para auditoría
Políticas de infraestructura como código que bloquean regresiones del alcance de acceso, QA de permisos basados en roles, pipeline de telemetría de fallos, revisión del marco operativo a tres años.
Lanzamiento y telemetría
Envío a App Store y Google Play para distribución interna en las tiendas de EE. UU. y la UE, despliegue de los paneles regionales, cambio a plan frente a real para los directores sénior.
Plan frente a real, asignación de cuotas y la vista del gestor
La capa de informes de Farm se construyó para que los informes de campo y la analítica de los gestores estén demostrablemente alineados, porque el bucle de plan frente a real se desmorona en cuanto un gestor y un comercial ven cifras distintas para el mismo cliente en la misma semana. La cuota trimestral la fija un director sénior en el panel de administración en React y se envía al almacén local de cada comercial en la siguiente sincronización. El comercial ve su propio progreso en la app móvil —una única línea de tendencia frente al plan, desglosada por categoría de producto— y el director sénior ve el agregado regional en el back office, con detalle por comercial y por cliente. La agregación en el servidor se ejecuta sobre un único flujo autorizado de informes de tratos que los clientes móviles alimentan por la vía de la clave de idempotencia, de modo que la vista del gestor y la del comercial siempre se concilian con la misma fuente de verdad. El comportamiento de kill-edit, los informes sin conexión que llegan con retraso y las notas de campo adjuntas por el comercial leen todos del mismo registro, así que un trato se resuelve limpiamente tras reinstalaciones, cambios de dispositivo y el eventual portal web. Todo el subsistema se construyó pensando en la extensibilidad: añadir un nivel multidivisa, un motor de comisiones por territorio o una extensión para comerciales socios B2B es un cambio de configuración sobre el back office y no una versión de código.
Lanzamiento en Estados Unidos y la Unión Europea
Farm se lanzó en Apple App Store y Google Play (distribución interna) con tiendas activas en Estados Unidos y la Unión Europea. La versión en inglés atiende a comerciales de ventas en campo de California, Nueva York, Texas, Florida y Washington en EE. UU., y de Países Bajos, Alemania, Francia, Irlanda y Suecia en la UE, sin una base de código distinta por región. Los flujos de consentimiento se adaptan a la región en la capa del back office: las cuentas de comerciales de la UE y el EEE reciben una pantalla granular de consentimiento al estilo RGPD para cualquier telemetría de producto opcional, y las cuentas de California reciben, dentro del mismo flujo de alta, un aviso al estilo CCPA «No vender ni compartir mi información personal». Las prácticas de tratamiento de datos están alineadas con el RGPD para los usuarios europeos y con el mosaico de leyes estatales de privacidad de EE. UU.: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) y la CPA de Oregón. Como la arquitectura minimiza los datos de seguimiento por comercial, el cumplimiento regional se reduce a una divulgación honesta y no a una segregación de datos por jurisdicción.
La API de Laravel se desplegó en paralelo en regiones de la UE y de EE. UU. —Países Bajos, Alemania, Francia, Suecia e Irlanda para la cobertura de la UE; este y oeste de EE. UU. para Norteamérica—, con los workers sin estado de cada región aprovisionados de forma idéntica. El servicio de agregación que alimenta el panel regional de plan frente a real ejecuta workers sin estado que pueden fijarse de forma independiente a regiones de la UE o de EE. UU. para futuros compromisos de residencia de datos. Tanto la distribución en App Store como la de Google Play se calibraron para el alta de empresa interna, y el aviso de privacidad dentro de la app documenta exactamente la arquitectura anterior, citando directamente las obligaciones del RGPD y las obligaciones de la CCPA de California. El equipo de ingeniería que respalda el desarrollo trabaja en horario CET y mantiene una jornada CET con solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias (stand-ups), la coreografía de revisión de las tiendas y la respuesta a incidencias: la zona horaria que permite a un equipo de producto de EE. UU. y a un equipo de ingeniería de la UE compartir cuatro horas de solapamiento en directo cada día.
Stack tecnológico y hoja de ruta
Swift
SwiftUI
Core Data
BGTaskScheduler
Kotlin
Jetpack Compose
Room
WorkManager
SQLite
Laravel
PHP 8
React
PostgreSQL
Redis
APNs
Firebase Cloud Messaging
Docker
Terraform
Prometheus
La hoja de ruta activa de desarrollo de software a medida para Farm incluye un motor de comisiones por territorio, una lista de precios multidivisa para distribuidores transfronterizos, un transporte de intercambio sin conexión ofuscado para que los comerciales puedan pasar un informe de trato de un dispositivo a otro sobre el terreno sin pasar por el servidor, y un cliente de escritorio construido sobre Tauri para compartir la lógica de negocio con la base de código móvil. Está previsto un nivel de comerciales socios B2B con lista de clientes propia, gestión de equipos y SSO para distribuidores de tamaño medio de EE. UU. y la UE, con el subsistema de derechos de acceso ya estructurado para la asignación multipuesto. Los planes de infraestructura incluyen más automatización de cloud y DevOps del pipeline de despliegue regional, un banco interno de verificación continua del contrato de corrección de la sincronización sin conexión y una futura evaluación independiente de preparación integrada en la cadencia operativa.
Cree una app de ventas en campo como esta: hable con nosotros
Si está planificando una app móvil interna de ventas en campo, una herramienta AgTech offline-first o cualquier app móvil en la que los comerciales pasen horas sin cobertura y el ciclo de informes tenga que superar a un auditor externo ante públicos de EE. UU. y la UE, hemos entregado este stack de principio a fin y podemos acortar de forma notable el plazo de desarrollo. El producto en producción lo opera internamente el distribuidor, en yusmpgroup.ru/cases/farm (página del caso), y el equipo de ingeniería que lo respalda forma parte de YuSMP Group. Trabajamos a precio cerrado para MVP bien acotados y con equipos de desarrollo dedicados para la entrega continua, con jornada CET y una ventana garantizada de solapamiento con la costa este de EE. UU. (9:00–13:00 ET) para reuniones diarias, demos y respuesta a incidencias.
Preguntas frecuentes
¿Cuánto cuesta construir una app móvil interna de ventas en campo para distribuidores?
Una app móvil interna de ventas en campo con clientes para iOS y Android, un catálogo de productos con capacidad sin conexión, registro de tratos y un back office en Laravel o Node suele costar $80k–$180k para un MVP. Añadir paneles regionales de plan frente a real, permisos basados en roles, sincronización sin conexión libre de conflictos, recordatorios push e integraciones con un ERP existente o un stack contable al estilo 1C lleva un despliegue completo a $220k–$450k. El principal factor de coste es el trabajo de corrección de la sincronización sin conexión y la lógica de precios por región.
¿Por qué usar un desarrollo nativo para iOS y Android en lugar de un framework multiplataforma?
Los comerciales de ventas en campo de los territorios agrícolas trabajan durante horas sin conexión, en bodegas, almacenes y campos sin señal. Los clientes nativos en Swift y Kotlin nos permiten controlar el consumo de batería durante sesiones largas de sincronización, integrar con limpieza los almacenes SQLite nativos de la plataforma y entregar un comportamiento de teclado y accesibilidad propio de cada SO que React Native y Flutter siguen envolviendo con concesiones. Con una ventana operativa de tres años en mente, el coste de mantenimiento de dos bases de código nativas resultó menor que el coste acumulado de sortear las abstracciones multiplataforma.
¿Cómo se construye una verdadera app móvil de ventas offline-first?
Un enfoque offline-first defendible es una decisión de arquitectura, no un interruptor de función. El catálogo completo de productos, las tablas de precios y el listado de clientes se replican en un almacén SQLite local en el primer inicio de sesión y se actualizan de forma incremental en cada sincronización correcta. Los informes de tratos escritos sin conexión se ponen en cola con marcas de tiempo locales monótonas y se concilian en el servidor mediante claves de idempotencia, de modo que un comercial que cierra una venta en un sótano y reabre la app en un tren dos horas después nunca duplica ni pierde una transacción. La resolución de conflictos es determinista: el servidor prevalece en el precio y el cliente prevalece en las notas de campo.
¿Qué hace la app Farm por los gestores de ventas en campo del sector agrícola?
Farm es el conjunto de herramientas internas que un gestor regional de ventas lleva a una visita a una explotación. Ofrece un catálogo estructurado de fertilizantes, semillas, agentes químicos y equipamiento con los precios vigentes; permite al comercial registrar un informe de trato en segundos sobre un cliente ya conocido; hace el seguimiento del plan frente a lo real respecto a los objetivos de ventas trimestrales del comercial; y muestra un panel del lado del gestor que desglosa las cifras por categoría de producto y por región. Los recordatorios push avisan de los informes sin presentar, y un panel de administración en React gestiona las actualizaciones del catálogo, los cambios de precios y la asignación de cuotas.
¿Cuánto se tarda en lanzar una app interna de ventas en campo en iOS y Android?
Un MVP bien enfocado con clientes nativos para iOS y Android, un catálogo offline-first, registro de tratos y una administración en Laravel suele llevar 14–20 semanas. Añadir el panel regional del lado del gestor, la analítica de plan frente a real, permisos basados en roles para directores sénior y comerciales de campo y la capa de sincronización libre de conflictos suma 6–10 semanas. Reforzar la app para tres años de uso en producción sin supervisión —telemetría de fallos, fiabilidad de las notificaciones push, registros de reproducción de la sincronización— se subestima con frecuencia y conviene presupuestarlo en 4–6 semanas de trabajo dedicado.
Casos relacionados
Más desarrollos móviles y de herramientas internas
CheckList
App móvil de auditoría de campo para inspectores: formularios con capacidad sin conexión, captura de varias fotos y panel para el gestor.
Ver el caso →
SuperStep
App interna de formación y rendimiento para una cadena de retail: base de conocimiento, seguimiento del rendimiento y back office.
Ver el caso →
ZipIt
Marketplace B2B de autopiezas con CRM de proveedores, catálogo estructurado y flujo de pedidos en EE. UU. y la UE.
Ver el caso →Planifique un desarrollo similar
Reservar una llamada inicialPedir propuesta
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.