The Concept Document Was a Workaround

10 min read

Build It, Don’t Describe It

Why Concepts Existed

Nobody writes a concept document because they enjoy it. They write one because building the wrong thing used to be catastrophically expensive.

I’ve run spikes with teams of 25 people. A spike is a timeboxed experiment, typically constrained to a single work day, where the entire team attacks a question: Can we do this? Is this feasible? What breaks when we try? One day, 25 people, answer by end of business.

In organizations that were fed up with papers describing a fantasy, management loved spikes. It was liberating. Instead of another concept document nobody believed in, you got a real answer in eight hours. The team built something, hit the walls, found the edges, and came back with evidence instead of opinions. That felt honest.

But spikes cost real money. Twenty-five people for a day is not cheap. And a prototype over several weeks that gets thrown away? Many organizations couldn’t stomach that. So the default remained: describe the thing on paper, argue about the description, get sign-off on the description, then build.

The document was a proxy for the thing itself. A stand-in. A beautiful artistic rendering of a house instead of an actual house. That proxy made economic sense when every line of code was hand-typed, manually tested, deployed through a ritual involving three approvals, a change advisory board, and a deployment window at 2 AM on a Saturday. The cost of building was high. The cost of writing was low. Do the cheap thing first. Nobody questioned whether the cheap thing was the right thing.

The Blueprint Illusion

There’s a deeper problem with concept documents, and it has nothing to do with cost. It’s a mental model borrowed from the wrong profession.

Concept documents feel like blueprints. An architect thinks, designs, specifies. Then construction workers build according to the specification. The thinking happens first. The building is mechanical execution. Knowledge workers design. Manual workers construct.

This has always been a misunderstanding when applied to software. Software development is not engineering in the traditional sense. An engineer applies known standards to known problems. A bridge, once designed, gets built exactly as specified. The blueprint works because the problem is understood, the materials are predictable, and the physics don’t change halfway through. Building codes and engineering standards carry legal weight. Ignoring them is an offence. An engineer who deviates from the specification faces liability, not a retrospective.

Software is nothing like that. Requirements shift. Users surprise you. Systems interact in ways nobody predicted. The act of building reveals the problem. You don’t understand what you’re making until you’re making it. The developer isn’t a construction worker following someone else’s thinking. The developer is the thinker. The code is the thinking made concrete.

When organizations treat concept documents as blueprints, they split thinking from building and hand them to different people. “Knowledge workers” produce the specification. “Programmers” execute it. That split guarantees failure, because in software the most important thinking happens during construction, not before it. Every interesting discovery, every critical design decision, every “wait, this won’t work because…” moment happens when someone is actually building the thing.

The concept document didn’t just cost time. It institutionalized a false separation between people who think and people who type code. Smart people write down what to build, then coders go code it. That mental model never fully died. The concept document is its last surviving artifact.

The Economics Flipped

Here is what changed. I can describe a system to an AI assistant and have working code within hours. Not pseudo-code. Not a mockup. Working, testable, deployable code. The spike that used to require 25 people and a full work day? A single developer with an AI assistant reaches the same conclusion in an afternoon. The prototype that used to consume a sprint now emerges in a day or two.

This isn’t theoretical. This is my Tuesday.

When a developer can produce a working prototype faster than a product manager can write a concept document, the economics flip entirely. The document is now the expensive option. Not because paper costs money, but because the document takes longer to produce, generates less information, and creates a false sense of certainty that the actual build will inevitably destroy.

A concept document tells you what someone thinks will happen. A prototype tells you what actually happens. One is opinion. The other is evidence.

Feature Flags Changed Everything

The real game-changer isn’t just that building got faster. It’s that feature toggles let you ship production-ready code while keeping it invisible.

Think about what that means. A developer builds a feature. Real code, real tests, real deployment. It goes to production. It sits behind a flag, invisible to users. A product owner, a stakeholder, a customer advisory board, whoever needs to approve it, can toggle it on in a staging environment, see it work, validate it against reality, and decide.

No document required. No concept review meeting where twelve people debate hypothetical edge cases that may never materialize. No sign-off on a description of something nobody has seen. The thing exists. Toggle it on. Look at it. Decide.

The old objection was always: “But what if we build the wrong thing?” Valid concern. Bad solution. A concept document doesn’t prevent building the wrong thing. It prevents building anything until enough people agree on a shared hallucination about what the right thing might be. Then you build it and discover the hallucination was wrong. Just like every time before.

Feature-flagged code does something concept documents never could: it lets you fail cheaply in production. Build three approaches. Flag all three. Test each with real users. Measure. Kill the losers. Ship the winner. Try doing that with a concept document.

What Concept Documents Actually Produce

