Sync conflicts delete drafts—here's the map you need
The café down the street installed new pendant lights last week—warm Edison bulbs that throw long shadows across the marble tables where half the neighbourhood taps away on laptops, phones face-down, AirPods in. Every one of them trusts that their words will still be there when they switch devices.
Productivity apps silently sync drafts across devices—and delete them
Cross-device sync in Notion, Obsidian, and Apple Notes can overwrite or delete drafts without warning.
You close your laptop mid-sentence, open your phone ten minutes later, and the last three paragraphs are gone. No conflict dialogue, no recovery prompt, no trace in version history. The app simply chose one version and discarded the other.
Most productivity tools sync changes in near-real-time, but they handle conflicts differently. Notion merges edits at the block level—if you change paragraph two on your phone whilst paragraph four syncs from your laptop, both usually survive. Apple Notes uses a last-write-wins model: whichever device saves last obliterates the other. Obsidian stores plain text files, so sync conflicts surface as duplicate files with timestamps—but only if you notice them before they’re purged by your cloud provider’s versioning limit.
The risk compounds when you work offline. Your laptop queues twenty minutes of edits whilst your phone queues five. When both reconnect, one set disappears. Some apps flag the collision; most don’t. Understanding which tool uses which conflict-resolution strategy—and how long deleted versions persist—determines whether you lose work or recover it. The behaviour isn’t documented in onboarding flows, and most operators only learn it after the first silent deletion.
TACTIC
WordPress transients pile up faster than plugins clean them
Transients are WordPress’s answer to temporary data—caching API responses, storing session tokens, holding countdown timers. They’re supposed to expire automatically, but many plugins write them and never sweep up. A site running a dozen popular plugins can accumulate thousands of transient rows in wp_options, bloating queries and slowing admin screens. Most operators never check the table because WordPress hides the mess behind a tidy dashboard. The fix is a manual purge or a scheduled job, but you need to know the problem exists first.
WORTH READING
When automation webhooks retry, they trigger your workflow twice
Zapier, Make, and n8n all retry failed webhooks—sensible behaviour when a server hiccups. But if your endpoint returns a 500 error after processing the first request, the platform assumes failure and fires again thirty seconds later. You’ve now charged a customer twice, sent duplicate welcome emails, or created two rows in your CRM. Most platforms don’t deduplicate by default; you have to build idempotency keys into your receiving endpoint or add a filter step that checks recent history. The retry logic is documented, but the double-trigger consequence isn’t obvious until it happens in production.
FROM THE ARCHIVE
Newsletter ad networks pay net-60—cash flow math for solo operators
You send a sponsored edition in January, the ad network confirms payment in February, and the money lands in your account in March. Net-60 terms are standard for most newsletter ad networks—Swapstack, Paved, and Letterwell all follow similar cycles. That two-month gap between send and payment means your operating account needs enough runway to cover hosting, tools, and freelance costs whilst you wait. If you’re running multiple sponsorships per month, the delay compounds into a rolling float. Operators who don’t model the lag often mistake booked revenue for available cash, then scramble when invoices come due before the ad cheque clears.
Know someone who would like this? Forward today’s email—every operator we reach is one closer to running an online business with a little less friction.