Process
Updated
How I build products.
Not a services menu. Not a résumé. A walk through the way I turn real friction into systems people can rely on on a Monday morning.
- What
- Iconic scroll process story
- Who
- Founders & builders evaluating fit
- Why
- Method before feature lists
Start with tension
Find the workflow that already hurts.
I do not start with a feature list. I start where someone is already compensating — spreadsheets, memory, inboxes, and side channels.
If nobody is struggling yet, there is nothing to ship.
With NepalIPMS, the tension was renewals living in memory and files split across drives. Digitization alone would have produced a prettier spreadsheet. The real job was redesigning the desk.
Sit with the desk
Watch how work actually moves.
Who decides. Who operates. What “done” looks like when a client is on the phone. Which errors are embarrassing vs career-threatening.
Non-technical operators will not read your architecture diagram. They will open the same screen a hundred times. Design for that repetition.
Model before pixels
Shape the system to the work.
Generic CRM shapes force practitioners to reorganize around the software. I prefer the reverse: mirror the domain, then build the screens.
Specialize when the desk is specialized.
Architecture is the product’s skeleton — data boundaries, failure recovery, and what must never be written silently.
Intelligence with brakes
Add AI only where it removes real work.
Extraction without understanding fails desks. Chat without a system of record is entertainment. I stage pipelines: store → OCR → classify → extract → human review → merge.
Confidence beside every field. No silent writes into matters.
Change your mind in public
The lesson that reshaped search.
I originally believed fuzzy matching would improve trademark search. It did — until it quietly introduced ambiguity in production. Lawyers stopped trusting results during client calls. That mistake completely changed how I think about search systems.
Trust beats cleverness when someone is on the phone.
Exact-first. Normalize hard. Expand later. Latency and false conflicts matter more than demo “smartness.”
Ship for Monday
Release into real load — then tighten.
Edge-native stacks a small team can operate. Migrations in desk slices, not diagram elegance. Watch production use. Cut what nobody touches. Document the why so the next decision is cheaper.
- Research — sit with friction
- Understand — operators and risk
- Design — the path they will repeat
- Architect — data, boundaries, recovery
- Build — APIs, persistence, safety
- Integrate AI — only with review
- Deploy — edge-native, observable
- Iterate — evidence over instinct
The person
What I reach for when stuck.
- ToolsTypeScript, Next.js, Cloudflare Workers / D1 / R2, a notebook before Figma
- Principle I changedFuzzy-first search → exact-first trust (see above)
- Failed attemptBroad similarity on 130K marks — impressive demos, unusable desks
- TeachingExplaining computer science to students forces clarity I reuse in product copy
- PlaceKathmandu — building for organizations that need software to hold under real load