A concept document produces three things reliably: delay, false confidence, and meetings.

Delay, because writing the document, reviewing it, revising it, and getting sign-off takes weeks. During those weeks, nobody is learning anything from actual software. The market moves. Competitors ship. Users develop workarounds.

False confidence, because a well-written document feels like progress. Everyone nodded. Everyone agreed. The document has sections and diagrams and a risk assessment. Surely the hard part is done. It never is. The hard part starts when code meets reality: unexpected API behavior, data that doesn’t match assumptions, users who interact with the system in ways nobody imagined while staring at a Word document.

Meetings, because every document generates a review cycle. More people in the room means more opinions means more revisions means more meetings. None of these meetings produce working software. They produce revised documents that will also be wrong, just differently wrong.

The Real Skill Was Always the Same

None of this means “stop thinking and start typing.” The skill isn’t typing. The end of coding didn’t end the need for judgment. You still need to understand the problem. You still need to talk to users. You still need to grasp the domain well enough to build something useful.

The difference is how you exercise that judgment. Before, you wrote. Now, you build. Before, you described your understanding. Now, you demonstrate it. AI as a thinking partner doesn’t replace thinking. It makes the gap between thinking and tangible output so small that the intermediate document becomes unnecessary.

Good developers have always known this. Back in 2010, I wrote about using Cucumber to start development from a conversation with the customer, capturing requirements as executable specifications in plain language, then building test-first with no concept document in sight. The feature file was the shared understanding. The passing test was the proof. AI didn’t invent building-as-thinking. AI made it fast enough that even organizations addicted to documents can’t ignore the alternative anymore.

The people who were good at concept documents were usually good at thinking. Their skill was never the document. It was the clarity of thought behind it. That clarity now expresses itself in working software instead of formatted PDFs. Better for everyone.

Experts Think in Screens, Not Systems

But let’s not romanticize this. Most subject matter experts don’t think in systems. They think in screens. Ask a business stakeholder what they need, and they’ll describe a form with fields, a button that does something, a report that shows numbers. Software for them is what they can click on. Everything behind that surface, the data model, the integration points, the failure modes, doesn’t exist in their imagination. Not because they’re stupid. Because nobody ever showed them.

That’s why concept documents survived so long. The subject matter expert described screens. Wireframes. Button labels. The concept document captured what was visible and ignored what was structural. It felt complete because it covered every pixel. It was hollow because it said nothing about data consistency, error recovery, or what happens when two users press that button at the same time.

A working prototype changes that conversation. When subject matter experts see screens responding, they click, type, get confused, and ask questions no concept document ever provoked. “Wait, what happens if I enter nothing here?” That confusion is pure gold. Their frustration becomes the requirements document. Their “that’s not what I meant” becomes the test case. All of it emerges from touching the software, not from reading about it.

When Documents Still Make Sense

Regulatory compliance where an auditor requires written specification before implementation. Safety-critical systems where lives depend on proven correctness before deployment. Contractual obligations where a client pays for a defined deliverable.

These are legitimate. They are also fewer than you think.

I worked on an axle counter system for a German railroad supplier. Safety-critical doesn’t get more real than that. Trains, tracks, lives. The regulatory requirements were extensive: SIL (Safety Integrity Level) certification, traceability from requirement to test to deployment. The kind of domain where you’d expect concept documents to be indispensable.

We figured out that TDD met every compliance requirement. Every test traced to a requirement. Every requirement traced to a test. The audit trail was better than anything a concept document could provide, because it was executable. You could run the proof.

But the company didn’t adopt it. The compliance framework wasn’t really about proving correctness. It was about distributing blame. Concept documents existed so that when something went wrong, everyone could point to the sign-off chain. “I approved the concept. The developers deviated from the concept. Not my fault.” When the test suite is the specification and the tests pass, accountability is clear. No room for the comfortable fiction that twelve signatures on a document mean twelve people verified correctness. They didn’t verify anything. They attended a meeting and didn’t object loudly enough.

Even in regulated industries, the concept document often survives not because regulation demands it, but because organizations prefer diffused responsibility over clear accountability. The document is a shield, not a specification.

The other 90% of software built every day has no such excuse. It needs a developer who understands the problem, an AI that accelerates the build, a feature flag that controls visibility, and a stakeholder who can say yes or no when they see the actual thing.

Stop Arguing About Concepts. Start Shipping Evidence.

The person who walks into the room with mockups and says “build this” has a new competitor: the developer who walks into the room with the working thing and says “try this.” One brought a description. The other brought evidence.

The concept document was a workaround for expensive construction. Construction got cheap. The workaround is no longer needed. Build it. Flag it. Show it. Decide. Move on.