GEMA FactoryMobile app
A maintenance app for a palm oil mill
A Flutter app that replaces paper work orders in a palm oil mill: scan a machine's QR code, report an issue with readings and photos, assign mechanics, and track the job to completion.
- Role
- Software engineer and product lead (Flutter): architecture, UI system and features
- Period
- 2026 – Present
- Team
- The GEMA team I lead (2–4 developers) and implementators, plus the client mill staff
- Status
- In active development
- 11work order types, from repair to calibration
- 4roles with their own permissions
- 3status levels per reading: Normal, Warning, Critical
Still in development, so there are no usage numbers yet.
Context
The problem
A mill runs dozens to hundreds of machines. Breakdown reports came in late or went missing, machine history wasn't recorded, inspection readings weren't documented, and supervisors couldn't see progress in the field. Paper work orders were easy to lose, and assigning mechanics was slow.
Solution
What we built
Technicians scan the QR code on a machine to open its details and work order history, then report an issue with actual readings, photos and notes. Each reading is checked against its threshold. Supervisors turn issues into work orders, assign a mechanic per item, and follow the status from open to completed.
- Flutter
- Dart
- Provider
- Dio
- Freezed
- dartz
- mobile_scanner
- REST API
Scope
What's in it
Features
- QR scanner with scan line, torch and haptic feedback
- Issue reports with readings, a photo per reading and up to 5 general photos
- Preventive maintenance, approvals and workshop activities
- Work orders across 11 types, status from Open to TECO to Completed
- A mechanic per work order item, with a searchable picker
- Daily inspection checklists with parameters from the API
- Dashboard with active work orders, pending issues and completed jobs
Roles
- Technician: scan, report issues, daily tasks
- Supervisor: approve, assign mechanics, monitor
- Manager: supervisor rights with wider access
- Management: dashboard and reports
Decisions
Decisions and trade-offs
Feature-based clean architecture
Each feature has its own UI, state and data source. Provider for state (MVVM-lite), repositories returning Either<Failure, T>, and immutable Freezed models.
Thresholds come from the server
Each parameter has a min, normal and max value from the API, so the app flags readings without hard-coding any machine.
Upload photos first, then submit
Images go to their own endpoint before the issue is posted, so a slow upload never leaves a half-saved report.
One screen for adding and editing
The same form handles both, keeps new photos apart from ones already on the server, and won't submit if nothing changed.
My role
What I owned
- Set up the feature-based architecture, state management and data layer.
- Built a reusable component system (buttons, fields, cards, media picker, submit bar).
- Built the QR scanner, issue reporting, work orders and inspections.
- Integrated the REST API with auth handling.
- Designed the product brochure and presentation material.
Artefacts
Have a process that should be a system?
I'm not looking for a new role, but I'm always up for a conversation about a system, a process or a collaboration.