I rebuilt my wife’s physical therapy site with an AI pair

What AI pairing taught me about clearer booking, readable mobile interfaces, cautious prototypes, and a scheduler we chose not to ship.

My wife, Cristina Bracamonte, PT, DPT, runs a one-person, cash-pay physical therapy practice. She drives to patients around Temecula and Murrieta and has no front desk. I build software, so I help where I can, with her approval for changes that touch her practice.

This article was adapted with AI writing assistance from my development field notes. The work described used Claude as a coding pair; the decisions and examples come from that project. The screenshots show the site and development prototypes, not patient records or a clinical validation study.

The goal was to move from about one new patient a week to three without adding phone tag. That was a target, not a measured result of the redesign. Over a few days, we worked on the site, a pre-screening prototype, and a technical review of the form system behind it. The useful lesson was how much development work followed from deciding what the interface should promise.

A booking button is a decision, not just a conversion

The old site offered three paths: pediatric therapy, senior mobility through Medicare, and private mobile PT. Two were marked “coming soon.” The page asked visitors to choose between a service they could use and two they could not.

We narrowed the site to the work the practice could deliver: in-home care for older adults who want to stay steady and independent. Balance, recovery after knee or hip replacement, vertigo, and back and joint pain became the page structure. The new headline described the outcome in ordinary language instead of asking the visitor to interpret our service categories.

The price and payment explanation moved next to the request button. The original button made it easy to call without understanding that the practice was cash-pay. Cristina still had to explain the payment model by phone.

Now the interface presents the visit price, payment timing, and the availability of a superbill before someone requests a visit. A separate payment page explains the steps. It should help a visitor understand the choice; it should not promise that their insurer will reimburse them.

The development implication was concrete: this information needed to be part of the reusable booking component, rather than copy maintained separately on each page. A booking button on a condition page should carry the same expectations as one on the home page.

Readability changed the implementation

My first pass used a decorative serif headline. Cristina’s feedback was blunt: hard to read. We switched to Inter, raised the site’s base text to 19px, and simplified the labels. The revised mobile screenshot makes the audience, the main request, and the payment information visible in one reading sequence.

This was feedback from the person running the practice, not evidence that we had tested the design with every older reader. I would not call a larger font an accessibility certification.

WCAG’s contrast guidance gives a useful check on text and background combinations. Its text-resizing guidance is a reminder that readable defaults still need to work when people enlarge them. Contrast, layout, and resizing are separate checks; a good score on one does not establish the others.

We also split routes and removed unused code. Those are useful implementation changes, but a smaller build is not evidence by itself that a page is easier to use. The next check belongs on the phone: load the page, enlarge the text, and follow the request path.

Turn a content preference into a build check

Some provider information belongs on private documents rather than an indexed marketing page. That preference is easy to lose during an AI-assisted edit: an agent can treat a detail as credibility copy without understanding where the practice wants it shown.

We added a check to the deployment path. It searches the built public output for values in a local, gitignored denylist and blocks deployment if it finds a match. The values themselves do not need to go into the article, the repository, or the error message.

The limitation matters: the current script skips the check when its list is missing or empty. It also checks exact strings, so it cannot prove that all private information is absent. It is a guard for known values, not a general privacy scanner.

That is the development lesson I would reuse: when a design decision has a release consequence, encode the part you can check and make its limits visible. “Remember not to include that” leaves the decision dependent on whoever is doing the next edit.

A movement prototype needs an honest results screen

We also built a quick-check flow and experimented with a camera-based movement check. The camera prototype uses MediaPipe pose landmarks and measurement logic written in Rust and compiled to WebAssembly. MediaPipe’s web documentation describes the landmark output; those coordinates are inputs to our logic, not a diagnosis.

The development simulator replays known landmarks through that logic. This is useful for checking a screen, its timer, and its response to controlled inputs. It does not establish how accurately a real camera measures a real person.

The result language therefore describes an observation: one turn was smaller than the other. It also says that camera readings are estimates and that the result is not a diagnosis. The balance screen keeps an obvious stop control in view. Those details are part of the interaction, not fine print added after the feature works.

The privacy objective was to process movement on the device. I am not treating that objective, or a “not recorded” label in a prototype, as proof that every dependency and network path has been verified. A claim in the interface needs evidence from the implementation and its actual configuration.

The form review changed what we could responsibly claim

The practice uses TendForm, the form platform I run. Reviewing its handling of health information was part of this work, but a technical review is not a HIPAA compliance certification.

The review produced automated checks and manual follow-up items. A check supports a specific configuration at a specific time. Deployment status and operational follow-up still need separate verification. I would not turn that record into a blanket claim about retention, immutability, or complete access logging.

For a product team, that boundary reaches all the way to the copy. A reassuring badge, an email notification, or a privacy sentence can promise more than the evidence supports. Write the claim down, identify the check that supports it, and record what still needs a human decision. Passing automated checks does not make the manual work disappear.

A working feature can stay parked

We designed a telehealth scheduler in TendForm: patients propose times, the system compares availability, and the practitioner confirms. Then Cristina’s real workflow won. A short qualifying form and a callback were already bringing in patients, and she likes talking to people.

The scheduler stayed parked until the practice needed it. A working implementation was not enough reason to replace a workflow Cristina preferred.

AI pairing makes it easier to build a feature before you know whether the person using it wants a different workflow. In this case, keeping the callback was a product decision the code could not make for us.

If I were starting this project again, I would write three things before asking the agent for the next change: the decision the visitor needs to make, the promise the screen makes about it, and the evidence needed before that promise can ship. Then I would review those with Cristina, alongside the actual page. The agent can draft the implementation. The practice still has to live with the result.

I rebuilt my wife’s physical therapy site with an AI pair was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.