Compass Healthcare Digital
Stopped a separate rounding module before build.
Sites rounded in two different ways. I remapped rounding into the follow-up record they already used. Engineering scoped one system instead of two.
Patient Rounding
About Anup
I work upstream,
before the screens exist.
I work on the boundary between what a system can do on its own and what still needs human judgment.
What I do.
I frame product direction, map operational workflows, define permissions and decision boundaries, and build working software to test those decisions.
ServiceNow
Brought five systems onto one shared partner request.
The shared record made ownership and stage visible across five systems. Local data stayed with the system that owned it.
Partner Operations
The stack changes. The loop doesn't: frame it, build enough to test it, then prove what changed.
01
Design
Figma · Framer
02
Build
Built this site and the working review gate in Lumens in code.Claude Code · Cursor · TypeScript · Next.js · Tailwind · shadcn/ui
03
AI + agents
Bo, the model-backed guide on this site, and the Lumens build.Claude API · OpenAI API · MCP
04
Evaluate
Every release of this site runs scripted copy, privacy, layout and Bo-answer checks before it goes live.Behavioral checks · browser verification · regression checks · citation checks
05
Ship
Vercel · Playwright · Linear
Off the clock
Elsewhere, usually.
Off the clock, I'm usually somewhere between a long drive,
I notice buildings,
Questions worth asking.
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.
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.
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.
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.
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.
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.