The Cost of "What If" Just Collapsed

After twenty years of filtering out ideas because they were too expensive to try, I'm watching that filter stop working — and I don't want it back.

There's a mental move I've made a thousand times in my career. Someone raises a possibility — a feature, a product idea, an experiment — and a fast, quiet calculation runs in the background: how much would this actually cost to try? Usually the answer comes back "too much," and the idea gets filed away. Not rejected exactly. Just deferred indefinitely to a future where I have more time, more headcount, more budget.

I've been watching that calculation stop running.

Not because I've changed my standards. I'm still the same person who asks "what does this cost, and what does it slow down?" What's changed is what comes back when I ask. The answer used to be six weeks and two engineers. Now it's two days and a few hundred dollars in API spend. And at that price, the calculation doesn't really gate anything anymore — it's just yes, let's go see what this actually looks like.

That's the shift I've been trying to articulate to clients. It's not a productivity story. It's a curiosity story.

The thoughts I used to reject

I'm going to be honest about something: over twenty years of building software, I've had a lot of ideas I never tried. Not because they were bad ideas — most of them were decent, a few were probably great — but because the cost of testing them was too high.

The raw cost was one part of it. Standing up a proof of concept for anything non-trivial meant a few developers for a few weeks, which in real money is $30-60K. You don't write $30K checks to find out if you were right.

But the opportunity cost was worse. We had real initiatives shipping on real deadlines, and anything I pulled developers off to explore would slow those down. The math was always the same — "I'd love to try X, but we can't afford to lose two weeks on the current release." So the idea went into a notebook, or a Slack DM to myself, or just out of my head entirely.

Multiply that by every senior technical person I know, making that same trade-off every week, for twenty years. That's an enormous amount of unexamined wondering sitting on the industry's cutting room floor. A lot of it was probably noise. Some of it almost certainly wasn't.

The database that populated itself

Here's the specific moment I realized things had changed.

I was working on a client app that needed location data — real, populated database rows for a specific category of place in a specific geographic area. I didn't have any of it. In the past, I'd have had exactly two options:

Assign a developer to scrape the data, clean it, validate it, and load it into the database. A real week of work. For seed data. On a project that had more urgent things to build.
Use fake data. A dozen rows with plausible names and coordinates. Good enough to wire up the UI, but not good enough to test anything that actually mattered.

In the past, I'd probably have gone with option 2 and rationalized it. Fake data is fine for an MVP. We'll backfill later. That's the normal trade-off.

Instead I opened Claude Code and said: "Go find all the [category] in [area]. Get the details we need — name, address, hours, whatever else makes sense. Populate the database."

It worked. The database filled up with real rows, with real data, that was actually good. It took about an hour of my attention, a few model calls, and cost me something like the price of lunch. The app that had been running on fake data now had the real thing to test against.

I want to be clear about what changed here. It wasn't that I suddenly had a new tool. I'd had Claude Code for months. What changed was that the thought "maybe I can just ask it to do that" arrived at all. A year ago I'd have spent zero seconds considering it, because in my mental model that kind of work was expensive and had to be planned for. The thought just didn't come up.

Now it comes up constantly. And usually the answer is yes.

The math on proof of concept

Let me put rough numbers on the shift, because the scale of it is what makes it matter.

A proof of concept used to cost, conservatively, a few developers for a few weeks. Call it $30-50K and 4-6 weeks of elapsed time. That's the bar you had to clear to get an answer to "I wonder if this would work."

A proof of concept now costs a few days and a few developer hours of direction-giving. The API spend is typically under $200. Call it $2-5K all-in, and 2-5 days of elapsed time.

That's not a 2x improvement. It's roughly 1/30th the cost, and about 1/15th the elapsed time. That's an order-of-magnitude shift, and order-of-magnitude shifts change what questions you're even willing to ask.

At 1/30th the cost, you don't have to be right to justify the exploration. You just have to be curious. You try it. You look at what came out. You decide whether to keep going. Nobody has to commit to a quarter.

What I'm saying yes to now

A short list of things I've actually built in the last few months that I would have deferred or declined a year ago:

Flux Timer + its own MCP server. I wanted Claude Code to control my pomodoros, so I built a macOS menu bar app with an MCP server baked in. Two days. Wrote it up here.
A standalone 3D mesh viewer for specific science data measurements. Reads custom mesh files, renders 78,000 data points as a publication-quality visualization, all in a single HTML file with no server. I have no background in that science. A weekend.
Real seed data for a client app, populated by asking Claude Code to go find it — the one I described above.

None of these were serious commitments when I started. They were "let me just see what this looks like." One became a tool I use every day. One became a reference artifact I can show clients. One saved a week of tedious work. All three cost less than a normal team lunch.

The new question

The question that used to matter was "can we afford to try this?" That question has mostly stopped being interesting. The answer is almost always yes.

The question that matters now is "if we try this, what's the smallest slice that would tell us something real?" Thinking in chunks. Not "build the whole thing" — build the piece that would give you a signal. Look at the signal. Decide.

I've started saying this to clients when we scope anything exploratory: we're not committing to the whole idea, we're committing to a chunk of it that will tell us if the idea is worth more. Then we go find out, then we decide. "Pilot project" and "discovery phase" used to imply a big commitment with a soft exit. Now the commitment is small enough that the soft exit isn't even a concession — it's just how the work moves.

The gate that's gone

If you ask me what the real change is, after a year of building everything agentically, it's not the speed. It's not the cost savings, although those are real. It's this: I am no longer rejecting ideas before they get a chance.

For twenty years I carried an internal filter that rejected possibilities before they were fully formed. Too expensive. Too slow. Too much opportunity cost. Not a priority. It was a good filter — it kept me focused and it kept my teams from chasing every bright thing. But I'm realizing something uncomfortable about what it was actually filtering.

That filter is mostly gone now. It still fires on truly big commitments — a six-month build is still a six-month build, and agents haven't changed that. But on the "I wonder if X would work" scale, which is where most of the interesting ideas live, it just doesn't come up anymore.

And here's the part I didn't expect. Most of the things I'm trying are working. I thought exploring more would mean a lower hit rate and a higher absolute number of wins. What's actually happening is that the same product instinct I was using to decide which ideas to pursue is now deciding which ideas to try, and it turns out the instinct was already pretty good. The filter wasn't rejecting bad ideas. It was rejecting fine ideas that just couldn't justify the old cost.

The cost of wondering used to be real, and I'd built a career around being careful about what I wondered about. Now the cost is close to nothing, and I'm finding out what that means in real time.

Dave Shak is a Fractional CTO and Agentic Development consultant based in Kitchener-Waterloo. He has 20+ years of experience scaling engineering organizations and now helps teams adopt agentic development workflows.