An RSS reader that keeps what it fetches.

Six months ago we moved retry handling out of each service and into the edge layer. The change looked small on the diagram. It removed four separate retry implementations, three of which disagreed about what counted as a timeout.

The first surprise was how much traffic had been retries. Once every retry passed through one place, we could count them. Roughly a fifth of requests to our billing service were second or third attempts, and most of those succeeded on the first try from the edge.

The second surprise was jitter. We had it in two of the four implementations. Adding it everywhere flattened the spikes we used to see every time a downstream dependency blinked.

Most people never open the settings page. That is not a failure of curiosity. It is a reasonable response to software that has, over years, trained them that settings pages are where the confusing things live.

So the default is what ships. If the default notification cadence is daily, your product is a daily product. If the default view is a list, you make list software, however beautiful the optional board view is.

A useful exercise: list every default in your onboarding path and ask who chose it and why. The honest answer, more often than we would like, is that nobody chose it.

I spent the last year building a notes app where the sync layer is just a folder of Markdown files. There is no server. Any file sync tool works, including the one you already pay for.

The hard part was not sync. It was conflict handling that a person could understand. I ended up with a rule: never merge silently. Show both versions, side by side, and let the person choose.

Happy to answer questions about the CRDT experiments I abandoned and why plain files won.