The D.E.M.O. Way - Blaž Kos

A new development methodology for the age of AI.

The Problem

Every development methodology in history was designed to solve the same problem: building the wrong thing is expensive.

Waterfall tried to prevent it with exhaustive upfront planning. Agile tried to catch it early with short iteration cycles. Lean tried to eliminate it with continuous validation. Each was a rational response to the economics of its era.

But the economics have changed. The cost of building a demo is approaching zero. And when trying is free, planning becomes overhead.

We are entering an era where anyone can manifest a working prototype in hours. Where the fastest path to alignment is not a meeting, a spec, or a user story. It is a thing that runs.

The Shift

Artificial intelligence has collapsed the cost of creation. What once took a team of engineers weeks to prototype can now be vibe-coded in an afternoon by a single person with a clear idea and the right tools.

This changes everything. Not incrementally. Fundamentally.

Old bottleneck

Engineering capacity

✍

→

New bottleneck

Judgment

👁

The scarce resource is no longer engineering capacity. It is judgment. The ability to look at something real and say: this is valuable, or this is not.

The Framework

1. Deploy

Someone has an idea — a feature, a product, a workflow, a fix. Instead of writing a specification, a user story, or a ticket, they open an AI tool and build a working prototype. No permission required. No grooming session. No estimation poker. Just build the thing.

Time: Hours, not weeks

Output: A running demo, not a document

Who: The person closest to the problem

2. Evaluate

Evaluation happens in two stages:

Stage A: Internal Demo

Show it to your team. The team gathers around an actual artifact — not a mockup, not a slide deck. A thing that works. The question: Is this valuable enough to put in front of real users?

Stage B: External Demo

Put it in front of your audience. Real users interacting with a real prototype generate signal that no internal discussion can replicate. Feature flags, sandboxed previews, invite-only releases.

3. Modify

Based on the evaluation, the team decides: kill it, tweak it, or go deeper. Because AI makes modification cycles nearly instant, you can run three to five iterations in a single afternoon.

This replaces sprints. There is no two-week wait. There is no velocity tracking. There is only: show me the next version.

4. Operate

Once the value is confirmed — and only then — you invest in making it production-grade. Tests. Security. Scale. Observability. Documentation.

This is the only phase that resembles traditional engineering. And now it is justified, because you know the thing is worth building.

Rigor earns its place by following proof of value, not preceding it.

The Seven Principles

I A demo is worth a thousand meetings.

Show the thing. Do not describe the thing. Do not debate the thing. Do not schedule a meeting to align on the thing. Build the thing and put it in front of people. Reactions to reality are more honest and more useful than reactions to imagination.

II The cost of trying is now near zero. Act like it.

The old economics demanded caution because building was expensive. The new economics reward boldness because building is cheap. If you are still asking permission to try, you are operating on yesterday's assumptions.

III Feedback on something real beats consensus on something imaginary.

Humans are terrible at evaluating abstractions and brilliant at evaluating experiences. Stop asking people to approve specifications. Start asking them to react to prototypes.

IV Kill fast, not plan slow.

Most ideas should die. That is healthy. In the old world, ideas died slowly — suffocated by months of planning, building, and launching. In the DEMO world, ideas die as demos, in hours, before anyone has invested their identity in them. This is a feature, not a bug.

V AI is the new junior team. Direct it, do not manage it.

You do not write tickets for AI. You do not run standups with AI. You give it context and direction, and it builds. The skill of the future is not project management. It is creative direction.

VI Ceremony is overhead. Every ritual must justify itself.

If a meeting, process, or artifact cannot outperform "just build it and show me," it does not deserve to exist. This is not anti-process. It is anti-waste. The DEMO cycle is itself a process. It is just radically compressed.

VII The person closest to the problem builds the first draft.

Not a PM writing tickets for someone else. Not a designer making mockups for a developer to interpret. The person who feels the problem builds the first version, even if it is rough, because their intuition is the most valuable raw material in the process.

How It Compares

	Waterfall	Agile	DEMO
Unit of work	Specification	User Story / Sprint	Working Demo
Planning	Months upfront	2-week sprints	None — just build
Feedback loop	After delivery	Every sprint	Internal + External demos
Who builds first	Engineering team	Dev team	Anyone with AI
Key ceremony	Design review	Daily standup	Demo session
Risk model	Prevent mistakes	Catch early	Mistakes cost nothing

When to Use DEMO

DEMO is not a universal hammer. It is optimized for environments where:

⚡

AI tools are available

The methodology assumes that building a prototype is fast and cheap. Without AI leverage, the Deploy phase takes too long.

Value is uncertain

If you already know exactly what to build, traditional engineering may be more efficient. DEMO shines when the question is what to build.

⏳

Speed of learning matters

If your competitive advantage depends on rapid iteration and market responsiveness, DEMO's feedback loop is unmatched.

👥

Cross-functional judgment

DEMO works best when the Evaluate phase includes diverse perspectives — product, design, engineering, customers.

The Demo Session

The Demo Session is the only required ceremony. It is the heartbeat of the process.

Before the Session

The demo is shared in advance. Every participant tests it themselves and arrives with written notes. Specific observations: what worked, what confused, what is missing, what should be cut. The session is not for discovery. It is for decision.

During the Session

Duration: As long as it takes to reach an updated spec.

Frequency: As needed. When there is something to show, show it.

Attendees: The builder, the stakeholders, anyone whose judgment matters.

Format: The builder walks through the prototype. No slides. No preamble.

The Output: A Versioned Spec

The output is an updated specification, versioned like code. Each demo session produces a new version. Version 1.0 is the original demo. Version 1.1 reflects the first session's feedback. Version 2.0 marks a major pivot.

Minutes document what was said. Versioned specs document what was decided.

This is not a rigid framework. It is a philosophy with structure. Adapt it. Break it. Rebuild it. That is, after all, the point.

Stop planning. Start showing. Welcome to DEMO.