The Ability to Be Wrong Cheaply

I built a speed reading app. Used it for two weeks. Realized it was solving the wrong problem. Pivoted it into an RSS reader in a few hours.

That sequence used to take months. Research phase, build phase, beta phase, feedback phase, pivot phase. Each one with its own timeline and cost. The fear of getting it wrong justified spending weeks making sure we got it right upfront.

But what if getting it wrong costs almost nothing?

The Real Unlock

We talk a lot about building faster. AI-assisted development, code generation, spec-driven workflows. The conversation centers on speed: how quickly can we go from idea to working software?

That's the wrong frame. The real unlock isn't building faster. It's changing direction faster.

Speed matters, but not for the reason we think. A faster build cycle doesn't just mean shipping sooner. It means the feedback loop between idea, ship, and learn compresses so tightly that being wrong stops being expensive. And when being wrong is cheap, everything about how we make product decisions changes.

What Cheap Mistakes Look Like

The app is called Foveate. My wife showed me an Instagram reel of someone speed reading, and I'd never heard of RSVP before. Words flashing one at a time at a fixed point on screen. It intrigued me. I wrote 18 feature specs covering PDFs, ebooks, importing from open libraries, calibration, training mode. The vision was expansive. I started with research and specs, then built the core engine in two days.

I used it as my daily reader for two weeks. The speed reading engine worked exactly as specced. ORP anchoring, adaptive pacing, comprehension checks. Technically, it was solid.

Then I started paying attention to what I was actually reading. Engineering blog posts with code blocks. Articles with architecture diagrams. Newsletters with pull quotes and embedded tweets. Speed reading works for quick, linear text. But most of what I read isn't linear. I can't flash a code snippet one word at a time.

The engine I'd built served maybe 20% of my reading. The other 80% needed a normal reading experience.

The app wasn't wrong. The frame was.

What I actually needed was a way to keep up with the engineering world. An RSS reader where speed reading was a small feature, not the whole product. Subscribe to sources, read articles in a web view, but when the backlog grows, hit "Catch Up" and speed-read through LLM-generated summaries in three minutes.

The specs made the pivot surgical. I described the new direction to Claude, and it looked at the spec index, figured out which specs to cut and which to add, and planned the path from the old vision to the new one. One PR stripped the library, training, calibration, and onboarding. Another added a feed timeline, daily digests, and an article web view. The pivot deleted 5,600 lines and added 2,758. The app got smaller and more focused at the same time.

Total elapsed time from "this isn't right" to "this is what I actually need": a few hours.

Why This Changes How We Think

The traditional approach to product development assumes that mistakes are expensive. Requirements gathering, user research, prototyping, validation — all of these exist because building the wrong thing used to cost months of engineering time.

When engineering time stops being the most expensive part of the process, the calculus flips. We don't need to be right upfront. We need to be honest quickly.

I wrote a while back that the gap between wanting to build something and shipping it is rarely technical anymore. That was about the first half of the loop: idea to ship. But the second half matters just as much: ship to learn. When both halves are cheap, the whole loop tightens.

This doesn't mean specs and research are wasted effort. Code has become a cheap artifact, something Claude can regenerate in minutes. The specs are what matter. They're the shared understanding between me and the coding agent. Foveate's feature specs made it possible to rethink the entire product without losing context.

The investment shifts. Less time making sure the plan is perfect. More time making sure the plan is easy to change.

The Uncomfortable Part

There's a psychological cost to this that's worth naming. Building something, using it, and admitting it's wrong — in the same week — requires a kind of honesty that doesn't come naturally.

We get attached to what we build. The speed reading engine worked well. It was good engineering. Admitting it solved the wrong problem felt like admitting failure.

But the cost of holding onto something that doesn't fit is higher than the cost of letting go. And when letting go means a few hours of work instead of months of sunk cost, the decision gets easier.

What This Means

Engineering used to be the expensive part, so we built entire processes around not wasting it. Requirements documents, approval gates, lengthy design phases. All of it optimized for a world where building the wrong thing cost months.

That world is fading. When engineering loops are cheap, being wrong is easy. And when being wrong is easy, we can stop optimizing for correctness upfront and start optimizing for learning.