Short answer
#The system
Slotwise lets clinics publish appointment slots and lets patients book and pay for them. A team of two built it over three years: a web application, a worker that sends confirmations and reminders from a queue, and a scheduler that closes unpaid bookings every night. The owner sells it and does not read code. The original lead developer is leaving next quarter.
#What the first analysis maps
| Component | What it is for | Talks to |
|---|---|---|
| Web application | Clinic dashboard, public booking pages, the payment step | Database, cache, payment provider, queue |
| Queue worker | Confirmation and reminder emails, calendar updates | Queue, email provider, calendar provider |
| Nightly scheduler | Closes bookings left unpaid, writes a CSV export for one clinic group | Database, file storage |
| Payment webhook | Receives payment events and marks bookings paid | Payment provider, database |
| Database | Clinics, slots, bookings, patients | Web application, worker, scheduler |
| Cache and queue store | Sessions, cached pages, the job queue | Web application, worker |
| File storage | Uploaded clinic logos, the nightly export | Web application, scheduler |
Five outside services appear at the edge of the map: the payment provider, the email provider, a calendar provider, an error tracker and an analytics service. The last two were added by somebody at some point and are on no list the owner has seen.
#Three claims and their evidence
- A booking is marked paid only by the payment webhook. Observed in the webhook handler and in the booking model, where no other code path sets the paid state.
- Patient email addresses are sent to the email provider and to the analytics service. Observed for the email provider in the notification code. Observed for analytics in the tracking snippet of the booking page, which sends the address as a user identifier.
- Unpaid bookings are closed after thirty minutes. Declared in a comment and in the README. Observed in the scheduler as twenty-four hours. The two disagree, and the picture says so rather than picking one.
The second claim is the kind an owner did not know to ask about and needs before a privacy question arrives. The third is the kind that only shows up when declared and observed facts are recorded separately.
#What nobody could establish
- Whether the calendar provider is still used by any clinic, or only configured.
- Who owns the account with the error tracker, and where its alerts go.
- What the clinic group does with the nightly CSV export.
- How long patient records are kept after a clinic leaves.
None of these can be answered from code. Each one goes on the list with the reason it is open, and two of them, the error tracker account and the retention of patient records, are questions for the developer who is leaving, while there is still somebody to ask.
#The second analysis
- Changed in the system. The payment webhook moved to a versioned address. The old address still answers, and the payment provider is still configured to send to it.
- Newly learned, not changed. The worker retries a failed reminder three times, and logos are resized on upload. Both were true a month ago and simply not recorded.
- Not reported as gone. The second analysis does not mention the nightly CSV export. It also did not examine the scheduler again, so the export becomes a question, not a removal.
- No longer confirmed. The statement that reminders go out a day before an appointment rested on a setting in the web application that the second analysis no longer finds. Where the value comes from now was not established, so the statement is marked as no longer confirmed, with the date it was last supported.
#What the owner does with it
Three things, none of which needs the owner to read code. They take the briefing into a thirty-minute call with the developer, where the first item is the moved webhook and the old address the provider is still using. They ask the two questions only the leaving developer can answer, and the answers are written where the next analysis finds them. And they add a line to the privacy notice, because patient email addresses go to an analytics service, which they did not know a week ago.