The metal hook of the coat hanger scraped against the weather stripping of the driver’s side window with a sound like a fingernail on a chalkboard. It was 3:14 in the afternoon, and the keys were resting on the center console of the sedan, mocking me through three millimeters of tempered glass.

I had stepped out for ten seconds to grab a stray coffee cup from the roof, and the car, following some internal logic of security I hadn’t consented to, had decided I was no longer its rightful occupant. I stood there, looking at the keys, then at the wire in my hand, then at the reflection of my own frustrated face in the window.

The glass created two separate realities: one where the engine could start and the heater could run, and one where I was standing in a cold parking lot with a piece of salvaged hardware, trying to bridge a gap that shouldn’t have existed.

The Luxury of Unconscious Ownership

This kind of sudden, mechanical insulation is usually how we realize we’ve lost touch with our own tools. We think we own the machine, but we only own the experience of the machine as it behaves when everything is going perfectly. When the glass is between you and the ignition, you realize you don’t actually know how the door lock works; you only know how to press the button.

In the world of software and web development, we spend most of our lives on the inside of that glass. We are given the keys on day one. A courier arrives with a box. Inside is a laptop that costs more than the first three cars I ever owned.

The machine described above has a Liquid Retina XDR display capable of 1,600 nits of peak brightness. This is the “pro” standard. It is offered as a perk, a sign of respect, a tool for the elite.

Within six weeks, that machine becomes the developer’s entire world. It defines the baseline of what “fast” feels like. It creates a physical, neurological intuition for how a button should respond and how quickly a page should render. But here is the measurement error: that intuition is calibrated to a device that less than four percent of the global population will ever hold.

The Bakery Floor vs. The Glass Office

Ahmed R.J. works the third shift at a commercial bakery four miles from my house. He starts his day when most people are finishing their first cycle of REM sleep. His tools are different. He deals with massive Hobart mixers, industrial proofing cabinets, and stainless steel tables that have been scrubbed so many times they’ve developed a soft, matte patina.

Ahmed doesn’t care about the “experience” of the oven; he cares about the thermal mass and the recovery time after the door has been opened. He knows that if the oven takes too long to get back to temperature, the crust won’t shatter the way it’s supposed to. He is intimately connected to the physical constraints of his output.

I used to think that giving a developer a faster computer made them a more efficient worker. I was wrong. I spent years advocating for the highest possible specs for every new hire, believing that reducing “compile time” was the only metric that mattered.

I realized eventually that I wasn’t just buying them time; I was buying them a suit of sensory deprivation armor. By removing every friction point from their work environment, I was ensuring they would never accidentally experience the product they were building the way a customer experiences it. I was paying to make them blind.

When you sit on a 940-megabit fiber connection in an office in San Francisco or New York, the internet doesn’t feel like a series of tubes or a cloud. It feels like a local hard drive. You click, and the data is there. You never see the “loading” spinner for more than a flicker.

You never see the layout jump as an image slowly crawls into view. You never feel the heat of a processor struggling to parse two megabytes of unoptimized JavaScript on a mid-range Android phone.

The industry treats this as an empathy problem. We have meetings about “user personas.” We put up posters with pictures of “Sarah, the busy mom” or “Kevin, the rural entrepreneur.” We tell our engineers to “think about the user.”

If your thermometer is off by twenty degrees, no amount of wishing for the patient to feel better will give you a correct reading. The engineer isn’t being mean; they are simply trusting their own eyes. And their eyes are looking at a screen that costs $3,500, connected to a network that never falters.

Consider the equipment list of a typical modern household in the 75th percentile of global internet users. It is not an M3 Max MacBook. It is a four-year-old Samsung A-series or a Xiaomi Redmi. It is a laptop with a Celeron processor and a spinning hard drive that takes three minutes to boot up.

The Architecture of Isolation

