Digitizing construction-site management across three roles
A mobile + web platform for India’s unorganized construction sector. I was designing and owning research, information architecture, the design system, UI, and prototyping. It was tested on real client sites in Himachal and Jodhpur before the company wound down.
Problem
Site management runs on paper and memory.
India’s unorganized construction sector has no single source of truth, so problems stay invisible until they’re expensive:
- Labour attendance is unreliable and often disputed.
- Inventory arrives with no tracking or verification.
- Worker payments are handled ad hoc.
- The project manager, who needs visibility most, has the least.
Most construction software is built for the office and handed to the field. CSITE is built for the field first: the supervisor on the slab at 2pm, one glove off, checking a phone.
Architecture
Each role sees only what it’s accountable for.
Three roles share one data model, but feature ownership follows how accountability works on a site. Quality control sits with the engineer, who answers for it. Attendance and labour sit with the supervisor, who manages them daily. The project manager sits on top. Information and accountability flow the same direction:
labour → supervisor → engineer → project manager.
Complexity is placed where it can be handled. The supervisor’s home is four cards; the project manager’s is a full dashboard.
Bottlenecks
Bottlenecks are tied to the engineer accountable for them.
The founders and I wanted the project manager to see specific bottlenecks, not vague status. We worked backwards from why projects fail and landed on three signals: delayed tasks, delayed deliveries, and failed quality checks. The engineer is accountable for these, so each engineer’s record carries their QC pass rate with delays mapped to their name.
A failure metric can backfire if people hide failures to protect it.
So this isn’t a ranking or a shared scoreboard. It’s a sortable list inside the project manager’s view only. It works as a diagnostic for the PM, not a number engineers compete on.
Triage
Delays are sorted by severity so the PM knows what to fix first.
Each delayed task and delivery is tagged High, Medium, or Low by days delayed, with the day count on every card, so a project manager can scan it in seconds on a phone.
I kept severity day-based because it was simple and shippable.
The limit I’m aware of: a short delay on a critical task can matter more than a long delay on one with slack. Weighting severity by task criticality was the planned next step, to build with engineering once there was real data.
The hardest user
The supervisor’s most frequent actions use the camera, not the keyboard.
Supervisors often have low text literacy but are numerate and fluent with their phones.
So their most frequent action, marking attendance, skips typing entirely: it is done by face recognition, which takes reading and writing out of a daily task.
A few smaller choices support this: light backgrounds and high-contrast black buttons for outdoor glare; numbers instead of prose where possible (“60 Nos”, “Present: 25 / Absent: 03”); and confirmation before financial actions like settling a payment.
Validation
Tested on real sites, with honest limits.
I worked remotely while the founders ran CSITE on client sites in Himachal and Jodhpur, observed crews using it, and brought feedback back for me to iterate on.
The clearest signal: supervisors marked attendance and logged quality checks without training.
This is founder-observed use, not first-hand or instrumented data. That’s what I’d instrument next, since real completion data would say more than any heuristic.
Reflection
Designing for the field changed what “good” meant.
Almost every time I removed something (a field, a step, a label), it worked better for the supervisor than adding “useful” information did. Designing for glare, gloves, and low literacy made restraint the default.
The company later wound down, after my tenure ended. Startups fail for reasons a contributor can’t control; and that’s a mature take, I would say, in this constantly evolving ecosystem.
CSITE is my clearest proof that I can take an ambiguous, real-world domain and design a whole system for it, alone.
Work Digitizing construction-site management across three roles
A mobile + web platform for India’s unorganized construction sector. I was designing and owning research, information architecture, the design system, UI, and prototyping. It was tested on real client sites in Himachal and Jodhpur before the company wound down.
Problem
Site management runs on paper and memory.
India’s unorganized construction sector has no single source of truth, so problems stay invisible until they’re expensive:
- Labour attendance is unreliable and often disputed.
- Inventory arrives with no tracking or verification.
- Worker payments are handled ad hoc.
- The project manager, who needs visibility most, has the least.
Most construction software is built for the office and handed to the field. CSITE is built for the field first: the supervisor on the slab at 2pm, one glove off, checking a phone.
Architecture
Each role sees only what it’s accountable for.
Three roles share one data model, but feature ownership follows how accountability works on a site. Quality control sits with the engineer, who answers for it. Attendance and labour sit with the supervisor, who manages them daily. The project manager sits on top. Information and accountability flow the same direction:
labour → supervisor → engineer → project manager.
Complexity is placed where it can be handled. The supervisor’s home is four cards; the project manager’s is a full dashboard.
Bottlenecks
Bottlenecks are tied to the engineer accountable for them.
The founders and I wanted the project manager to see specific bottlenecks, not vague status. We worked backwards from why projects fail and landed on three signals: delayed tasks, delayed deliveries, and failed quality checks. The engineer is accountable for these, so each engineer’s record carries their QC pass rate with delays mapped to their name.
A failure metric can backfire if people hide failures to protect it.
So this isn’t a ranking or a shared scoreboard. It’s a sortable list inside the project manager’s view only. It works as a diagnostic for the PM, not a number engineers compete on.
Triage
Delays are sorted by severity so the PM knows what to fix first.
Each delayed task and delivery is tagged High, Medium, or Low by days delayed, with the day count on every card, so a project manager can scan it in seconds on a phone.
I kept severity day-based because it was simple and shippable.
The limit I’m aware of: a short delay on a critical task can matter more than a long delay on one with slack. Weighting severity by task criticality was the planned next step, to build with engineering once there was real data.
The hardest user
The supervisor’s most frequent actions use the camera, not the keyboard.
Supervisors often have low text literacy but are numerate and fluent with their phones.
So their most frequent action, marking attendance, skips typing entirely: it is done by face recognition, which takes reading and writing out of a daily task.
A few smaller choices support this: light backgrounds and high-contrast black buttons for outdoor glare; numbers instead of prose where possible (“60 Nos”, “Present: 25 / Absent: 03”); and confirmation before financial actions like settling a payment.
Validation
Tested on real sites, with honest limits.
I worked remotely while the founders ran CSITE on client sites in Himachal and Jodhpur, observed crews using it, and brought feedback back for me to iterate on.
The clearest signal: supervisors marked attendance and logged quality checks without training.
This is founder-observed use, not first-hand or instrumented data. That’s what I’d instrument next, since real completion data would say more than any heuristic.
Reflection
Designing for the field changed what “good” meant.
Almost every time I removed something (a field, a step, a label), it worked better for the supervisor than adding “useful” information did. Designing for glare, gloves, and low literacy made restraint the default.
The company later wound down, after my tenure ended. Startups fail for reasons a contributor can’t control; and that’s a mature take, I would say, in this constantly evolving ecosystem.
CSITE is my clearest proof that I can take an ambiguous, real-world domain and design a whole system for it, alone.
