Selected work

Shown as decisions, not screenshots.

The decision is the part that transfers to your situation. The implementation rarely does. Client names are withheld where appropriate; the reasoning is not.

01 / Healthcare technology

Realtime AI healthcare assistant

The problem

Hold a natural realtime conversation with a patient while keeping clinical workflow boundaries intact.

The decision

Separate the conversational model from the structured clinical handoff, and keep the handoff deterministic.

Capability
Realtime voice AIOrchestrationStructured outputsSafety boundaries
02 / AI engineering

AI engineering orchestra

The problem

AI-assisted development becomes inconsistent as soon as agents operate without governance.

The decision

Impose a controlled architecture, implementation, review and remediation cycle rather than trusting a single pass.

Capability
AI engineeringSoftware architectureDelivery governance
03 / Distributed systems

Multi-tenant logistics platform

The problem

Support realtime operational tracking without compromising tenant isolation or transactional performance.

The decision

Split high-frequency telemetry away from the core transactional workload instead of scaling both together.

Capability
Distributed systemsRealtime infrastructureMulti-tenant architecture

The pattern

The presenting request is often bigger than the decision that solves it.

Across AI systems, operational platforms and product engineering, a repeated part of the work is separating what must be deterministic from what can be probabilistic; what needs custom engineering from what can be bought; and what should be built now from what should wait.

That is why the site shows decisions instead of a wall of screenshots. The judgment is the transferable asset.

Your turn

Tell us the decision. We'll tell you what we'd check.