Garrett Holmes Denver · replies within one business day

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 Three Peas in a Pod home page: “You see the vetting before you see the sitter.”, beside the request form asking what kind of care a family needs. Live

The evidence

Screens of the running thing

The Three Peas request form on a phone: “What do you need?”, with “A sitter for a date” selected and short-term care, a nanny placement, and a membership folded below it.
Exhibit A The request form, on a phone. It asks what kind of care first; once a family picks one, the other choices fold down to a line each.
Two phones side by side. The parent’s shows “Sunny is confirmed for Saturday, Sept 26 at 6:00pm.” The sitter’s shows the job offer, a YES reply, and the confirmation with the family and neighborhood.
Exhibit B The two-phone demo, with its invented cast. The sitter is offered the job and answers YES; the parent has a name back in the same minute. The texts are the real ones, word for word.
A family record: three sitters with Preferred, No preference and Never send buttons, one marked Never send with the owner’s private note, and the start of the family’s history, filterable by sits, texts, enquiries, notes and changes.
Exhibit C Part of a family’s record on the desk: the sitters they prefer, who are asked first, and the one they never want back, who is left out of every offer. The history below holds every sit and text.

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 connect

In
Parents site form · one text
Caregivers application + documents · replies by text
The system
Edge functions verify, then hand over
Dispatch worker 1-minute cron · first yes wins
Database families · roster · bookings
Document storage résumés · certifications
Out
Lead email to the owner
Sitter confirmed by text to the family
The desk roster · inbox · pipelines
Fig. 1 · Two kinds of people come in; one record and one desk come out.

Before & after

The account, both columns

Before

  • 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

01SvelteKit on Cloudflare Pagesstatic; every page a file
02Pages Functionsthe public edge: verify, cap the body, hand over
03One Worker + D1plain SQL, 44 forward-only migrations, a 1-minute cron
04R2caregiver documents, private
05Twiliotexting on one number, opt-outs mirrored to the database
06Stripememberships, invoices, card on file; no SDK
07Claude Haikua fenced fallback for texts the rules refuse
08bun test6,261 checks before every release

Garrett Holmes · The Operations Ledger

Composed by hand in Denver. Replies within one business day.