What happened
In an October 21, 2026 edition of the Aboard Newsletter, Paul Ford describes the launch of TinyLittleOffice.com, a web-based office suite that stores its data in the URL. Ford says he put roughly twice as much effort into building it as he might spend writing a long newsletter post. The project attracted enough visitors to exceed his Cloudflare free-plan capacity and take the server down. After he added a credit card, he says a couple hundred thousand people visited. The project also drew feature and fix requests on GitHub, received coverage from The Register, and briefly reached Product Hunt’s top ten. Ford says he plans to continue supporting and improving it while doing client software work.
The experience led Ford to a larger point: the browser is a powerful application platform, and the cost of using it is falling. He says his hosting costs were effectively zero after he optimized for cheapness, while acknowledging the initial capacity problem. He points to browser APIs and technologies including Web Crypto for security, WebAssembly for near-native-speed code, WebGL for graphics, and Web Audio for sound. JavaScript provides a full-featured programming language, while HTML can represent many kinds of documents. He also notes that browser applications can be multilingual and accessible; TinyLittleOffice launched in 21 languages.
Ford’s second example is Battle Drones, a browser-based 3D game by Simon Willison. Ford says it runs from GitHub, is multiplayer, and works offline. He highlights its use of audio for multiplayer interaction, and cites Willison’s view that “vibe coded” games could be taken seriously. Ford presents the game as evidence that a person without a games-industry background can now make a polished browser experience.
The essay’s claim is not that these technologies are new: Ford says the browser capabilities have existed for years, but are extensive and difficult to master individually. He argues that many were built for large companies and teams, leaving smaller builders to rely on libraries and abstractions. As development becomes easier, he sees potential consequences for app-store economics and for industries where custom software could improve a process or product. He also describes the shift as mixed: software may become easier to make, while the work of making it risks being undervalued.
What the archive adds
New Runtime’s earlier coverage of Northstar described browser-engine independence as an open-source engineering project, a different question from Ford’s focus on what individuals can build inside browsers. The essay is a new perspective on browser software, not a new browser release or a continuation of that project: Northstar browser.
Trend signal
This essay does not yet fit a pattern New Runtime tracks. Ford describes lower barriers to building browser applications, but the examples do not establish a shift in agent protocols, software capabilities exposed to agents, or another tracked pattern. The argument is worth revisiting if more projects show individuals shipping useful software through this route.
Why now
Ford’s timing is explained by his own recent experience: TinyLittleOffice had just launched and attracted a large audience, prompting him to reflect on the browser capabilities he had used to build it. He connects that experience to a broader moment in which software development feels faster and more accessible to him, rather than claiming a newly released browser technology.
Why it matters
For teams building with AI, the essay is a reminder that the model is only one part of the cost of turning an idea into a usable product. A browser already combines distribution with capabilities for graphics, audio, cryptography, and offline use. If AI-assisted development helps more people compose those capabilities, smaller teams may be able to test ideas that once required specialized staff or an app-store launch.
That possibility should not be confused with proof that production software is now effortless. Ford’s examples show what he and Willison built, not a measured change in the average cost, reliability, or maintenance burden of software. Still, they make a practical case for reconsidering whether a workflow really needs a native app or a large technology stack. A cheap browser prototype can test demand before a team commits to heavier infrastructure. The counterweight is economic: more software may mean more utility, but not necessarily more sustainable work for the people who build and maintain it.
Limits and uncertainty
Ford’s account is personal commentary, not a controlled comparison of development costs or a survey of browser projects. He gives no itemized hosting bill, traffic breakdown, development hours, or maintenance costs; “$0” describes the hosting cost after his optimization and plan-capacity experience, not a universal price for running an application. The examples do not establish how reliably similar projects scale, how accessible they are to users, or whether they can replace native applications. The essay’s predictions about app stores, industry disruption, and the value of software work remain arguments rather than measured outcomes.
Reader takeaway
A modern browser can be a serious platform for small, ambitious software—not just a place to display pages. Ford’s examples make a case for testing whether browser APIs can support a product idea before reaching for a larger stack. Treat the essay as an invitation to experiment, not evidence that building, scaling, and maintaining software have become cost-free.
Open question
Which kinds of software can individuals now build and sustain in the browser, and where do reliability, accessibility, and maintenance costs still require a larger team?