built with Claude Code
INTERNAL TOOL (VIBECODING) · SWIGGY INSTAMART · 2026
INTERNAL TOOL (VIBECODING) · SWIGGY INSTAMART · 2026
A field research instrument built overnight for POD visits
A field research instrument built overnight for POD visits
When my manager asked for an observation tool the evening before a field visit, I designed the use cases, defined the user flow, and built a production-ready PWA with Claude Code, all in one session.
When my manager asked for an observation tool the evening before a field visit, I designed the use cases, defined the user flow, and built a production-ready PWA with Claude Code, all in one session.
When my manager asked for an observation tool the evening before a field visit, I designed the use cases, defined the user flow, and built a production-ready PWA with Claude Code, all in one session.
MY ROLE
Product Designer
TEAM
Solo
DURATION
May 2026
BUILT WITH
Claude Code · React · Local
THE BRIEF
THE BRIEF
A WhatsApp message at noon
MANAGER • WHATSAPP • JUNE 2
"Hey, can you prepare an observation checklist for our field visit tomorrow? Walk the putaway SOP step by step, write whether each step is being followed, bypassed or altered. If there's a discrepancy, ask why. Also some tool for capturing TMS, field notes, photos?"
MANAGER • WHATSAPP • JUNE 2
"Hey, can you prepare an observation checklist for our field visit tomorrow? Walk the putaway SOP step by step, write whether each step is being followed, bypassed or altered. If there's a discrepancy, ask why. Also some tool for capturing TMS, field notes, photos?"
The visit was at 7am the next morning. I had one evening. Before touching any code, I went through the same process I would for any design problem: define the use cases, define the user, define the flow.
The visit was at 7am the next morning. I had one evening. Before touching any code, I went through the same process I would for any design problem: define the use cases, define the user, define the flow.
The visit was at 7am the next morning. I had one evening. Before touching any code, I went through the same process I would for any design problem: define the use cases, define the user, define the flow.
GETTING STARTED
Defining a Persona
These themes emerged consistently across interviews and data:
These themes emerged consistently across interviews and data:
01
Speed vs. compliance tension. Under order surge, pickers defaulted to fastest paths — not SOP-compliant ones. The SOP hadn't been designed with peak-hour cognitive load in mind.
PHASE 1: DEFINE
Defining the use cases & sketching the concepts
I started by mapping every scenario the tool needed to handle. Defining actual things a researcher would need to do, standing in a POD, holding a device in one hand.
I have done 3 POD visits before this one, so I recaptured my points from those visits. Secondly, I asked my team members to share their pain points.
I started by mapping every scenario the tool needed to handle. Defining actual things a researcher would need to do, standing in a POD, holding a device in one hand.
I have done 3 POD visits before this one, so I recaptured my points from those visits. Secondly, I asked my team members to share their pain points.
I started by mapping every scenario the tool needed to handle. Defining actual things a researcher would need to do, standing in a POD, holding a device in one hand.
I have done 3 POD visits before this one, so I recaptured my points from those visits. Secondly, I asked my team members to share their pain points.
PHASE 2: BUILD
The conversation that made it
Once the use cases were clear, I opened Claude Code and briefed it the same way I'd brief a developer, precisely, with constraints. Here's how the key moments of that build session actually went.
Once the use cases were clear, I opened Claude Code and briefed it the same way I'd brief a developer, precisely, with constraints. Here's how the key moments of that build session actually went.
Once the use cases were clear, I opened Claude Code and briefed it the same way I'd brief a developer, precisely, with constraints. Here's how the key moments of that build session actually went.
claude-code · pod-observation-tool · June 2
me
me
Once the use cases were clear, I opened Claude Code and briefed it the same way I'd brief a developer, precisely, with constraints. Here's how the key moments of that build session actually went.
Once the use cases were clear, I opened Claude Code and briefed it the same way I'd brief a developer, precisely, with constraints. Here's how the key moments of that build session actually went.
Once the use cases were clear, I opened Claude Code and briefed it the same way I'd brief a developer, precisely, with constraints. Here's how the key moments of that build session actually went.
claude
claude
Building this as a single offline HTML file, download once, open in Safari, runs fully on-device. localStorage for persistence. Three-state status per step with reason field that only opens on deviation. Timer holds multiple readings with optional labels. Photos compress on capture so they don't hit storage limits. Field notes panel with timestamps. PDF export via Safari's print dialog. Starting with the data model...
Building this as a single offline HTML file, download once, open in Safari, runs fully on-device. localStorage for persistence. Three-state status per step with reason field that only opens on deviation. Timer holds multiple readings with optional labels. Photos compress on capture so they don't hit storage limits. Field notes panel with timestamps. PDF export via Safari's print dialog. Starting with the data model...
Building this as a single offline HTML file, download once, open in Safari, runs fully on-device. localStorage for persistence. Three-state status per step with reason field that only opens on deviation. Timer holds multiple readings with optional labels. Photos compress on capture so they don't hit storage limits. Field notes panel with timestamps. PDF export via Safari's print dialog. Starting with the data model...
me
me
I can't see capture buttons for photos or video. Also, can we store all assets from a visit in Google Drive?
I can't see capture buttons for photos or video. Also, can we store all assets from a visit in Google Drive?
I can't see capture buttons for photos or video. Also, can we store all assets from a visit in Google Drive?
claude
claude
The capture buttons were hidden inside a section that only opened after marking a step, fixing that, they'll always be visible. On Google Drive: auto-uploading would need a live connection at the moment of capture, which defeats the offline goal. Better solution: store everything on-device during the visit, then one-tap download of a .zip bundle, photos, videos, audio clips, CSV, summary, at the end. Upload that one file to Drive when you're back on wifi.
The capture buttons were hidden inside a section that only opened after marking a step, fixing that, they'll always be visible. On Google Drive: auto-uploading would need a live connection at the moment of capture, which defeats the offline goal. Better solution: store everything on-device during the visit, then one-tap download of a .zip bundle, photos, videos, audio clips, CSV, summary, at the end. Upload that one file to Drive when you're back on wifi.
The capture buttons were hidden inside a section that only opened after marking a step, fixing that, they'll always be visible. On Google Drive: auto-uploading would need a live connection at the moment of capture, which defeats the offline goal. Better solution: store everything on-device during the visit, then one-tap download of a .zip bundle, photos, videos, audio clips, CSV, summary, at the end. Upload that one file to Drive when you're back on wifi.
me
me
Mic is working. A few edits: audio transcription (English or Hinglish)? Camera in field notes section? Ability to add/delete steps? Filter chips at top for Inwarding / Putaway / Both, but shouldn't affect the PDF export.
Mic is working. A few edits: audio transcription (English or Hinglish)? Camera in field notes section? Ability to add/delete steps? Filter chips at top for Inwarding / Putaway / Both, but shouldn't affect the PDF export.
Mic is working. A few edits: audio transcription (English or Hinglish)? Camera in field notes section? Ability to add/delete steps? Filter chips at top for Inwarding / Putaway / Both, but shouldn't affect the PDF export.
claude
claude
On transcription: in-field isn't realistic offline. Adding live dictation instead — tap mic, speak, text lands in the note field, EN/HI toggle for Hinglish. Needs signal, so it's clearly labelled and audio recording stays the reliable fallback. All four other edits are in: camera in field notes, add/delete steps with auto-renumbering, filter chips at top-left as proper pill components with live counts, PDF always includes everything regardless of active filter.
On transcription: in-field isn't realistic offline. Adding live dictation instead — tap mic, speak, text lands in the note field, EN/HI toggle for Hinglish. Needs signal, so it's clearly labelled and audio recording stays the reliable fallback. All four other edits are in: camera in field notes, add/delete steps with auto-renumbering, filter chips at top-left as proper pill components with live counts, PDF always includes everything regardless of active filter.
On transcription: in-field isn't realistic offline. Adding live dictation instead — tap mic, speak, text lands in the note field, EN/HI toggle for Hinglish. Needs signal, so it's clearly labelled and audio recording stays the reliable fallback. All four other edits are in: camera in field notes, add/delete steps with auto-renumbering, filter chips at top-left as proper pill components with live counts, PDF always includes everything regardless of active filter.
me
me
The current UI is cognitively very heavy. The followed/altered/bypassed buttons look exactly like the capture buttons, completely different purposes. Take inspiration from Apple HIG, Notion, Slack. Build a really solid and bug-free v2.0.
The current UI is cognitively very heavy. The followed/altered/bypassed buttons look exactly like the capture buttons, completely different purposes. Take inspiration from Apple HIG, Notion, Slack. Build a really solid and bug-free v2.0.
The current UI is cognitively very heavy. The followed/altered/bypassed buttons look exactly like the capture buttons, completely different purposes. Take inspiration from Apple HIG, Notion, Slack. Build a really solid and bug-free v2.0.
claude
claude
Running a full design audit first before rebuilding. The core problem: status and capture use identical visual weight, violating the law of similarity. Fix: status becomes one iOS-style segmented control — the single dominant element per card. Capture drops to a quiet, recessed icon row beneath it. Progressive disclosure hides timer and note until tapped. Also adding a fourth state (N/A), fixing the edit-text height bug, re-enabling pinch-zoom for accessibility, and a CSV data sheet with one row per step for aggregating across visits. Building v2 now...
Running a full design audit first before rebuilding. The core problem: status and capture use identical visual weight, violating the law of similarity. Fix: status becomes one iOS-style segmented control — the single dominant element per card. Capture drops to a quiet, recessed icon row beneath it. Progressive disclosure hides timer and note until tapped. Also adding a fourth state (N/A), fixing the edit-text height bug, re-enabling pinch-zoom for accessibility, and a CSV data sheet with one row per step for aggregating across visits. Building v2 now...
Running a full design audit first before rebuilding. The core problem: status and capture use identical visual weight, violating the law of similarity. Fix: status becomes one iOS-style segmented control — the single dominant element per card. Capture drops to a quiet, recessed icon row beneath it. Progressive disclosure hides timer and note until tapped. Also adding a fourth state (N/A), fixing the edit-text height bug, re-enabling pinch-zoom for accessibility, and a CSV data sheet with one row per step for aggregating across visits. Building v2 now...
THE TOOL
What we actually shipped
POD Field Observation (live)
POD Field Observation (live)
Built to work fully offline inside low-signal PODs. Hosted on GitHub Pages. Used on the Sushant Lok and Sector 67 visits.
Built to work fully offline inside low-signal PODs. Hosted on GitHub Pages. Used on the Sushant Lok and Sector 67 visits.
4
Adherence states
Followed, Altered, Bypassed, N/A: as a single iOS-style segmented control. The dominant, primary action per step. Reason field only opens on a deviation.
∞
TMS readings per step
Start/stop timer per step, holds multiple readings with optional labels. Actual time compared against SOP expected time in Review.
3
Built-in SOPs
Inwarding, Putaway, Order Fulfillment pre-loaded. Paste any custom SOP and the tool auto-parses it into editable steps with one click.
1-tap
Visit bundle export
One .zip with every photo, video, audio clip, a CSV data sheet (one row per step, built for aggregating across visits), and a printable summary.
EN/HI
Live dictation
Speak to fill note fields. English or Hindi toggle for Hinglish. Requires signal. Audio recording is the reliable offline fallback.
0
Signal required on the floor
PWA with service worker caching. Load once on wifi, runs fully offline inside any POD. Data stays on-device until you download the bundle.
4
Adherence states
Followed, Altered, Bypassed, N/A: as a single iOS-style segmented control. The dominant, primary action per step. Reason field only opens on a deviation.
∞
TMS readings per step
Start/stop timer per step, holds multiple readings with optional labels. Actual time compared against SOP expected time in Review.
3
Built-in SOPs
Inwarding, Putaway, Order Fulfillment pre-loaded. Paste any custom SOP and the tool auto-parses it into editable steps with one click.
1-tap
Visit bundle export
One .zip with every photo, video, audio clip, a CSV data sheet (one row per step, built for aggregating across visits), and a printable summary.
EN/HI
Live dictation
Speak to fill note fields. English or Hindi toggle for Hinglish. Requires signal. Audio recording is the reliable offline fallback.
0
Signal required on the floor
PWA with service worker caching. Load once on wifi, runs fully offline inside any POD. Data stays on-device until you download the bundle.
OUTCOME