Product philosophy

Software that disappears into the work.

Useful software that becomes part of someone’s daily workflow — combining engineering, design, and business understanding.

Most of the web is designed to be looked at. A portfolio piece, a campaign landing page, a brochure with buttons. That work has its place, but it is not the work I am drawn to. I am drawn to the moment someone opens the same screen on Monday morning, Thursday afternoon, and the day before a statutory deadline — because their job depends on what happens there.

That distinction changes everything about how you design. A marketing site optimizes for first impression. Operational software optimizes for the hundredth session: fewer clicks on repeated paths, predictable recovery when something goes wrong, language that matches how practitioners already talk about their files. The interface should feel like an extension of the desk, not a separate product someone has to “use.”

I learned this building legal technology in Nepal. IP firms do not need another dashboard. They need renewal clocks that never slip, matter records that mirror how partners already organize companies and assets, and search across 130,000 trademark entries that returns in milliseconds because a paralegal is on the phone with a client. When software earns that place in a workflow, people stop calling it “the system.” They just call it how they work.

That is why I start with friction, not features. I sit with the real desk — the spreadsheets, the shared drives, the inbox threads, the government bulletins someone re-types by hand. Features come later, shaped by what actually breaks. Architecture follows the shape of the domain: company, file, matter, asset — not generic CRM abstractions that force firms to reorganize around the software.

Reliability is part of the product experience. A missed renewal date is not a bug report; it is a client relationship at risk. So I treat migrations, observability, and edge deployment as design decisions, not backend chores. Shipping on Cloudflare Workers, D1, and R2 is not trend-chasing — it is choosing infrastructure that stays fast and reachable for teams who cannot afford downtime during filing season.

Applied AI belongs in the same frame. Document intelligence and retrieval are valuable when they remove genuine repetition — bulletin intake, register lookup, drafting scaffolding — without asking experts to trust a black box over their own judgment. The best AI features feel like acceleration, not automation for its own sake. They should make a skilled person faster at the work only they can do.

What I am optimizing for is not launch day applause. It is the quiet signal that the product has become infrastructure: fewer panicked calls, fewer duplicate files, fewer hours lost to work that software should carry. Users remember the outcome — the renewal filed on time, the student matched to the right program, the case file found in seconds — not the interface chrome.

If that is the kind of problem you are trying to solve — domain-shaped, operationally serious, worth maintaining for years — that is where I do my best work.

← Back to portfolio