Professional classes are systematically insulated from the conditions their work produces. This is a pattern that repeats across every high-skill industry. Urban planners are often given reserved parking spaces at City Hall, which ensures they never have to experience the transit system they designed or the parking scarcity they manage.

Hospital administrators have private entrances and bypass the waiting rooms where the actual “service” of the hospital is experienced. The insulation is always presented as a luxury or a necessity for productivity, but its primary function is to make the consequences of bad design invisible to the designer.

If you want to see how a website actually performs, you have to break the insulation. You have to put down the “pro” hardware and pick up a $200 phone with a cracked screen. You have to throttle your connection until the text takes five seconds to appear.

The weight is real. The average web page in 2024 is larger than the entire install size of the original Doom. We ship megabytes of tracking scripts, font files in four different weights, hero images that could be printed on a billboard, and frameworks that require the browser to do a massive amount of “thinking” before anything can be clicked.

To a developer on a fast machine, this is “overhead.” To a user on a slow machine, this is a broken door. This is why the approach taken by Digital Heroes is so divergent from the agency standard.

They don’t show you a screenshot of a perfect Lighthouse report run on a machine with unlimited power. Instead, they verify performance at the 75th percentile of real-world users. This means they are looking at the data from the people who are actually struggling-the people with the old phones and the bad signals.

They write these thresholds into their contracts. If the largest contentful paint isn’t under 2.5 seconds for those real users, the work isn’t finished. This shift from “average” to “75th percentile” is the difference between a designer who looks at a blueprint and a designer who walks the site in the rain.

The baked goods Ahmed R.J. produces at 3:00 AM are not meant for him. They are meant for people who will buy them twelve hours later, after they’ve sat in a plastic bin or under a heat lamp. He knows this.

He adjusts the moisture content of the dough because he knows the air in the grocery store is dry. He is accounting for a reality he doesn’t personally inhabit during his shift. Developers rarely do this. We build for the “now” and the “here.”

We build for the bright lights of the office and the silence of the high-speed fan. We forget that the most common way for a human being to interact with our work is while they are frustrated, in a hurry, on a device that is running out of battery, in a place with bad reception.

The Civil Engineering of Digital Spaces

When I finally got that coat hanger through the top of the door frame, I spent twenty minutes fishing for the lock. I could see it. I could see the little plastic nub. But the angle was wrong. The tool I had-a piece of wire from a dry cleaner-wasn’t designed for this.

Software is increasingly becoming that “smart” system. We add layers of complexity because our machines can handle them, never stopping to ask if the user’s machine can. We treat the browser as a playground rather than a utility.

We forget that for most people, the internet is not a hobby; it’s a way to pay a bill, find a doctor, or talk to a child. When we make those things slow, we aren’t just being “inefficient.” We are creating a barrier. We are locking the keys inside the car while the user is standing in the rain.

We need to stop treating web performance as a technical optimization and start treating it as a civil engineering constraint. In bridge building, you don’t calculate the load for a sunny day with three small cars. You calculate for the once-in-a-century storm with a line of fully loaded semi-trucks. You build for the worst-case scenario because that’s when the bridge actually matters.

The same is true for the web. A site that works on a 16-inch MacBook Pro is not a success; it’s a default. A site that works for the person on a three-year-old phone in a basement-that is an engineering achievement. That is what happens when you stop trusting your own “pro” intuition and start measuring the real world.

I eventually got my car door open. The weather stripping was mangled, and there was a long, thin scratch on the paint near the handle. It was a permanent reminder that the barrier between me and my own tools was thinner than I thought, but much harder to cross than it should have been.

I sat in the driver’s seat and felt the heater kick on, and for a second, I was back in the “pro” reality. But I kept looking at that scratch. It was the only part of the car that told the truth about how the afternoon had actually gone.

We should spend more time on the devices we hate, on the networks that fail us, and in the waiting rooms we try to bypass. Only then can we see what we are actually building. Only then can we see the glass.