Shipping beats planning.

The longest meeting I have ever sat in was about a feature that took four hours to build. Nobody in the room was wrong. Everyone was arguing from a model in their head, and no artifact existed in the world that could settle which model was right.

Planning is compressed guessing

A plan is a prediction about a system that does not exist yet. Some predictions are cheap and reliable — how long the migration takes, roughly what the schema needs. Others are pure fiction — how it will feel to use, where people get stuck, which edge case turns out to be the main case.

The mistake is treating both kinds the same and spending equal effort on them. The second kind cannot be reasoned into correctness. It can only be observed.

If the disagreement is about what will happen, stop discussing and go find out. It is almost always cheaper than the meeting.

The one-day rule

When a debate has run past an hour with no new information, I ask one question: can a rough version exist by tomorrow? If yes, we stop talking and build the rough version. Not a design document, not a spike report — something a person can click.

The prototype almost never wins the argument for one side. What it does is reveal that both sides were arguing about the wrong thing, which is the actual value.

Make it disposable on purpose

A prototype people are afraid to delete has already failed. Build it so throwing it away costs nothing.

git switch -c spike/pricing-model
mkdir -p spikes/pricing && cd spikes/pricing

# Rules, written into the README on line one:
#   1. Read-only credentials. Never prod writes.
#   2. Hardcode everything not under test.
#   3. Delete by Friday. Calendar invite exists.

echo "DELETE BY: $(date -v+5d +%Y-%m-%d)" > README.md

• Separate branch, separate directory, never touching production data.
• Hardcode what is not being tested. The point is the one uncertain thing.
• Announce up front that it will be deleted. Then actually delete it.

The moment a prototype is quietly promoted to production, you have traded a day of learning for a year of technical debt. Discipline about deletion is what makes fast prototyping sustainable rather than reckless.

Sort by reversibility, not by size

This is not an argument against thinking. Plan hard where mistakes are expensive and irreversible: data models, public interfaces, anything touching money or identity, anything you cannot roll back. Those decisions deserve the whiteboard, because the feedback loop is measured in years.

Irreversible + expensive   -> design review, write it down
Irreversible + cheap       -> one careful hour, then commit
Reversible   + expensive   -> prototype, measure, decide
Reversible   + cheap       -> just ship it, stop discussing

For layout, flow, naming, ordering, and the shape of an interaction the feedback loop can be one afternoon. Use it.

What this looks like in practice

The teams I have seen move fastest were not the ones that skipped planning. They were the ones that knew instinctively which category each decision fell into, and refused to spend irreversible-decision effort on a reversible one. Speed is mostly a routing problem.

Joseph Ali — Director of IT & Technology. hello@josephali.com