k4i.com now publishes three kinds of post on its own: risk factor changes from 10-K filings, earnings guidance checked against results, and a chip and AI infrastructure press release digest. No server, no paid inference, no one at the keyboard. Each one is a scheduled GitHub Actions workflow in the site’s repo that reads a public source, runs it through a model, checks the output with plain code and commits a Markdown file. Cloudflare Pages builds the site from there.

The cheapest AI app to run is one where the user’s own machine does the work. Your server hands out files, the browser downloads a small model once, and every inference after that happens on the visitor’s GPU or CPU. You pay for static hosting. That’s it.

This used to be a demo trick. In 2026 it’s a reasonable way to ship a real tool. WebGPU now runs in Chrome, Edge, Safari 26 and up (iPhone and iPad included) and Firefox on Windows and Apple Silicon Macs. Transformers.js v4 runs vision, speech, embedding and classification models on WebGPU and falls back to WebAssembly when there’s no GPU path. The pieces are boring enough to build on.

If you build AI features alone and can’t afford a surprise bill, the model you pick matters less than where it runs and who triggers it. Get those two right and inference costs nothing or close to it. Get them wrong and a free tier runs dry by lunch, or a paid API quietly eats your month.

What follows is the reasoning I’d give any solo builder, worked out the long way: by throwing ideas at the wall and watching most of them fail one test or another.

A useful software primitive gives another program a clear operation to depend on. Its explanation can fit into a sentence because its boundary is narrow: append an event, validate a proposed change, compute a difference or reserve a unit of capacity. Its value grows when the behavior behind that sentence is dependable enough that replacing it would mean recreating a substantial set of guarantees.

Easy to explain should describe the interface, not the difficulty of the work. “Store a value under a key” sounds simple until the user asks about durability, concurrency, ordering, limits and recovery after a crash. Those details decide whether the component belongs in a real system. A short description is a promise to make complexity manageable at the boundary, not permission to leave the difficult behavior undefined.

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.