Inside the Build: Bringing Real-Time Visibility to Construction Site Operations

The problem: growth capped by a physical visit

GharBanegaEasy runs construction projects across multiple sites in India. Like most small and mid-sized construction businesses, the way the owner knew whether a site was on track was to go there. Attendance, inventory levels, work progress, payment status — none of it was visible remotely. If the owner wasn't standing on the site, the owner didn't really know what was happening on it.

That's not a minor inconvenience. It's a hard ceiling on how many projects a business can run at once. Every additional site adds another physical visit to the owner's week, and there's a limit to how many sites one person can drive to, walk, and inspect before the whole operation starts to strain. GharBanegaEasy was running around 5 projects in parallel — not because demand was capped, but because oversight was.

Layered on top of the visibility gap were two more problems. Manual attendance and inventory tracking left room for errors and leakages that were genuinely hard to trace after the fact — was that bag of cement actually used on-site, or did someone log it and it went missing? And the four different people who needed to understand a site's status — the engineer running it, the supervisor overseeing it, the owner funding it, and the client waiting on it — each needed a different slice of the same information, not the same report forwarded four times.

There wasn't an off-the-shelf tool built around this. Generic project-management software assumes a different kind of user and a different kind of site. So we built a custom platform from the ground up around how GharBanegaEasy's sites actually run.

Three problems, one root cause

Before writing any code, the challenges broke down into three distinct things that all traced back to the same root cause — no real-time visibility without a physical presence:

No remote visibility. The owner's only reliable source of truth was standing on the site. Everything else — phone calls, WhatsApp updates, verbal reports from supervisors — was secondhand and unverifiable.

Leakage-prone processes. Manual attendance sheets and inventory logs are trust-based by design. They work fine at small scale when the owner can spot-check everything. They stop working once there are more sites than the owner can personally audit, and that's exactly when the errors and losses start compounding.

Multi-role coordination. A site incharge/engineer, a supervisor, the owner, and the client all needed live information about the same site, but none of them needed the same view of it. Coordinating that over phone calls and WhatsApp groups meant information degraded with every retelling.

“”

The architecture decision: proof-first, not trust-first

The core design decision was to make every meaningful action on-site produce evidence at the moment it happens, rather than a report filed later. That single principle shaped almost everything downstream.

Attendance is photo-based and live-capture only. Workers are marked present through a photo taken in the app at the time of marking — not a manual check-in someone can log for a worker who isn't actually there. This closes the most common leakage point in manual attendance tracking directly.

Inventory has a request-approval-usage chain. Material requests, deliveries, and usage are all tracked with approvals built in, so there's a record of what was ordered, what arrived, and what was actually consumed — not just a running tally someone updates from memory.

Progress is daily, multi-angle, and photo-logged. Instead of a supervisor's written update, the app captures progress photos from multiple angles every day, building a visual timeline of the site that the owner and client can both see without visiting.

Vendor ordering runs through WhatsApp automation. Since WhatsApp was already how these businesses communicate with vendors, we automated ordering through it rather than forcing vendors onto a new interface they'd resist adopting.

Payments carry their own audit trail. Payment requests, reminders, and invoices are handled in-app through Razorpay, so payment status is one more thing the owner can see without a phone call.

Coordinating five different interfaces — the Site Incharge/Engineer Mobile App, Supervisor Mobile App, Owner Mobile App, Client Mobile App, and Admin Web Dashboard — around this proof-first data model was the real engineering challenge. Each app needed to be genuinely built for its user rather than a shared shell with different permissions bolted on. We go deeper on how that role-based architecture was structured in a follow-up piece on multi-role mobile apps for field teams. On the infrastructure side, the platform runs on React Native across the mobile apps, Node.js on the backend, SQL and MongoDB for structured and document data respectively, and AWS underneath all of it — a stack chosen for reliability at the scale the business was aiming for, not just the scale it started at. If you're weighing similar stack decisions for a field-operations product, our mobile app development team can walk through the trade-offs specific to your use case.

What changed once the site visit was no longer required

The result wasn't just "the owner can see more now." It removed the actual constraint on the business. Once oversight didn't require physical presence at a site, the owner could run more sites in parallel without a proportional increase in personal time spent driving between them.

GharBanegaEasy scaled from 5 to 30 concurrent projects — a 6x jump in how much the business could run at once, using the same ownership structure that used to cap it at 5. That's not a vanity metric. It's the direct, measurable result of removing a bottleneck that had nothing to do with demand and everything to do with visibility infrastructure that didn't exist yet.

The platform has since become the foundation for something bigger than GharBanegaEasy's own operations. The same visibility problem — construction business owners capped by how many sites they can personally oversee — exists across the industry. DevOrbital and GharBanegaEasy are now productizing the platform as a SaaS for other construction businesses, with DevOrbital continuing as the technology partner on that build. You can read the complete breakdown of the problem, approach, and outcomes in the Construction Operations Platform case study.

What this build says about custom software for operational bottlenecks

The lesson that generalizes beyond construction: when a business's growth is capped by something that looks like "the owner needs to be everywhere," the fix usually isn't more staff or more hours. It's replacing physical presence with verified information. That's a software problem, and it's one where off-the-shelf tools frequently miss because they're built for a different operating model than the one your business actually runs on.

If your team is hitting a similar ceiling — growth capped by an owner or manager who has to physically be somewhere to know what's happening there — that's usually a sign the right fix is a purpose-built system, not a bigger team.