ElectroUchet

Inspiration

I am the chief power engineer for a property management company in a small town in Moldova. Electricity readings are still often collected with paper notes, phone photos, and fragile spreadsheets. Field employees work in basements and utility rooms where connectivity is unreliable, while the office later has to reconcile those readings with utility registers.

What it does

ElectroUchet connects the complete field-to-office workflow. Administrators manage employees and assignments. Field employees see only their assigned meters, capture readings and synthetic evidence photos, and continue working offline. IndexedDB keeps a durable local queue; synchronization resumes automatically when the internal network returns.

Stable client and device identifiers make delivery idempotent, so retries cannot create duplicate readings. The office imports management-company and utility reports in real-world XLS/XLSX layouts, preserves source rows, matches meters by serial number, highlights discrepancies, tracks tasks, and exports a monthly Excel reconciliation.

The field workflow also includes meter identity barcode decoding and calibrated display recognition as optional entry aids. Uncertain recognition is never treated as truth: the employee remains the final reviewer.

How we built it

• React 19 and TypeScript for the administrator interface and responsive field PWA
• IndexedDB and a service worker for offline-first operation
• FastAPI, Pydantic, SQLAlchemy, SQLite, and Alembic for the local API and storage
• openpyxl and xlrd for source-faithful XLS/XLSX imports and exports
• a Flutter Android field client with offline synchronization and on-device recognition scaffolding
• Docker Compose and an Nginx same-origin gateway for the isolated judge demo
• automated backend, authorization, import, synchronization, barcode, and OCR tests

How Codex and GPT-5.6 helped

This was a solo Build Week project. Codex powered by GPT-5.6 acted as my implementation partner: auditing the initial visual prototype, translating field requirements into role boundaries, implementing the FastAPI backend and durable offline queue, reasoning through retry failures, building the image and spreadsheet workflows, writing regression tests, and packaging a synthetic Docker demo.

GPT-5.6 was especially useful for reasoning about ambiguous meter recognition, data privacy, idempotency, and failure recovery. I supplied the domain knowledge, made the product decisions, reviewed the implementation, and verified the complete workflow.

Challenges

The hardest problem was safe offline retry. A connection can disappear after the server accepts a reading but before the device receives the response. ElectroUchet combines stable record and device IDs with a server uniqueness constraint, so the retry returns the existing record rather than creating another one.

The second challenge was privacy. Real operational data must remain inside the organization. The public repository and judge environment therefore use a separate ephemeral database containing only fictional addresses, meters, reports, and photographs.

Accomplishments

• A working offline-to-online workflow rather than a disconnected mockup
• Server-enforced assignments and separate administrator/field authentication
• Photo-capable durable queueing with automatic idempotent retry
• Real-world legacy XLS and XLSX import structures
• Barcode identity recognition and conservative display-reading assistance
• Automated tests and a reproducible one-command synthetic demo
• English and Russian documentation for deployment and judging

What we learned

Offline-first is not a cache toggle. A dependable workflow needs stable client identity, explicit queue state, retry-safe server semantics, authorization during synchronization, and recovery for attachments. AI agents work best when paired with strong domain constraints and human verification.

What's next

• Calibrate recognition on a larger, consented field-photo dataset
• Complete Android field trials and refine the Flutter experience
• Add route ordering and workload estimates
• Expand audit history and operational reporting

Testing

Run docker compose -f compose.demo.yml up --build, then follow the judge workflow in the repository README. All included demo data is synthetic.

Built With

• docker-compose
• fastapi
• flutter
• gpt-5.6
• indexeddb
• nginx
• openai-codex
• python
• react-19
• sqlite
• typescript