The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Because Firestore evaluates security rules on the server, a write queued offline can be refused after reconnection, so hold the saved label until a snapshot shows hasPendingWrites and isFromCache both false, which your listener sees only with includeMetadataChanges: true.
Ye le Jani:
This is such a crucial Firestore nuance! Most people miss the hasPendingWrites + isFromCache combo - super valuable tip for handling offline writes properly. Thanks for sharing!
This is the kind of subtle Firestore gotcha that can haunt an app for weeks before anyone connects the dots. Holding the saved label until the snapshot confirms both flags false is a really clean rule of thumb. Have you run into this on Android and iOS equally, or does one platform's cache behavior make it trickier?
Good catch. Offline writes getting rejected after reconnect trips a lot of people up.
Holding the saved label until both hasPendingWrites and isFromCache are false is a neat rule, since a server-side security rule rejection after reconnect would otherwise leave the UI claiming a save that never happened. The includeMetadataChanges: true detail is the part I'd most likely have missed.
Thank you! You get the point.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
A push notification model usually breaks in one of two ways: a second phone stops receiving anything, or notifications keep arriving for the account that just signed out. Both come from storing one push address per user. Store one row per app installation instead, with the user ID as a field, and someone with a phone and a tablet has two rows that a single query returns.
The sign-out half has an ordering trap. Delete the installation row while the user is still signed in, then call signOut. A security rule that compares the row owner to the signed-in user refuses the delete once there is no user left to compare against, and the device keeps pointing at the previous account.
The full write-up covers the Firestore rules, the Flutter registration listener, a server cleanup that handles both unregistered error codes, and an acceptance sequence to run on two test installations.
duskolicanin.com
Keep Flutter Push Tokens Correct Across Devices
Fix Flutter push notifications that miss a second device or follow the previous user: store one FCM installation ID per device and prune unregistered IDs.
Great breakdown! The sign-out timing is such an easy detail to overlook, but it can cause real issues. 👏
Backfill: every cancellation becomes a booking.
Why: a late cancellation leaves an empty chair. Filling it means calling down a waitlist, which nobody at a busy front desk has time for, so the hour and the revenue are simply lost.
What it does: when a patient cancels, Backfill offers the slot to everyone on the waitlist whose service, day and time match, all at once. The first to tap Claim gets it. The slot is re-checked first, so nobody is ever double-booked. Everyone else is told it's taken and keeps their place. The front desk sees every step on a live dashboard, along with the revenue recovered. If nobody claims within 30 minutes, staff get a "Needs you" alert.
Try it: open the link and choose "Use a demo account". Nora is the front desk; Sarah, Mike and Amara are patients. Cancel as Sarah in one window and claim as Mike in another. Or register with your own email and tap "Send me an offer" to get the real offer email.
Built with Base44: the data model, the offer chain, a demo clinic that refreshes every day, a demo sign-in with an in-app inbox, real offer emails, and a split-screen demo view.
Behind the build: a design system and a clickable prototype first, then every screen rebuilt in Base44's AI chat, one prompt at a time.
Data, offer automation, real emails and the front desk dashboard all run on Base44, responsive down to a phone.
FirstReply — reply first, win the booking
Description
Event venues lose bookings because they reply a day late. By then the client has booked somewhere else. FirstReply answers every inquiry with a priced proposal and a held date in seconds.
The automation
1. An inquiry arrives from the venue page, or staff paste in an email.
2. AI extracts event type, date, guests, budget and requests, each with a confidence level and the exact words it came from.
3. Missing date or guest count? It writes a clarifying reply instead.
4. It matches the smallest free space that fits (or the two nearest free dates when it's booked), prices the right package and holds the date for 5 days.
5. The client gets their own proposal page and books with one tap. The hold becomes a confirmed booking.
6. Unsure details, over-budget totals or Review mode send it to a review queue first. Humans step in only when needed.
7. Views, acceptances and expiring holds update the pipeline and alert the team live. Every step is logged to the second.
The design A full design system first (tokens, type scale, components), built as a clickable prototype, then rebuilt in Base44 from prompts. Client pages are mobile-first; the venue side is desktop-first.
Try it Client side: firstreply.base44.app · Venue side: firstreply.base44.app/dashboard