Fail fast. But for whom? | Nexus Inclusion, Skip to main content
People of different abilities using technology with accessibility features represented by icons

Fail fast…

Ship the MVP. Validate. Iterate. Kill it quickly if the numbers don't move. Don't get precious. Don't gold-plate. Get it in front of people and let the market tell you the truth.

I understand the logic. I'm a founder too. I've built things, launched things, watched some of them not work. And there's real wisdom buried in the mantra: don't spend two years and your life savings polishing something nobody actually wants.

But I keep arriving at one question the mantra never seems to answer.

Fail fast for whom?

Because here's what "ship the minimum" tends to mean in practice. It means the quickest thing you can get in front of some users.

"Some users," almost always, does not include people with disabilities. Not the person using a screen reader. Not the person navigating entirely by keyboard. Not the someone whose eyes can't parse your low-contrast grey text on a slightly-less-grey background.

They're not in the MVP. They were never going to be in the first cut.

Accessibility is often treated as a finishing touch, something to worry about only after product-market fit is secured. I want to take that idea apart, because I think it's wrong on its own terms. Not just morally, but strategically.

Your MVP isn't as "viable" as you think

Roughly, one in five people lives with some form of disability. That's not a rounding error. That's not an edge case you can defer to a future sprint. That's a fifth of your market.

So when you launch a product that excludes them and then read your early metrics, what have you actually learned? You've learned how a subset of people respond to your idea. You've validated against a slice of the market and treated the result as the whole truth. That's not lean. That's a measurement error you built on purpose.

An MVP that excludes disabled users isn't a minimum viable product. It's minimum viable for able-bodied people. Which is a different, smaller, and much less honest thing.

Accessibility isn't the polish. It's part of "does it work."

This is the part I most want founders to hear. Accessibility gets filed under "nice-to-have," alongside animations and a clever onboarding tour. But it doesn't belong in that pile. It belongs next to "can people actually complete the core task."

If a portion of your users literally cannot use the thing you built, you haven't shipped a rough version of a working product. You've shipped a product that doesn't work for them. That's not an aesthetic gap. It's a functional one. And here in Europe, it's now also a legal one.

The European Accessibility Act is in force. The "we'll get to it after Series A" posture isn't just short-sighted anymore; for a lot of products it's non-compliance.

There's a cost argument too, and it cuts the opposite way from what people assume. Retrofitting accessibility onto a product that was built without it is slow, painful, and expensive. You end up ripping up decisions baked in at the foundation.

Building it in from the start costs a fraction of that. So the "fail fast" instinct to defer it doesn't even save you time. It borrows time from a future version of you at a brutal interest rate.

What is the product actually for?

Underneath all of this is a question I don't think founders ask themselves often enough: what are you actually trying to make?

Because "fail fast" quietly assumes an answer. It assumes the goal is to find the shortest path to something that makes money. And look, I'm not naïve about money. A business that doesn't make any isn't a business, it's a hobby, and I want to build something that lasts.

But surely the goal is to build something good. Something that works. Something that works for as many people as it possibly can.

When we built our product, we took the time to do that, and I've never once regretted the days it added. It's the part I'm proudest of. It's the reason it's worth doing at all.

If your only metric is speed-to-revenue, accessibility will always lose the argument, because caring about people who are easy to ignore never shows up in this quarter's numbers. But that's a statement about your metrics, not about your users.

Fail fast, by all means. Just don't fail narrow.

I want to be fair to the idea I'm poking at. Learning quickly is good. Testing your assumptions before you bet the company on them is good. I'm not asking anyone to spend two years in a cave perfecting something in silence.

What I'm asking is this: when you build the fast version, build it for everyone from the first line. Because if your idea is so fragile that it only survives by quietly excluding a fifth of the population, failing fast won't save it. It'll just teach you the wrong lesson faster.

Build it right, and build it for everyone. That, to me, is the version of "moving fast" actually worth doing.

— Written by a founder with a disability, who'd quite like the products of the future to work for people like him.

Explore more Accessibility Resources

Learn more about digital accessibility, inclusive design, and how to build accessible products from the start with our practical guides, articles, and expert insights.