As Answers get Cheaper

So you want to build a project. You have a rough idea of what it is, a fuzzier idea of who it's for, and a nagging sense that you should figure both of those out before you write a line of code.

Don't. Or rather, don't wait. Here's why.

The questions become the expensive part

For most of the history of software, good answers were hard to come by. Perhaps you had a vision and knew what you wanted to achieve... that felt simple but the problem was getting it built. Months of specification, many more months of development, testing and re-working until it was "done"... and by the time the thing shipped you were already defending the budget it took to get there and being asked by your customers to make changes and add new features. That constraint shaped everything: how we planned, how we hired, how long we argued before anyone touched a keyboard. Getting it wrong was costly, too, so there was intense pressure not just to get it done but also to get it right the first time.

That constraint has mostly dissolved. I've written about this before: software is becoming ephemeral, and we can now build things we couldn't build before at a fraction of the old cost. A working answer to a well-posed question is a day's work, sometimes an afternoon's. Answers are cheap.

Which moves the bottleneck. The hard part is no longer building the thing. The hard part is knowing what question the thing is supposed to answer.

We've had a name for this problem since 1979. In The Hitchhiker's Guide to the Galaxy, a civilization builds a computer the size of a city, asks it for the Answer to Life, the Universe, and Everything, and waits seven and a half million years. The answer is 42. It's correct. It's also useless, because nobody ever worked out what the question was, and the computer's only suggestion is to build a bigger computer to find out.

That's where we are. The answer machine works. What we're short on is the question.

Uncertainty is the argument, not the obstacle

The usual reasons for not starting are all variations on "I don't know enough yet." I don't know exactly who this is for. I don't know if the market will still want it in a year. I don't know whether the technology I'd build on will exist in eighteen months, or whether the public will have swung from loving AI to loathing it by the time I ship. All true. None of it is a reason to wait.

Every one of those unknowns is a moving target, and you don't hit a moving target by aiming longer. You hit it by taking more shots and correcting between them. The only way to get more shots in is to start earlier, because iteration is paid for in calendar time, and calendar time is the one thing you can't buy back later.

The instinct to wait for clarity assumes clarity is out there, waiting, and that enough research or money or deliberation will deliver it. It won't. I've never seen a project where the understanding arrived before the work. What I have seen, over and over, is understanding arriving because of the work: you build something, you put it in front of someone, and their reaction tells you what you were actually trying to do. The first version is less a product than an instrument for finding out what the product is.

So the shifting ground isn't a warning to stay off it. It's the argument for getting on it now, while you still have time to be wrong a few times before it matters.

Millions of visitors, and still guessing

I want to be careful not to make this sound easy. It isn't... but I’ve lived the version where it was a lot harder.

Some years ago I worked on the web team at Lovehoney, an online retailer with millions of visitors a month and a serious appetite for conversion optimization. We used ContentSquare to measure the customer's experience and Monetate to make subtle changes to that experience. We ran A/B and A/B/n tests across enormous traffic with slight differences to the color, shape, size and positioning of text, buttons, product images... pretty much anything that could be changed. We had the budget, the tooling, and a volume of site visitors across four global regions that most teams only dream about, and the loop was as tight as the era allowed: change a button, a layout, a line of copy, then then track the numbers for a month or more, looking for a measurable and statistically meaningful change in sales.

Most of it was shooting in the dark. We would make small changes across several areas of the site, one change at a time, hoping that one of them would clear significance, and when one did, we were often honest enough with ourselves to admit we weren't sure why. Worse, we knew that by the time a result was solid enough to act on, the conditions that produced it had already drifted: a new season, a new campaign, a new competitor, a shift in what people were in the mood to buy or how the culture or the economy affected their purchasing decisions. The target moved while we were still reading the results of the last hit.

I don't tell that story to knock the practice; it was state of the art, and it worked well enough to be worth doing. I tell it because it shows what quantity looks like when the "directed" part is missing. We had the loop. What we didn't have was a clear enough picture of the question for the loop to converge on anything. More experiments produced more results, good and bad, not necessarily more understanding of the customer or the market forces that moved them.

That's the trap on the other side of this argument. Iteration without a definition of good isn't learning, it's motion. The volume has to point at something.

