This is the first post in a new series. The last one, the Build series, was about how I built the software for three telehealth practices with no computer science background. This one is about the part that comes after building: actually running the practice day to day. The tools, the workflows, the boring-but-hard operational problems nobody warns you about when you decide to be both the doctor and the person who keeps the website up. I'll start with a small one that saves me a disproportionate amount of grief: the robot that checks my site before I do.
Its name is Khai, spelled חי, the Hebrew word for "living." Its two letters, khet and yud, are worth eight and ten in gematria, so they add up to eighteen, which is why eighteen is the number that means life. I named it that on purpose. It's an AI lifecycle agent, and its job is to keep the things I build alive and working: to bring the projects to life and then keep them there. It's a piece of software I built to be the first set of eyes on the site after anything changes, so that by the time I look, I'm looking at a site that's already had its obvious bugs found. It is, in the most literal sense, a robot that logs in as a patient and clicks around to make sure the practice still works.
The problem it solves
Here's the situation every solo operator who ships their own software lives in. You make a change. Maybe you wrote it, maybe an AI agent wrote it, maybe it's a dependency update you barely understand. It builds, it deploys, the site comes back up, and it looks fine on the one page you happen to check. And somewhere three clicks deep, behind a login, on a device you didn't test, a link is broken or a form won't submit or the checkout throws an error, and you have no idea, because you are one person and you did not click every path.
In a company, this is what QA is for. There's a person, or a team, whose whole job is to go find the broken thing before a customer does. I don't have that person. For a long time the QA team was me, clicking around after each change, and the problem with me as the QA team is that I'm the same person who just made the change, I'm tired, I'm biased toward believing my own work is fine, and I have a practice to run. So the patient becomes the QA team by default. The patient finds the broken link. That's the failure mode I built Khai to kill.
I built it to be the first pass. Not the last pass, not a replacement for my judgment, just the first sweep that catches the dumb, mechanical, expensive-if-missed stuff before I spend my limited attention on anything.
What it actually does
Khai logs into the site the way a patient does, with real credentials, and then it behaves like an extremely thorough, extremely patient visitor who has all day and clicks everything.
It crawls the site, following links, and flags the ones that are broken: the 404s, the dead buttons, the pages that error out. Broken links are the single most common thing it catches, because they're the easiest thing to introduce without noticing. A slug changes, a page moves, a redirect gets missed, and suddenly there's a link to nowhere that you'd only find by clicking it.
It goes through the flows that actually matter, the ones where a failure costs you a patient or a payment: the login itself, the intake, the checkout. These are the paths where a silent break is most expensive, because a patient who hits a broken checkout doesn't email you to complain. They just leave.
It takes screenshots of what it sees, including the authenticated pages I'd otherwise have to log in and navigate to myself, so I can look at the actual rendered state instead of imagining it. It can run a security and configuration audit. It can check the site against accessibility standards. And it does all of this on demand, when I ask it to, which is both its original design and, as I'll get to, its main limitation.
The point of all of it is the same: move the discovery of a broken thing from "a patient finds it in production" to "a robot finds it before I've even reviewed."
What's actually under the hood
For anyone who wants the technical picture, here's what Khai is under the surface. It's a local service running on my own machine, driving a real browser through Puppeteer, which is what lets it log in and behave like an actual visitor instead of just pinging URLs from the outside.
The core crawler walks the site to a configurable depth, and on every page it reaches it checks the things that quietly break: HTTP status codes, load times, images that failed to load, JavaScript errors in the console, failed network requests, missing alt text and other accessibility problems, and whether forms carry the request-forgery protection they should. It screenshots each page at desktop, tablet, and mobile sizes, because plenty of bugs only appear at one width.
On top of the crawl sits a fourteen-category audit that goes well past "is the page there." It checks security headers and cookie flags, tests CORS with a hostile origin, tries to reach protected pages and APIs without logging in, probes for exposed files that should never be public, hammers endpoints to see whether rate limiting kicks in, inspects the SSL certificate, and reviews the SEO and performance basics. Given login credentials it goes further: it crawls the authenticated areas, and, the check I care about most, it logs in as one kind of user and tries to reach another kind's pages to confirm it gets turned away.
Then there's the more aggressive stuff, the tests I reach for when I want to actively try to break something before a patient does. Visual regression that compares screenshots pixel by pixel against a known-good baseline and highlights exactly what moved. Flow tests that run a whole multi-step journey like eligibility or checkout and assert on each step. Fuzzing that throws hundreds of malformed and malicious inputs at both API endpoints and page forms, watching for a crash or a payload that reflects back unescaped. Core Web Vitals measurement for the metrics Google actually ranks on. A dedicated broken-link crawler. And a scheduler that can run any of this on a timer and flag a regression the moment a run comes back worse than the one before it.
It is, in other words, a great deal more than a link checker. Most days I don't use all of it. But the range is the point, because a first-pass tester earns its keep exactly when it catches the thing you didn't think to look for.
Where it sits in the loop
The way this actually works is a loop, and I'm not the one running most of it. Something changes. Khai sweeps and produces a report of what's broken. Then Claude, the AI agent I build with, reads that report, makes the fixes, and reruns Khai. That cycle repeats on its own, Khai finds, Claude fixes, Khai re-checks, around and around, until the sweep comes back clean: zero broken links, zero dead buttons, zero errors behind the login. Only then do I look.
That changes what I spend my attention on more than any single feature does. The old way of reviewing a change was to open the site and start hunting, clicking around trying to notice whether anything broke, which is slow and unreliable and exactly the kind of task humans are worst at. The new way, I don't hunt and I don't even triage. By the time the site reaches me, one robot has found every mechanical problem and another has fixed them, and the two of them have gone around enough times that there's nothing mechanical left to find. I'm reviewing a site that's already been tested and already repaired.
So what's left for me is the only part that actually needs me: judgment. Not "is this link broken," which the loop has already settled, but "is this flow confusing, does this copy say the right thing, is this the experience I want a patient to have." The mechanical layer gets handled by the Khai-and-Claude loop running until it hits zero. The human layer, the taste and the clinical sense and the is-this-actually-right, is the part I keep. Driving the errors to zero before I look is exactly what frees me to spend my attention on the questions a machine can't answer.
The honest limitation
Here's the thing I have to be honest about, because this whole series is field notes and not a sales pitch: a tool you have to remember to run is a tool you will eventually forget to run.
Khai has a scheduler built into it. It can run on a timer, on its own, without me, and for a long time I never turned that on. That's the most honest thing I can tell you about running your own tools: building a capability and actually switching it on are two different projects, and I had only finished the first. So in practice Khai stayed a tool I invoked by hand. And the trouble with on-demand QA is that the moments you most need it, right after a big messy change when you're tired and behind, are exactly the moments you're least likely to remember to run it. A tester that depends on my discipline inherits my worst days. In practice that means the tool is genuinely useful when I use it and does nothing on the days I don't, and the days I don't are the days a bug is most likely to slip through. That's not a flaw in the robot. It's a flaw in wiring a robot to a human's memory.
Turning it on daily
Which is why the next step, the one I'm setting up now, is to take my memory out of it and let Khai run on its own.
The plan is straightforward: a scheduled daily run against all three sites, every day, whether or not I remember. Real checks pointed at the actual practices instead of the placeholder I first tested the feature against. And the results routed to where I'll actually see them, the same morning report and dashboard I use to know whether the practice is up, so a broken link shows up next to everything else I check by habit rather than sitting in a tool I have to think to open.
The shift is small to describe and large in effect: from a tester I invoke to a monitor that watches. The capability doesn't change; Khai already knows how to log in and sweep. What changes is that it stops depending on me to start it. The first-pass tester becomes a standing first line, running before I've had coffee, so the answer to "did anything break overnight" is already waiting instead of being something I have to go find out.
I'm having it set up properly rather than hacking a timer onto it, because anything that runs on my machine on a schedule and holds the keys to my sites is exactly the kind of thing you set up carefully or not at all. But the direction is set: the robot that checks the site before I do is about to start doing it every day, without being asked.
Why this matters for a solo practice
The general lesson, the one that outlasts this particular tool, is that the first reviewer of anything, and increasingly the first fixer too, should be a robot, so that the human spends judgment and not attention on mechanics.
A solo practice runs on one person's attention, and attention is the thing you run out of first. Every minute I spend clicking around looking for a broken link is a minute I'm not spending on a patient, on the actual medicine, on the decisions that need me specifically. A robot that does the mechanical first pass isn't a luxury for an operation my size. It's part of what lets an operation my size exist at all, because it converts a category of work that would eat my attention into a report I can skim in a minute. Build the tester that catches the dumb stuff, and then, the part I'm doing now, make it run on its own so it catches the dumb stuff even on the days you'd have forgotten to look.
And because the whole point of this series is that solo operators shouldn't have to keep building the same things alone, I'm putting Khai on GitHub. If you run your own site and want a robot that logs in and sweeps it before your patients do, you can take this one and point it at yours: https://github.com/thebensoffer/khai-website-tester.
Next time
The next post is about the other half of knowing your practice works: not "is the site correct" but "is the site even up." Uptime, build health, and whether payments are actually going through, watched by robots so that the first one to know the practice is down is me and not a patient. Khai checks that the site is right; the monitoring checks that it's there. A solo practice needs both, and neither should depend on me remembering to look.