CallSentry
Answers the phone, handles the conversation, books the appointment, and gives the operator a record of every call.
Open systemClient work · Demo instances
Running systems, not slide decks.
These are running systems, not design exercises. Some were built for client production environments; others are independent systems I built and operate myself. Demo instances use sanitized or synthetic data where required. What you open here is a demo instance of that work: the same code, with client data replaced by sanitized sample data. Use it, and judge the work by how it behaves.
Selected systems
Pick one and open it.
Every card opens a live demo instance of a client system. Names, records, and content are sanitized. The workflows, roles, and failure handling are exactly what the client runs.
Foundry
Design, order, and client operations for a jewellery studio, held in one system of record instead of spreadsheets and inboxes.
Open systemVideo Automation Service
A topic or script goes in. A finished, rendered MP4 comes out. AI plans the edit; a deterministic pipeline executes it.
Open systemMX Sentinel
Shows mail operators why delivery is failing by correlating SMTP telemetry, DNS changes, DMARC data, and reputation signals, before the incident becomes a support queue.
Open systemSeoulFM
A live, listener-driven K-pop station. Song requests, synced lyrics, and dedications for an audience around the world, playing around the clock.
Open systemHow to review this work
Open → Use → Try to break it → Ask
A working system should survive a sceptical visitor. Treat these the way your staff would.
01
Open it
Every link goes to a running demo instance, not a recording or a slide. Same code the client runs, with sample data.
02
Use it
Click through a real workflow end to end. Where sign-in is required, credentials are issued on request.
03
Try to break it
Take the awkward path: bad input, a refresh mid-task, a second tab. Watch how it handles the failure.
04
Ask about it
Every design decision has a reason. I will walk you through any of them, including the trade-offs.
What you see here is what the client received: a system that is deployed, monitored, and owned. The demo differs from production only in its data.
What these have in common
The same rules, applied every time.
The domains differ. The engineering does not. These are the constraints each system was built under.
01Deterministic core, probabilistic edge. AI assists judgment; it does not hold the state.
02Business state lives in a proper database, not in a prompt or a chat history.
03Humans approve consequential decisions. The system makes them easy to approve well.
04Failures are visible and recoverable. Retries, queues, and audit trails are not afterthoughts.
05Sign-in, roles, and logging from the first release, because clients hand these to staff.
06Boring where boring is safer. New tools earn their place by solving a real problem.
Access
Some doors are locked on purpose.
In production, several of these systems hold client and operational records. The demo instances carry sanitized data but keep the same sign-in, role-based access, and session logging, because that is the standard I ship with. Ask and I will issue review credentials.
Request review accessOpenCallSentry · Self-hosted AI voice receptionist
Sign-inFoundry · Studio operations platform
Sign-inVideo Automation Service · AI video production engine
OpenMX Sentinel · Email infrastructure observability
OpenSeoulFM · Live community radio