· 4 minute read
The notification that never arrived
A new service request is revenue walking in the door. Here is why it sometimes walks back out, and what a delivery ledger does about it.
The most expensive bug in pet sitting software is not a crash. It is a client submitting a request for a week of vacation visits, and nobody seeing it for two days.
By then they have called someone else. You never find out you lost it.
Send-and-hope is the default
Many tools call an email API, gets a 200 back, and considers the job done. But a 200 from a provider means the message was accepted for delivery, not that it arrived. Bounces, spam folders, a push subscription that expired when the sitter got a new phone, a carrier filtering the SMS, none of that shows up anywhere the owner will look.
What a ledger changes
In Porchlight, every intended send becomes a row before a provider is called: recipient, channel, template, status. The attempt updates the row with the provider message id or the error. Retryable failures back off and try again; terminal ones stop and raise a warning.
The admin header shows a health indicator. A weekly digest lists everything that failed. And most importantly, the request itself is watched, not just the message about it: if it is still unreviewed after your threshold, the owner gets an escalation and the dashboard shows a banner that does not go away until someone looks.
It is a small feature and a large difference
None of this is technically hard. It is a table, a backoff schedule and a banner. The reason it is rare is that it only pays off on the days something goes wrong, and those days are invisible if you are not recording them.
That is exactly why it should be built in.