Build progress
Pawly is being built in the open. This page is a snapshot of what actually works, what has been verified and how, and what is still waiting on a decision rather than on code.
Pawly is not live yet. Everything described here runs and is verified on a local development stack. Nothing on this page describes a deployed service, a delivered message, or a processed payment.
Where things stand
Recently finished
Each of these is merged and passed the full check suite before it landed.
- T056
Pet-parent app follow-ons
Real provider search and pet projections replace the last fixtures, and the portal now exposes tips, store credit, prepaid packages, waitlist state, and gift-card redemption — each scoped to the account’s own affiliations.
- T055
Office reply composer
The office web thread sends through one unified client-visible path and keeps a separately labelled internal-note lane, so a private note can’t be mistaken for a message to the client.
- T054
Unified client-visible send
One hardened database write path now backs every client-visible reply, with trainees denied, an audit row per send, and inbox triage advancing off the same event.
- T053
Staff app messaging
Sitters read and post real threads from the field, with client-visible replies and internal notes visually distinguished. Verified on an iPhone 16 Pro, not only in tests.
- T039
Waitlist slot-open signals
A periodic scan re-derives availability read-only and queues a deduplicated, no-personal-data “a spot may be open” signal. It never schedules or mutates a booking, and a dedup ledger prevents notification storms.
- H04
Test isolation hardening
Integration suites were sharing fixture state and could collide run-to-run on a reused database. They are now hermetic, so a green run means the code is green rather than the order was lucky.
How it is checked
Nothing merges until this is green. The database tests run against a real Postgres instance reading through the same permission path a browser would use, so a test cannot pass by holding privileges the product does not have. Mobile changes are additionally run on a physical iPhone, because a passing test suite does not prove an app runs.
Waiting on a decision
These are not half-built. In each case the work is finished and tested behind a seam, and what is missing is an account, a credential, or a decision that only the business owner can make.
- O02
Deployment
- Today
- Web, marketing, and the background worker all build and run locally.
- Waiting on
- Hosting accounts and a worker host, plus approval to apply two pending database migrations.
- O03
Live payments
- Today
- Stripe Connect onboarding is built and verified end to end in test mode.
- Waiting on
- Identity verification with Stripe, then approval to enable live charges.
- O04
Real notifications and photos
- Today
- Scheduling, content, consent, and quiet-hours logic are built and tested against a no-op transport seam.
- Waiting on
- Text and email provider accounts, a media storage account, and the go-live decision on texting.
- O05
Push notifications
- Today
- Every message surface works in-app today.
- Waiting on
- Apple and Google push credentials.
- O06
Phase-2 integrations
- Today
- Not started — deliberately scoped out of the first release.
- Waiting on
- A decision on which integrations matter, plus their credentials.
- O07
Governance sign-offs
- Today
- The emergency-care and data-retention designs are written and reviewed; the code paths wait behind them.
- Waiting on
- Four recorded decisions covering veterinary authority, retention, intellectual property, and public pricing.
- O08
Signup persistence
- Today
- The signup form and its validation work.
- Waiting on
- A decision on where leads should land before the form is pointed at the public.