Construction Tech · Web + Mobile
From paper logs to real-time financial visibility
Onsite had a mobile app for site supervisors - but nothing for the owner deciding where the money was going. I designed and built the missing half: a desktop platform from zero, plus a redesign of the existing app.
100K+
Construction businesses reached
₹5,000Cr+
Worth of projects on the platform
$1.7M
Funding raised
My Role
Lead Product Designer - solo on the desktop platform, end to end
I owned UX and visual design for the entire desktop build, working directly with the founders with no PM layer in between. I designed four modules from zero - Dashboard, BOQ & Billing, Company Profile, Estimation Builder - redesigned the existing mobile app, and built the design system a second designer later extended into mobile.
Industry
Construction ERP
Platforms
Web + iOS + Android
Timeline
~4 months, solo
Team
Me + founders + eng
System architecture - how Company, Project, and each module relate, with BOQ reading from Material, Attendance and Tasks.
The Business Problem
Supervisors had visibility into the site. Owners had none into the business.
Zero desktop experience. Every financial decision an owner made relied on someone verbally relaying site information.
A manual bridge, not a system. Owners hired a dedicated person to sit between the supervisor and the accountant, turning paper site-logs into Excel by hand.
Billing and progress were disconnected. Nothing tied “work completed” to “amount owed” - every bill was a manual reconciliation exercise.
No cross-project visibility. An owner running five sites held five separate mental models, with no company-level view.
How might we give owners the same real-time visibility into their business that supervisors already had into the site?
Process
No research team. Direct access to the people who ran construction businesses.
There was no budget for formal studies. The substitute was tight, continuous access to the domain experts - founders who had run construction businesses themselves. Every module was shaped in working sessions with them, not a discovery phase handed off in a deck.
Construction workflows don’t map onto existing SaaS patterns: progress isn’t binary, billing isn’t per-unit, labour isn’t salaried. Almost every module went through multiple structural passes before converging.
Early dashboard explorations - multiple structural directions before locking one.
Flow logic mapped for Material and Payment tracking.
One artifact shaped BOQ more than any wireframe: an actual Running Account (R/A) bill - the progress-billing format Indian contractors already use, tracking previous, current, and total quantity per line item. I wasn’t inventing a billing schema. I was digitizing a format the industry already trusted.
A real R/A bill — an existing industry document, not something I designed. The reference that shaped BOQ’s data model.
The Decision That Shaped the Product
How do you show accurate billing without drowning the owner in rows?
BOQ isn’t billed in finished units — it’s billed in partial, uneven progress. Every item needed previous, current, and total quantity, and any item could span multiple locations at different stages. There was no honest way to compress that into a single number. Tracking per-location wasn’t optional; the R/A format demanded it. The real problem: laid out as table rows, the screen becomes unreadable past a handful of items.
Version 1 — Fully expanded
Every task, every location, its own row, headers repeated per group. Accurate - but the more accurate the data got, the harder the screen was to read.
Version 2 — Tightened columns
Cleaner alignment, a running total at the bottom. Still every location visible at once, whether the owner needed it or not.
Version 3 — Progressive disclosure (shipped)
Each task collapses to one row: one progress bar, one amount. Location-level detail - the R/A-accurate part - only appears when a task is expanded. The data stays as granular as the format demands, without forcing an owner to read every location on every visit.
The deciding factor: who reads this screen daily. An owner wants a task’s one-line status; a supervisor updating progress needs the location breakdown. Collapsing by default and disclosing on demand let one screen serve both.
The Rest of the System
Twelve modules, one consistent language
Dashboard
Every project got its own - attendance, material, labour cost, transactions, and project health in one screen. Replaced “call the supervisor, call the accountant” with a glance.
Attendance
Supervisors log hours, allowances, and shift type. Because labour is paid daily, the same log gave workers visibility into their own earnings - cutting day-to-day payment disputes.
Material Log
Digitized the paper register supervisors kept for material received and used on site.
Transactions
A single ledger for money in and out across every party on a project. UPI and online payments were scoped for a later phase.
Company Profile · my idea
A public profile - like a freelancer’s on Upwork - where a construction company showcases past work and shares it with prospective clients. One of four ground-up modules.
Estimations
Build quotations, track lead → accepted. Clients comment directly on line items - negotiation in context, with full version history.
Also shipped: Tasks & document attachments, a per-project Photos library, downloadable Reports per module, a company-level Parties & Library, Access & Roles, and cross-project Company Analytics.
Impact
Adoption followed the modules that removed the most manual work
30%+
Growth in BOQ feature usage post-redesign
60%+
Growth in estimation generation
4.5★
Current Google Play rating
Founders reported a meaningful drop in manual invoice work - adjusting, tracking, and reconciling payments against progress, which BOQ now handled directly instead of as a separate step.
“Our finance team now uses the web app daily without needing support.”
“I can finally see what’s happening across projects without calling my site supervisors.”
- Founder feedback, relayed during rollout
Context, not personal credit - Onsite today markets 2× field-office communication, 25% faster delivery, and 10% cost savings, at 10,000+ companies. That’s the full-product value prop years and several team iterations later — not a metric to claim directly, but evidence the direction this phase set held.
Reflection
Working without a research team meant founders’ domain knowledge did the work interviews usually would - enough to move fast, though I’d still want real supervisor and owner interviews if I revisited this today, especially for BOQ. What I’m most confident about is the progress-per-location decision: the slower, more expensive version to build, and the one that didn’t break the first time a project got messy. The product kept evolving - GPS attendance, multi-level approvals, an AI layer - and those sit on top of the same core structure rather than replacing it. That’s the best evidence the foundation held.