Pointing the volume at something

So what does "directed" look like in practice? Here's how I work it, both for Auth/Technic clients and for my own products. It isn't a methodology so much as three habits that keep the loop honest.

Align on the problem as the customer sees it

Before anything gets defined, I want to be able to describe the problem in the words the person living with it would use, not the words I'd use to solve it. These are rarely the same. A client will say "we need a dashboard"; what they mean is "I find out about problems from my customers instead of from my own systems, and it's embarrassing." The dashboard might be the answer. It might not. But the second sentence is the question, and I can't evaluate any answer until I've got it.

This step is uncomfortable because it produces nothing you can demo. It's conversation, observation, repeating back what you heard and getting corrected. It feels like delay. It's the opposite: it's the thing that makes every subsequent iteration count, because now there's something to measure against.

It also doesn't have to be finished. You'll get it partly wrong. The point is to have a stated version of the problem that the work can push against, so that when the work contradicts it, you notice.

Define the work as clearly and thoroughly as you can

Once the problem is stated, I write down what I think the solution is, in as much detail as I can stand: what it does, what it explicitly doesn't do, what "working" means, how we'll know. This is the part people skip when answers are cheap, on the theory that it's faster to just build it and see. It is faster to build it. It is not faster to find out whether what you built was any good, because without a definition you've got nothing to compare the result to except a vague feeling.

The definition is also where the AI tooling earns its keep. A clear, thorough description of the work is exactly what these tools are good at turning into software, and a vague one is exactly what they're bad at. The quality of the output tracks the quality of the question with almost embarrassing fidelity. Which is the whole thesis in miniature: the definition is the expensive part, and it's expensive because it's where the thinking happens.

Build, document, deploy, and show it

Then build the thing. Build it quickly, build it as described, and get it in front of the people from step one as fast as you can. Document what you built and why, so that when you come back to it (and you will) you can tell what was a decision and what was an accident. Deploy it somewhere real, even if "real" is three users and a staging URL. Then demo it, test it, and listen.

This is the step that closes the loop. The demo tells you where the definition was wrong. The definition tells you where the alignment was wrong. And the alignment, corrected, points the next round of building somewhere better. Each pass through the loop refines the question a little, and the question is the thing you were actually short on.

None of this is novel. What's changed is the cost of the third step, which used to dominate everything. When building took months, you could afford maybe two or three passes through the loop before the money ran out, so you front-loaded the first two steps and prayed. Now building is the fast part, which means you can afford to be wrong in alignment and definition and find out quickly, instead of being wrong expensively and finding out late. That's not a license to skip the first two steps. It's what makes doing them well finally pay off.

The time to get in the loop is now

The industry conversation right now is anxious. What happens to junior developers? Do we even need software anymore or will agents just do the work for us directly? Those are real questions and I've got opinions on them, but they're questions about the answer machine. I'm more interested in whether we get better at the part the machine can't do for us: understanding the nature of the problems we're trying to solve and the people we're trying to solve them for.

And the honest state of that is: it's hard, it stays hard, and it never finishes. Technology will change under you. The market will shift. Your users will want something different next year than they want today... next week, even, if your product is good enough, and the cultural weather around AI will blow hot and cold more than once before you're done. The question you're refining is not going to hold still long enough for you to get it perfectly right. The best you can hope for is to continually get closer.

Which is exactly why the loop matters more than the plan. Build, inspect, revise, redeploy; each cycle shorter than the last, each one teaching you something the previous one couldn't. AI has made that cycle tighter than it has ever been, and it's getting tighter while you read this. Think of jumping from a standstill onto a moving platform that’s still accelerating: the longer you wait to make the leap, the harder the leap gets. It may look chaotic from where you’re standing now, but once you’re on it, you share its frame of reference. The people who benefit won’t be the ones who waited until they understood today’s problem. They’ll be the ones who started early enough to keep pace with tomorrow’s, which will arrive faster than today’s did.

So start. Start unsure of what it is and who it's for. Start knowing that the thing you end up with will not be the thing you set out to build. That isn't a failure of planning. That's the plan working. The whole point of building is to find out what you should have been building, and you can't find that out any other way.

The answer is cheap. Go earn the question.