Progressive Enhancement

Products used to be built against the best available environment, with everything else listed as unsupported. If it looked right in the newest browser, the building was considered done.

The problem is that the people building don't get to choose the environment. A company-issued laptop runs a browser from several years ago, a connection on a train delivers half the scripts, an office security policy blocks anything loaded from outside. Those users don't find the product mildly inconvenient — they can't do anything at all. Discovering days before a contract closes that a customer's security settings stop the save button from working is how this shows up.

Progressive enhancement reverses the order. The core action gets finished first using the simplest available means, and conveniences get layered on afterwards, as far as the environment accepts them. When a layer falls away, the one underneath is still there and the person can still finish what they came to do. Nothing about that requires them to notice that anything fell away.

Build the core action with the simplest means, check the environment, then add on top of it. Five steps.

1. Name the one thing that has to work on this screen. On an editor, writing text and saving it. On a checkout, getting card details to the server. Formatting toolbars and auto-arrangement don't belong on that list.
2. Build it with means that work without scripting. On the web that means links and form submissions: press save, the server takes it, a new page comes back. Slow and plain, and it works everywhere, including in environments nobody on the team has ever tested.
3. Ask the environment whether it has what you want to use. Not by browser name and version, but by checking for each capability individually. Splitting by name means maintaining a list every time a browser ships, and anything missing from the list gets excluded by default.
4. Add it where it's there. Saving as you type, dragging a file in, updating a result without redrawing the page — those live in this layer. Add them in order of what matters least to completing the task, so the most expendable thing is also the most likely to be missing.
5. Use the product once without the upper layer. Turn scripting off and check that saving works; throttle the connection and check that nothing freezes. Skip this and step two quietly stays empty, since nothing in normal use would ever reveal it.

Getting this order right is mostly a matter of building the plain path first, while it is still easy to build. Retrofitting it under a working screen is a different and larger job, and it usually arrives as an urgent one.

It's for products whose environment can't be controlled. Anything sold as a web product qualifies, and inside that, the paths where failure leaves no alternative — signing in, paying, submitting — get it first.

The value rises with enterprise customers. Security policies differ company to company, and which scripts get blocked isn't knowable before the contract. With the base layer standing, the work still gets done in that environment, so evaluation doesn't stall on a question no salesperson can answer in the room.

It points the same direction as accessibility, designing so people can use a product regardless of disability or circumstance. Someone using a screen reader, which reads screen contents aloud, or navigating by keyboard alone, mostly travels through the base layer. A complete base layer means less to build separately for them, and less to maintain as two parallel paths afterwards. The habit in responsive design of laying out the small screen first is the same thinking applied elsewhere.

There are bad fits. In a 3D editor or a video editor, the upper layer is the product, and no base-layer version of it exists. Better there to state the requirements up front and show a clear notice outside them, rather than a broken screen that looks like a bug. Internal tools have less to gain too: when the company issues one browser at one version, there are no branches to check.

"Make sure saving works in an environment where scripts are blocked."

Don't ship the upper layer without a base layer under it, however rare the blocked case looks.

"Let's check for the capability instead of splitting on browser name."

Changing how the environment gets judged, from a list somebody has to maintain to a feature check.

"This can't have a base-layer version. Let's show a proper unsupported notice."

A judgment that the approach doesn't apply here, and that saying so plainly is the better option.

Pagedeck met this on its first enterprise contract. The customer's security policy blocked externally loaded scripts, so autosave never ran and edits disappeared. Theo looked and found there was exactly one path to saving, and it was autosave. Nobody had decided that; it was just the only one anyone had built.

The fix wasn't to add a feature. The save button came back, handled by the server without scripting, and autosave moved into the layer above it. Noa chose to leave the button on screen, greyed out, in environments where autosave does run — a screen that changes shape between environments leaves people hunting for what moved.

The most common mistake is reading it as support for old environments. Old browsers come up often in the discussion, so the reading is natural. But what the approach governs isn't the age of the environment — it's the order of building. Nor does it mean giving up new capabilities. You use all of them; you just lay a floor underneath so their absence doesn't stop the work. Understood as an old-browser concern, it leads to the conclusion that a market on current browsers doesn't need it, and blocked scripts and slow connections happen on current browsers too, on the same laptops the team tests with.

Assuming it doubles the cost is the other one. Two layers exist, so the arithmetic looks obvious. But keeping the order stops the total from growing much. The base layer is small precisely because it uses plain means, and the upper layer is added on top rather than designed as a second product from scratch. Where the cost genuinely doubles is in the reverse order: ship only the upper layer, wait for reports from environments where it fails, and now a floor has to be threaded underneath a screen already in use.