About Anup

I work upstream, before the screens exist.

Product designer and builder across healthcare operations, enterprise platforms, and AI agents. My focus is who owns the next step and what happens when the plan changes.

Working software is how I test those decisions, put workflows under pressure, and revise what fails.

The tools I reach for.

The stack changes. The loop doesn't: frame it, build enough to test it, then prove what changed.

  1. Frame it

    Most of the design work that matters happens before any pixel exists. The brief is the deliverable.

    Figma, Framer, Linear

  2. Build enough to test it

    Built this site and the working review gate in Lumens in code. Bo, the guide on this site, answers from a real model.

    Claude Code, Cursor, TypeScript, Next.js, Tailwind, shadcn/ui, Claude API, OpenAI API, MCP

  3. Prove what changed

    Every release of this site runs scripted checks, before it ships and again once it is live.

    Release gateruns on every deploy

    Before it ships. A failure stops the release.

    • Copy. No em dashes in rendered copycheck:copy
    • Privacy. Copy screened for personal and client disclosurescheck:privacy
    • Weight. Key pages stay under their script budgetscheck:bundle
    • Frames. Frame times held to the last releasegate:frames

    Once it is live. A failure calls for a rollback.

    • Public build. Retired pages stay off the domaincheck:leaks
    • Bo. Answers come from the modelcheck:bo

    Playwright, Vercel

Off the clock

Elsewhere, usually.

Off the clock, I'm usually somewhere between a long drive, a camera, a kitchen, and an animal I've stopped to watch for too long.

I notice buildings, old signs, odd interfaces, and the way people improvise around systems. I photograph places that feel lived in, and take the scenic route even when it's objectively inefficient. Dogs generally improve the plan.

Questions worth asking.

01What changes when you join a product team?

I make the decisions hiding upstream visible: what we are actually solving, what the system should own, where judgment belongs, and which assumptions are carrying the roadmap. Then I build working software so those calls get tested instead of debated.

02What shape of problem do you solve best?

Consequential systems where the cost of being wrong is high. Healthcare workflows, regulated operations, agent supervision, and enterprise products where permissions, exceptions, handoffs, and judgment determine whether the system actually works.

03How is designing for AI different from traditional software?

AI products introduce probabilistic behavior where software once relied on explicit rules and states. I design the boundary: what the system may do, what requires approval, what evidence it exposes, and how a person can inspect, correct, or take control.

04Where do you draw the line between design and engineering?

I build working systems when the question is interaction, state, workflow, or judgment. I partner with engineers when the hard problem becomes architecture, security, scale, or production reliability. The boundary follows the problem, not my job title.

05How do you decide what an agent should do on its own?

Start with consequence, reversibility, and accountability. Let the system act where mistakes are recoverable, ask where judgment matters, and hand control back before it crosses a boundary it should not own.

06Why isn't Bo more autonomous?

Because autonomy has to be earned. Bo's job is to help you understand the work, find the evidence, and ask a better question. He does not need to act on your behalf to do that. I give a system the smallest useful autonomy and widen it when the workflow proves it needs more.

Email me