Visual mockups of each proposed fix. Most important to look at: Section 1 (Patch A — portal edit) — that's the data-correctness fix. Everything else is UX polish that can ship later.
Patch A · Critical correctness
A1. Dashboard chips become tappable
The dog chip row I shipped today is read-only. Customer can't pick which dog is shown in the hero card or which dog "Edit profile" targets. Fix: chips become clickable, tapping a chip swaps the hero to that dog and changes what "Edit profile" opens.
Current
Live today
🐕
Buddy
Golden Retriever · 4y · 65 lb
Friendly
🏡 at home
🐕MaxHusky
🐩LunaPoodle
Broken: Max and Luna chips just sit there. Tap doesn't do anything. "Edit profile" always edits Buddy regardless.
Patch A1
Tappable, hero swaps to picked dog
🐺
Max
Husky · 6y · 72 lb
Energetic
🏡 at home
🐕BuddyGolden
🐺MaxHusky · viewing
🐩LunaPoodle
Fixed: Tap any chip → hero swaps to that dog. "Edit profile" button name updates to Edit Max's profile so customer knows what they're editing. Featured chip is highlighted gold.
Patch A · Critical correctness
A2. Per-dog edit sheet
When the edit sheet opens, it currently always shows dogs[0]. Even if A1 ships, the edit sheet still needs to know which dog. Plus a backup dog-selector tab inside the sheet itself for fast switching.
Current
Live today
Edit dog profile
Broken: always shows Buddy's data. No way to switch to Max or Luna. Worse: if customer somehow opens edit for "Max" via a future fix, save will write to dogs[0] (Buddy's slot) — silent data corruption.
Patch A2
Sheet has a dog-picker at the top
Edit Max's profile
Fixed: sheet header shows whose profile is being edited. Tab row at the top to swap between dogs without leaving the sheet. saveDogEdits takes a dogIndex parameter and writes to the correct slot. Pairs with the data-layer fix below (D1).
Patch A · Cosmetic
A3. Status chip reflects actual checked-in state
Hero status chip currently looks at dogs[0]'s booking state. If Max is checked in for daycare but Buddy's at home, the chip says "🏡 at home" while Max is literally at the kennel. Fix: chip aggregates across all dogs.
Current
Wrong status
🐕
Buddy
Golden · at home
🏡 at home
🐺Maxchecked in
Hero says "at home" but Max chip shows "checked in". Customer is confused — which is it?
Patch A3
Correct aggregated status
🐕
Buddy
Golden · at home
🏡 Buddy at home · 🐕 Max checked in
🐺Maxchecked in
Single chip shows both states. Customer sees the truth at a glance.
Patch B · UX (Brandon ask 3 — Interp A)
B1. Dog detail in staff app shows owner's other dogs
Today the dog detail/edit view shows the owner as a plain text field. With multi-dog households, admin would benefit from seeing "this owner also has Max and Luna" with quick-jump links — discoverability for the household.
Current
Owner is just a string
🐕
Buddy
Golden Retriever
OwnerJane Smith
Phone(604) 555-0123
Weight65 lb
Age4y
No indication Jane has 2 other dogs at the same kennel. Admin has to remember or search to find Max/Luna.
Patch B1
Owner clickable + sibling dogs
🐕
Buddy
Golden Retriever
OwnerJane Smith ›
Phone(604) 555-0123
Weight65 lb
Age4y
🏡 Same household — 2 other dogs
🐺
Max · Husky🐩
Luna · Poodle
Owner name is now a tap target → navs to Jane's customer review. "Same household" callout shows the other dogs as quick-jump chips. Discoverability + flow for booking the same family.
When admin searches for a dog and that dog's owner has more dogs registered, surface a one-click "+ Buddy + Max + Luna" multi-pick UI to take all bookings in one flow.
Current
One dog at a time
🐕
Buddy
Golden Retriever · Jane Smith
To book Max too, admin closes this flow and starts again from search. 3-dog household = 3 round trips through the booking flow.
Patch C1
Detect household, multi-pick
🐕
Buddy
Golden Retriever · Jane Smith
🏡 Jane has 2 other dogs — book together?
Buddy is auto-selected (admin's search target). Other household dogs appear as checkboxes. CTA updates as admin checks/unchecks. Save creates linked bookings for all picked dogs in one atomic write.
Patch C · UX
C2. Customer portal: book multiple dogs at once
Mirror of C1 but on the customer side. Today the booking-request flow shows a single "Which dog?" dropdown — customer can only request a stay for one dog per submission. Households with multiple dogs going on the same trip have to submit twice.
Current
Dropdown — one dog only
Which dog?
What kind of stay?
☀️ Daycare
🏕️ Boarding
Customer wants to board Buddy + Luna. Has to submit two separate requests. Admin sees them as two separate things to convert.
Patch C2
Multi-pick: book all dogs at once
Which dog? (pick one or more)
✓
🐕
Buddy
Golden · 4y
🐺
Max
Husky · 6y
✓
🐩
Luna
Poodle · 3y
What kind of stay?
☀️ Daycare
🏕️ Boarding
Customer picks any combination of their dogs. One submission covers them all. Admin sees a single multi-dog booking-request with all picked dogs to review/convert together.
Summary & recommended order
Each patch is independently shippable. Patch A is the only one with a real-data-loss bug (D1) hiding in it — the rest are UX improvements.
Patch
What it fixes
Severity
Est
A1+A2 Per-dog edit + tappable chips + ID alignment (D1)
Edit second dog from portal · stop silent /kennel-data corruption · IDs match across paths
Critical
~1 hr
A3 Status chip multi-aware
"At home" chip stops lying when one dog is checked in
High
~15 min
B1 Dog detail → owner's other dogs (Brandon ask 3, Interp A)
Discoverability for multi-dog households in staff app · jump to owner's customer record
Medium
~30 min
C1 Take-a-booking multi-pick (Brandon ask 3, Interp B)
Book Buddy + Max + Luna in one flow · saves clicks for boarding multi-dog households
Medium
~45 min
C2 Portal: request stay for multiple dogs
Customer picks any combination of their dogs in one booking-request
Low
~30 min
My recommendation: ship A1+A2+A3 in one patch (~75 min) — closes the critical correctness gap. Then pause, let you live with multi-dog for a few days, and decide on B1 / C1 / C2 based on actual workflow friction.
Alternative if you want maximum impact today: ship A1+A2+A3 + B1 (~110 min). B1's discoverability win is small but cheap, and pairs nicely with the per-dog edit for completeness.
Hold off on C1+C2 for now — they're nice but require new RTDB write patterns (multi-dog booking-request shape, multi-booking atomic creation) that I'd want to design carefully rather than rush.