A desktop app wants an undo history that survives a crash. An edge gateway buffers sensor readings while its uplink is down and has to replay them, in order, once the link is back. An AI agent writes down every action it takes so a bad run can be replayed later. All three are the same data structure: an append-only sequence of records, plus readers that remember where they stopped. Kafka is that structure, and also a cluster, partitions and the people who tune them.

Run npm ls --all on a mid-sized web app and you get a tree that scrolls for pages. It’s accurate and complete, and on the morning a maintainer deletes a package it tells you almost nothing. You can see that tiny-util sits three levels down. You can’t see whether losing it breaks the checkout page or a script nobody has run since spring.

A dependency tree answers “what do I depend on”. The question that matters is “what breaks, and for whom, if this package vanishes or turns hostile”. They need different data. The tree comes from a lockfile. The answer comes from your own source: which functions call the package, which routes, commands and jobs those functions serve, and how much code would change to replace it. A tool that produced that for every package would turn dependency management from an inventory into something a product owner can read.

Compare two quickstarts. The first says to install Docker, bring up a compose file with a database, a cache and a worker, create an account, and paste a token into an env file. The second says to download one file and run it. Both tools might solve the same problem. Only one of them survives an evaluation that lasts ten minutes.

The second quickstart is a product decision, made in the architecture. SQLite and nginx made it decades ago, and Caddy, DuckDB, ripgrep, jq and Hugo have made it again in their own corners. Small surface area, few dependencies and one artifact to copy work as an adoption strategy. For a one-person or AI-assisted project they also work as the only scope control that holds up. That’s the claim, and the rest of this post tries to break it.

A line item’s quantity goes from 4 to 5. The order subtotal should change, and so should the tax, the order total, the customer’s lifetime value and the regional revenue figure on a dashboard. Which of those actually update depends on which code path made the edit, because each one gets recomputed somewhere different: the checkout handler, the invoice renderer, a nightly job, a SQL view somebody wrote for finance. Every copy of the formula is another chance for two screens to disagree.

Every app idea has a boring 90% and a nasty 10%. The boring part is CRUD, auth, a settings page, Stripe. The nasty part is the one subsystem that decides whether the thing works at all, and it’s usually not the part that looks hard in the pitch. Below are nine builds worth attempting, with the nasty 10% named up front so you can decide whether you want to spend your weekends there.

A team spends three weeks rewriting a hot loop in Rust bindings, shaves forty milliseconds off a function that runs once per request, and ships it. The page still takes four seconds to load. Nobody profiled first. That’s the pattern behind most performance work that goes nowhere: real effort, wrong target.

Optimization only pays off when you know where the time actually goes, and that’s rarely where intuition points. Developers tend to suspect their own code, because that’s the part they wrote and the part they can picture running slowly. The database, the network, the third-party API call buried in a middleware layer — those stay invisible until you measure them.

The default architecture for most mobile applications treats network connectivity as a reliable precondition. API calls are made on demand. Failures produce error states. The user waits for responses. This architecture produces apps that work acceptably on fast, reliable connections and badly on slow, intermittent, or absent connections — which describes the conditions under which many mobile users actually use apps.

Offline-first architecture inverts this assumption. The app reads from and writes to local storage first. Network synchronization happens in the background, opportunistically, whenever connectivity permits. The user experience is fast and available regardless of network state. The complexity is in the synchronization layer, which most teams underestimate significantly before they build it.

Every mobile app that does anything interesting eventually needs a backend. Authentication, data storage, push notifications, file uploads, real-time updates — the list of backend requirements grows quickly once an app moves beyond a local-only experience. The decision of how to provide that backend is one of the most consequential architectural choices a mobile development team makes, and it is one that becomes substantially harder to reverse after significant user data has accumulated.