Case study 02
Field operations platform
Narrowing a broad security-operations ERP into a local-first trip-to-report pilot with an explicit path to managed cloud authority.
Security operations connect people, sites, shifts, attendance evidence, travel, payroll, invoices, and compliance-sensitive records. The hard part is deciding which events are authoritative and which product surface is allowed to change them.
The mobile source contained local SQLite, Supabase, and Spring REST paths. Rather than imply that every path was equally ready, I froze the current release around one testable workflow: capture a daily journey, preserve route evidence, review it, and generate a printable conveyance report without requiring cloud access.
Each choice connects a business constraint to an implementation boundary and retained evidence.
Made SQLite authoritative for trips, route points, stops, destinations, and local reports. Remote configuration is control-only: it cannot upload active-trip data or turn on cloud sync, payments, authentication, or hidden ERP modules.
Evidence · Accepted ADR 0001 records the authority boundary, alternatives considered, failure defaults, verification tests, and rollback path.Limited the pilot shell to Daily Trips, My Profile, and Settings, with cloud sync, desktop sync, payments, and mandatory authentication disabled. The release does not claim attendance, payroll, or the wider ERP as pilot-ready.
Evidence · The Feedback Build Decision Log and Trip-to-Report E2E Plan define the exact build flags, exclusions, eight acceptance gates, and real-device test matrix.Kept trip capture usable offline, required an explicit foreground tracking notification, preserved active-trip recovery after app restart, and documented force-stop, permission, battery-policy, map, and uninstall limits instead of treating GPS collection as infallible evidence.
Evidence · Current Implementation and the pilot E2E plan tie background tracking, plausibility filtering, persistence, route review, PDF generation, and recovery to explicit acceptance conditions.Used a weighted decision matrix to proceed with the local feedback pilot and release governance, design—but not launch—the managed tracker, and reject a near-term full-ERP SaaS release while authority, tenant isolation, idempotency, compliance, and module UAT remained unresolved.
Evidence · The recorded decision matrix scored the local pilot and governance paths at 119, while the full-ERP launch scored 50 and was marked do not proceed.The accepted pilot architecture now has one named data authority, a deliberately small visible surface, capability-narrowing remote controls, an explicit rollback path, and a documented definition of end-to-end success from trip start through report recovery after restart.
Internal release candidate 1.0.8+12 passed Flutter analysis, focused remote-config, legal-policy, and local-storage tests, and release AAB packaging. Real-device remote-config and location-workflow verification remained pending, so external pilot and Play production approval were not claimed.
Evidence basis
AI disclosure. Implementation was developed extensively through AI-directed workflows across Spring Boot, Flutter, tests, configuration, and release documentation. Exact line-level authorship and an AI-generated percentage were not independently audited. I owned product scope, system architecture, delivery priorities, review and correction of generated changes, hands-on defect diagnosis and fixes, validation interpretation, and release gates.