A floppy disk's worth of app

Fast fits on a 1.44 megabyte floppy disk. Not literally, in the sense of magnetic storage and a school cupboard from 1998, but the same byte count. Everything that makes Fast work (the code, the drawings, the layout), compressed, comes in under 1.44 megabytes. That's a deliberate ceiling.

Floppies are dead. Why measure against one?

A floppy disk with a paper label reading Fast in green. Fast

One of these holds 1.44 megabytes. The whole of Fast fits, with room to spare.

Once Fast is on your phone it lives there. The first time you load it, the browser saves a local copy, and after that the app opens from your own device with no need to ask the internet for it. So the question "how big is Fast?" isn't really about waiting for a progress bar at the line. It's about two things that matter more.

Why small matters

The first is updates. Every time I release a new feature or a fix, your phone notices the update is waiting and quietly fetches it in the background, ready for the next time you open the app. Small means that handoff is quick. A bigger app would mean every update pulled a couple of megabytes down whatever signal you happen to be on at the time. Six hundred kilobytes makes the upgrade invisible.

The second is how much work the phone has to do. Every kilobyte of code is work: time to read it, memory to hold it, battery to keep it running. Two or three megabytes is enough to put a noticeable lag between tapping the app and seeing it ready, especially on an older phone. Six hundred kilobytes is almost nothing. Less code means more battery on a long day at the field, a snappier tap-by-tap response, and a phone that doesn't get warm from running a scorecard.

Where it can, Fast leans on what the browser already knows how to do. Forms, scrolling, page layout, all the everyday stuff: the browser handles that for free. Fast doesn't carry its own version. The code Fast does carry only handles the bits that genuinely need a brain, like arithmetic, your scores, and the rules of each round. Working with the grain of the phone, not against it.

Need more reasons? Check out A Manifesto for Small Software fitsonafloppy.com

Software has lost its way. Apps that once shipped on a single floppy disk now demand gigabytes of your storage, minutes of your time, and far too much of your patience. We accepted this gradual bloat, but that’s not progress.

How Fast stays small

Three things, mostly.

The first is graphics. Fast doesn't carry any photos. The tuning target, the score sheet, the achievement badges, the icons in the navigation bar, all of them are line drawings described in plain text the browser turns into shapes on the fly. A photo of a target face is a couple of hundred kilobytes. A drawing of a target face is a couple of kilobytes. Multiply across every icon in the app and you've saved most of a megabyte before anything else.

The second is hand-rolling things when a library would have been overkill. The form sparkline on each round card looks like a chart, but it isn't one. It's a few lines of code drawing little rectangles. A full chart library would have done the same job carrying nearly two hundred kilobytes along for the ride. Sometimes the lightest path is to write the thing yourself.

The third is discipline. Every time a new feature wants a new library, there's a question: is the size worth the value? Sometimes the honest answer is yes, it's better to re-use something battle-tested rather than write my own, but if the cost/benefit ratio is poor, I'll write a small thing myself instead.

A new guardrail

From this week, no new version of Fast can go out if it outgrows the floppy. If a future change pushes the download over 1.44 megabytes, the release stops at the door and nothing reaches your phone. It's an accountability handrail more than a hard rule: the number to beat right now is about six hundred kilobytes compressed, comfortably under the ceiling, with plenty of room to keep growing the app responsibly.

You won't see this. It runs once, before each release, and either lets the new version through or doesn't. But it changes how I add features. Every new one has to answer the same question: does this fit? If the answer is no, I look at the size again and find a smaller path. It's the same question, every time, instead of a one-off audit that happens once a year when someone notices the app got chunky.

Quality can drift. Every new feature shaves a bit off the budget, every new library takes a slice. Without a ceiling, those slices add up over months until one day the app takes three seconds to open on bad signal and nobody quite knows why. With a ceiling, the slow drift gets caught the day it starts.

What's next

The same discipline applies to icons, copy, every new feature. The bet Fast is making is simple: do less, send less, sit lightly on the phone you've got.