Case file № 001 · Process rebuild · Client system
The agency that ran on one inbox
- System
- Three Peas site + dispatch
- Client
- Three Peas in a Pod · Denver nanny and babysitting agency
- Status
- Live on her domain since September 20, 2026 · dispatch and billing on staging
A Denver nanny and babysitting agency ran on a template website, one long form for every family, an inbox, and the owner’s phone. I rebuilt the site, live on her domain since September 20, 2026, and then built the operation behind it: sitters found by text with the first yes winning, members booking in a single text, a record for every family and every sitter, memberships and invoices, and a desk that holds the business on one screen.
The evidence
Screens of the running thing


Captured from the live request form, the demo, and the desk rendered with an invented family and sitters. No real family or caregiver data.
The system
How the parts connectBefore & after
The account, both columnsBefore
- Every family filled in the same long form. A new parent weighing a full-time placement and a regular who needed someone for Saturday night answered the same questions.
- Each request became an email the owner read, then a round of calls and texts to sitters, one at a time, until someone was free. The parent waited on a person reading a form.
- Which sitter sat for which family, whose CPR card was about to expire, and which sitter a family never wanted back lived in the owner’s head, her phone, and her inbox.
- Caregivers applied by email attachment. The site was an off-the-shelf template that had drifted: three fee lists that disagreed, and its best page linked from nowhere.
After
- One source for every price. Every page reads the same file, so the site can’t disagree with itself. Every old address forwards to its new home, and an old per-service link opens the request form with that service already chosen.
- A request form that asks what kind of care first and folds everything else away. A returning member gets one screen and is remembered on that phone for 90 days. Every lead reaches the owner’s inbox from her own domain, with a fallback sender if the first one fails, and ad links are tagged so she knows which post brought a family.
- Caregivers apply on the site and upload a résumé and certifications straight to private storage through short-lived upload links. Each open role has its own shareable page; filled roles drop out of search.
- Sitter dispatch by text. A request texts the right sitters, and the first yes claims it in one conditional database write, so two yeses can never both win. A sitter the family rated highly or asked for by name is asked first and waited for; anyone else’s yes becomes a standby the parent is told about. Every sitter has quiet hours, and a cancellation starts a backup fill.
- Members book in one text, in their own words. Rules read it first. A language model is asked only when the rules refuse, and it never does date arithmetic: it quotes the words it read, code works out the date, and a quote that isn’t in the text is refused. Every booking is read back, and only YES books. On 101 texts written blind by a reviewer, none was read wrong.
- A record for every family, without buying a CRM. One timeline of texts, requests, bookings and placements; a second adult who may book; the sitters they prefer and the ones they never want back. Removing a family redacts them from every table, and a test checks every table afterward.
- The desk: the sitter roster with a watch on CPR and First Aid expiry and a Monday email, one inbox for every text thread, pipelines for placements and applicants, standing weekly sits a family can skip by text, and exports.
- Memberships, gifts, card on file and placement invoices through Stripe, with the renewal notice Colorado requires and a one-step cancel. A review found a payment outage being read as a declined card, which would have invited a second charge; it and four other money bugs were fixed before any money moved.
- Everything that can text, charge or email a family ships behind its own switch, and turning one on is a release like any other. Each piece was reviewed, tested, and landed through one release gate. The site is live; dispatch, booking by text and billing run on staging and on a two-phone demo with an invented cast.
The verdict
The site was the part anyone could see. The work was everything that has to be true before a text reaches a sitter at 9pm: that two yeses can’t both win, that “a week from Saturday” is never read as this Saturday, that a payment outage isn’t mistaken for a declined card, and that nothing able to text or charge a family goes out until someone turns it on on purpose.
Bill of materials
What was used, and the job it did| 01 | SvelteKit on Cloudflare Pages | static; every page a file |
|---|---|---|
| 02 | Pages Functions | the public edge: verify, cap the body, hand over |
| 03 | One Worker + D1 | plain SQL, 44 forward-only migrations, a 1-minute cron |
| 04 | R2 | caregiver documents, private |
| 05 | Twilio | texting on one number, opt-outs mirrored to the database |
| 06 | Stripe | memberships, invoices, card on file; no SDK |
| 07 | Claude Haiku | a fenced fallback for texts the rules refuse |
| 08 | bun test | 6,261 checks before every release |