Every third inventory on the warehouse ends with discrepancies. Paper forms get lost, data is entered late, and serial numbers are forgotten. We develop mobile apps that replace manual labor: an employee scans a barcode, the system instantly reconciles with the records and fixes the result. Inventory time is reduced by up to 70%, and process transparency eliminates human error.
At its core is inventory — verification of actual availability against accounting data. But the traditional process becomes digital: the mobile app prompts what to scan and ensures no item is missed. Offline mode guarantees operation even without network, and integration with 1C automatically uploads reports to the accounting system. Our app enables warehouse automation through offline inventory tracking and barcode scanning.
What does a mobile inventory app deliver?
Built-in camera vs hardware scanner
The built-in camera is the most affordable solution. ML Kit Barcode Scanning (Android/iOS) via CameraX or AVFoundation decodes EAN-13, EAN-8, Code 128, Code 39, QR, and a dozen other formats. Works offline. Recognition latency on modern phones is 100–200 ms.
However, there are cases where the camera falls short: a warehouse with poor lighting, damaged labels, or the need to scan without lifting the item (long-range reading). Here Bluetooth scanners (Zebra CS60, Honeywell 1950g, Newland BS80) or industrial TSDs (Zebra TC21/TC26, Honeywell CT30) are required. They connect as HID keyboard or via the manufacturer's SDK.
| Parameter | Camera | Bluetooth scanner | Industrial TSD |
|---|---|---|---|
| Cost | Free (built-in) | Low | High |
| Scan speed | 100–200 ms | 50–100 ms | 30–50 ms |
| Range | 10–30 cm | up to 10 m | up to 15 m |
| Damaged label handling | Poor | Good | Excellent |
| Dust/water protection | No | Model-dependent | IP65+ |
In practice, the camera suits an office or store, while a TSD is for dirty warehouses. If the budget is limited, a Bluetooth scanner with a hand strap is the sweet spot: it is 2–3 times faster than the camera on worn barcodes.
Why offline-first architecture is critical for the warehouse?
The warehouse is an area with unstable Wi-Fi. Some zones have no coverage at all. The app must work completely offline: load the inventory list before starting, store scans locally, and sync when connectivity is restored. We use Room for the local database and WorkManager with the NetworkType.CONNECTED constraint.
// Room: entities for inventory plan and scan records @Entity(tableName = "inventory_items") data class InventoryItem( @PrimaryKey val sku: String, val name: String, val expectedQuantity: Int, val unit: String, val location: String, ) @Entity(tableName = "scan_records") data class ScanRecord( @PrimaryKey(autoGenerate = true) val id: Long = 0, val sku: String, val scannedQuantity: Int, val scannedAt: Long = System.currentTimeMillis(), val syncStatus: SyncStatus = SyncStatus.PENDING, val userId: String, ) enum class SyncStatus { PENDING, SYNCED, CONFLICT } On conflict (another employee scanned the same SKU), the server returns a conflict, and the app shows both values and asks to resolve manually.
How to implement serial number tracking?
Not every item has a readable barcode. Manual SKU input with autocomplete from the local database is a must. The SKU list is downloaded in advance into an FTS4/FTS5 Room table for fast full-text search by name.
Serial numbers are a separate story. An item may require scanning each unit individually (laptops, printers, tools). Serial number tracking mode: the app waits for N serial number scans for one item, showing progress 3/10 serial numbers entered.
How are discrepancy reports generated and integrated with 1C?
After inventory completion—a discrepancy report: which items were not found, which are surplus, where actual did not match plan. Generated locally, sent to the server, or exported to PDF via PdfDocument API (Android) / PDFKit (iOS).
Integration with 1C via REST API (1C HTTP service) or an intermediary service. Data exchange format is JSON or XML, as agreed with the 1C developer. Uploading the inventory document back to 1C is a standard final step.
A recent case from our practice
For a logistics warehouse with 15,000 SKUs, we deployed an iOS app with Bluetooth scanners and offline-first architecture. Previously, a full inventory took 15 staff two full days. After migration, the same work is done by 5 staff in 4 hours — a 70% reduction in labor time. Discrepancy rate dropped from 3% to 0.2%, virtually eliminating write-offs from undocumented losses. This resulted in annual labor cost savings of approximately $50,000. Typical project cost ranges from $15,000 to $40,000 depending on complexity.
What is included in the work?
| Component | Description |
|---|---|
| Process audit | Study of current inventory scheme, item types, warehouse working conditions |
| Design | Technology stack (iOS/Android/Flutter/React Native — cross-platform options), architecture (offline-first), scanner type selection |
| Development | Implementation of scanner, local storage, synchronization, reporting |
| Integration | Connection to 1C or other ERP, exchange setup |
| Testing | Verification on real devices, including TSDs |
| Deployment | Publication to App Store and Google Play, configuration of TestFlight/Firebase Distribution |
| Documentation | User manuals and technical documentation |
| Access rights | Setup of user roles and permissions |
| Training | Staff training on the app, handover of documentation and access rights |
| Support | Post-launch support and bug fixes |
Moreover, the app can turn any smartphone into a data collection terminal, making it a turnkey inventory solution.
Timeline: basic version with camera and offline — 5–7 weeks. With TSD, serial tracking, and 1C — 10–14 weeks. Pricing is determined after analyzing your project.
Development approach in 5 steps
- Audit processes — understand current workflow and pain points.
- Design architecture — choose tech stack and offline-first pattern.
- Develop core features — scanning, offline storage, sync.
- Integrate with ERP — connect to 1C or other systems.
- Test and deploy — test on real devices and publish to app stores.
Common development mistakes
- Ignoring offline mode — the app hangs when network is lost.
- Lack of scanner abstraction — replacing the camera with a TSD requires code rewriting.
- Sync conflicts without a resolution mechanism — data can diverge.
- No fallback for damaged barcodes — using only the camera without a manual input option.
Our team has 5+ years of mobile development experience and has delivered over 30 projects for warehouse logistics. We guarantee stable app performance in conditions of poor connectivity and harsh environments.
Contact us for a consultation — we will evaluate your project and propose the optimal solution.







