System thinking

How I connect data, AI, and product.

Software that survives daily operations is rarely one layer. It is a chain of decisions — what enters the system, how it is validated, where it lives, and how a human actually uses it under pressure.

Data systems

Government data has to become desk-ready.

When I built the trademark register inside NepalIPMS, the raw source was not a clean API. It was Department of Industry bulletins, legacy spreadsheets, and partial exports that firms had accumulated over years. The system’s job was not to mirror government files — it was to make 130,000+ records searchable while a paralegal is on the phone.

I think about data as a pipeline with explicit gates: import, validate, persist, index, expose. Each gate exists because real desks fail at handoffs. A row that slips through validation becomes a renewal missed. A search index built on unnormalized marks returns false confidence. Notifications only matter if the underlying record is trustworthy.

Government DataDoI bulletins, register exports, firm-maintained sheets
ImportBatch ingestion with provenance — know which source each row came from
ValidationSchema checks, duplicate detection, canonical application numbers
DatabaseD1 with migrations — the register is a living model, not a dump
SearchFTS5 indexes tuned for mixed Nepali/English mark queries
User WorkflowMatter records, deadlines, client portfolios — data in context
NotificationsRenewal clocks and status changes that reach the right desk

AI systems

Intelligence belongs in the loop, not in the way.

Document intelligence in legal practice is not about replacing judgment. It is about removing the repetitive translation between a government PDF and a matter record. OCR demos make this look solved. Production taught me otherwise: bulletin layouts shift, bilingual text breaks tokenizers, and confidence scores mean nothing unless a practitioner can correct them quickly.

My AI systems always end at the same place — search and reminders tied to verified records. Click each stage for technology, reason, and tradeoff.

Upload

Technology
Reason
Tradeoff

Full interactive OCR architecture →

Product systems

Architecture follows the problem, not the stack.

Product thinking, for me, starts before technology. What breaks on Monday morning? What does the firm do when a client calls about a mark they filed three years ago? Those questions shape workflow design long before I choose Workers, D1, or a frontend framework.

Deployment and iteration close the loop. Shipping on Cloudflare’s edge is a product decision — low latency for Kathmandu teams, operational simplicity, infrastructure that does not require a dedicated DevOps hire. Iteration means watching production queries, sitting with practitioners after launch, and adjusting the model when the desk tells you the abstraction was wrong.

Across ScholarQuest, Global Law Associates, TopRank, and Yogshala, the pattern repeats: understand the domain, design the workflow, architect for reliability, deploy, learn. The stack changes; the sequence does not.

User ProblemFriction on the real desk — not feature requests from a slide deck
Workflow DesignPaths practitioners repeat daily, error recovery included
Technical ArchitectureDomain model, API surface, storage, observability
DeploymentEdge-native production — fast, reachable, maintainable
IterationProduction signals, desk feedback, measured refinements

See architecture diagrams →