Early on, two requests could both read 'this tractor is free on the 14th', both pass validation, and both write a booking row — a classic race condition. Optimistic locking (checking a version number before committing) reduced the failures but didn't eliminate them under real load, because the retry logic on the client just tried the same doomed booking again.

The fix was pessimistic locking at the database level: `SELECT ... FOR UPDATE` on the relevant availability row for the duration of the booking transaction, so a second request is forced to wait rather than race. It costs a little throughput under contention, but for a resource with hard physical availability — a single tractor can only be in one field at a time — correctness matters far more than raw concurrency.

The bigger lesson: not every problem needs the trendier solution. Optimistic locking is usually the right default for low-contention writes, but the moment a resource is physically singular and demand spikes at the same time (peak planting season, everyone booking the same three tractors), pessimistic locking is the boring, correct answer.

A two-week sprint dies by a thousand small interruptions: a client message that becomes an unplanned mid-sprint request, a "quick" bug that eats a full day, a scope conversation that should have happened at planning instead happening on day 8. My job stopped being just about code and became about noticing when scope was quietly drifting and saying so out loud before it became a crisis at the retro.

The other thing that surprised me: velocity numbers are far less useful than the conversation you have about why they moved. A sprint that "under-delivered" but surfaced a real architectural risk early is a good sprint. A sprint that hit every point but shipped something nobody double-checked against the actual requirement is a quiet failure.

Since then, I try to run retros around one question: what almost went wrong that we caught in time, and what didn't we catch? That question surfaces more useful signal than a burndown chart ever has.

The failure mode is subtle: the renderer shows one version of "current progress," the main process has already moved past it, and now your UI is lying to the user by a few seconds — just enough to look broken without ever throwing an error.

The fix was treating IPC like an actual API contract instead of a convenient tunnel: typed message shapes, a single source of truth for state living in the main process, and the renderer only ever rendering what it was explicitly sent — never assuming, never polling ad hoc. Once that discipline was in place, adding encrypted local state persistence on top was straightforward, because the state was finally well-defined enough to serialize safely.

If you're building anything in Electron beyond a static shell, decide on your IPC contract before you write the first scraping job, not after the third race condition report.