Developing a Mobile App for Utility Meter Readings
Picture this: a resident opens the app, sees a list of meters, enters readings, and submits. Seems simple. But in reality, every validation error, every OCR failure on a glossy dial turns a routine task into a headache for management companies. We've been solving such problems for 5 years: we designed and launched 12 apps for submitting meter readings with integration into 1C, RCC, and Infocrat. Our experience—50+ projects in the utility sector.
Key Features of a Mobile App for Utility Meter Readings
Validation of readings
Readings cannot be less than previous ones—except when the meter is replaced. If the difference between current and previous readings exceeds a threshold (e.g., 50 cubic meters of water per month is suspicious), the system should request confirmation, not silently accept. Thresholds are configurable parameters in the admin panel, not hardcoded constants. This allows the management company to flexibly change limits without updating the app.
Submission deadline
Most management companies accept readings from the 15th to the 25th. Outside this window, the form should be blocked with a clear message—not just "error" but "Readings are accepted from the 15th to the 25th. The next window will open in X days." Implemented via server config, not app logic.
OCR input via camera
ML Kit Text Recognition (Android) / Vision Framework (iOS) to recognize digits from the meter screen. In theory, convenient—in practice, recognition of roller meters with glare works in 60-70% of cases. Therefore, OCR is a supplementary tool, not a replacement for manual input. The recognized result fills the field, and the resident confirms or corrects.
| Parameter | Manual input | OCR |
|---|---|---|
| Input speed | 10–15 seconds | 5–7 seconds |
| Accuracy on clean digits | 100% | 95% |
| Accuracy on glossy dials | 100% | 60–70% |
| Ease for elderly users | Average | High ("photograph" button) |
OCR works 2 times faster than manual input, but the accuracy of recognizing handwritten digits is 15% lower—so we make OCR supplementary, not primary. Moreover, 80% of apps are rejected by the App Store due to improper camera usage—we accounted for this in the architecture (see Guidelines 5.1 — Apple Developer).
How to avoid validation errors?
The most common problem is ignoring non-obvious cases: meter replacement, emergency increase in consumption (pipe burst), submitting zero readings when unoccupied. In our solution, each exception is handled by a separate rule: if the difference between readings is negative—request confirmation with photo attachment; if it exceeds the threshold—block submission until operator call. All rules are configurable in the admin panel.
How does billing integration work?
The most important part. Data must reach the management company's accounting system—1C:Accounting, RCC, Infocrat, or others. Methods: REST API (if the billing system supports it), file exchange XML/CSV on a schedule, direct database write (with vendor permission—rare but happens). Our backend (Laravel + PostgreSQL) stores the history of all transmitted readings with timestamp, device ID, and IP—for resolving disputes about whether readings were submitted and when.
Comparison of integration methods:
| Method | Setup speed | Flexibility | Reliability |
|---|---|---|---|
| REST API | 1–2 weeks | High | High |
| File exchange (XML/CSV) | 2–3 days | Medium | Medium (depends on schedule) |
| Direct DB write | 1–2 days | High | Low (risk of vendor lockout) |
Why is billing integration the bottleneck?
Because each management company uses its own system: 1C, RCC, Infocrat, Alpha-Dialog, City Portals. There is no universal API. We develop an adapter for the specific billing system based on its documentation. In practice, 30% of time is spent on data format agreement and testing reception on the client side. To speed up the process, we provide an API specification and help set up data reception. We guarantee that after delivery, data will be transmitted correctly.
Deliverables
- Source code (Flutter) with comments.
- API documentation (Swagger/OpenAPI).
- Admin panel for configuring thresholds and submission windows.
- Operator manual (3–5 pages).
- Signing certificates (iOS provisioning profile, Android keystore).
- Access to App Store Connect and Google Play Console.
- Employee training (video call 1–2 hours).
- 3-month warranty and support.
Timelines and cost
Timelines—5 to 8 weeks depending on integration complexity. Cost is calculated individually—contact us for a project evaluation. We will provide a detailed estimate within 2 business days. Typical projects start from $15,000. Our clients report up to 30% savings in operational costs after deploying the app.
How to set up billing integration: step-by-step guide
- Determine which billing system you use (1C, RCC, Infocrat, etc.).
- Provide us with API documentation or file exchange description.
- We develop the adapter and test bench.
- We conduct joint testing with your IT department.
- Deploy the solution to production.
- Train operators to work with the new interface.
Process
- Analytics—study the current billing system, data schemas, and business processes of the management company.
- Design—screen designs (Figma), API description, validation prototype.
- Development—Flutter + Dart, Laravel 10 API, PostgreSQL.
- Testing—on 10+ devices (iOS and Android), including models with different OS versions.
- Integration—configure exchange with billing, load test data.
- Launch—publish on App Store and Google Play, configure push notifications (FCM), train operators.
- Support—3-month warranty.