Lo que hoy le costaba a QualityChecker
- · 3 a 5 días entre la inspección y el certificado. El inspector iba al campo con carpeta, formularios en papel y cámara aparte, volvía a la oficina, tipeaba todo en un Excel y armaba el certificado en Word. El cliente esperaba días algo que podía resolverse en horas.
- · Certificados sin verificación, riesgo de fraude. Un papel firmado sin QR ni código validable se puede falsificar. Las empresas que compran tanques usados o contratan inspecciones a terceros no tenían forma de confirmar la autenticidad.
- · Inspectores aislados en zonas sin señal. Las inspecciones ocurrían en fincas, plantas industriales, zonas rurales. Sin internet, no había forma de consultar el historial del tanque ni validar contra la base central. Todo se decidía en el momento, sin contexto.
Lo que cambió con la app
- · Certificado en el momento, en la casa del cliente. Lo que tardaba 3–5 días ahora sale en minutos. La inspección se cierra con el PDF firmado y el QR ya generado, antes de que el inspector se vaya de la visita.
- · QR público de verificación, antifraude de entrada. Cualquier persona con el QR puede escanear y ver datos del tanque, fecha, inspector y empresa. La duda sobre la legitimidad del papel desapareció.
- · Sync offline sin pérdida de datos. El inspector trabaja toda la jornada sin señal. Al volver a zona con internet, la app sincroniza fotos, formulario y resultados automáticamente. Cero pérdida, cero retrabajo.
La sincronización offline no era un feature — era el proyecto entero
Si el inspector llenaba un formulario y se perdía al sincronizar, todo el sistema se quebraba. La confianza del inspector en la app depende de que sus datos estén siempre, sin importar la señal. Diseñamos el flujo así:
- 1 UUID generado en el dispositivo. Cada inspección tiene una identidad propia desde el momento en que se crea en la app, antes de tocar el servidor.
- 2 Fotos encoladas y subidas en segundo plano. Se almacenan con su UUID en el dispositivo y se sincronizan cuando hay conexión, sin bloquear al inspector.
- 3 Merge por UUID, no por ID autoincremental. Si la misma inspección se carga dos veces por un retry de red, el backend la reconoce y no la duplica.
- 4 Feedback claro al inspector. "Sincronizado", "pendiente", "error de subida". Nunca queda en duda qué pasó con su trabajo.
┌─────────────────┐
│ App Flutter │ ◄── Genera UUID local, captura fotos, sync offline
│ (Android) │
└────────┬────────┘
│ REST + JSON
│ (sync cuando hay internet)
▼
┌─────────────────┐
│ Django REST │ ◄── Auth, merge por UUID, generación PDF, QR
│ Framework │
└────────┬────────┘
│
▼
┌─────────────────┐ ┌──────────────────┐
│ PostgreSQL │ ◄──┤ Dashboard web │ (oficina, supervisores)
│ │ │ + reportes email │
└─────────────────┘ └──────────────────┘ Lo que nos llevamos como aprendizaje
- 01
Offline-first no es "guardar y subir después" — es una arquitectura
Si lo tratás como un detalle al final, perdés datos. Hay que diseñarlo desde el primer wireframe, no después del MVP funcional.
- 02
El QR no es un feature estético, es el corazón de la confianza
En industrias con riesgo físico (gas, electricidad, alimentos), la verificación por código único es lo que sostiene la confianza del cliente final. Sin eso, la app era un "PDF con wifi".
- 03
El feedback de campo es ruidoso: instrumentá bien
Los inspectores no te van a decir "se cayó la app". Te van a decir "no anda" o "perdí un reporte". Invertí tiempo en logs y tracking (Sentry) para reconstruir qué pasó cuando un inspector vuelve a la base con un problema.
Pasamos de esperar días a entregar el certificado en la inspección. Y la tranquilidad de que cada certificado es verificable cambió la relación con nuestros clientes — ya nadie nos pregunta si el papel es real.
Testimonial parafraseado.
¿Tenés un proceso de campo que sigue en papel?
Conversamos 20 minutos sobre tu operación, vemos el alcance, la arquitectura offline-first y el plan de trabajo. Sin compromiso.