Show It Before You Build It

Here is a proposal for a section on a landing page.

I will add a clean, modern pricing section with three tiers, clear hierarchy and a highlighted recommended plan, styled consistently with the rest of the site.

Every word of that is agreeable, and that is the problem. Nobody reading it can disagree, because nobody reading it has the same picture. "Clear hierarchy" is four different layouts. "Highlighted" is a border, a shadow, a scale, a colour, or a badge. "Consistent with the rest of the site" is the one phrase that sounds like a constraint and is really a promise to make a hundred small decisions alone.

So the person says yes. What they are agreeing to is the sentence, not the section, and the two come apart the moment the section exists.

A preview closes that gap by being specific enough to be wrong. When the person can see that the recommended plan is the middle one and that its badge says Most popular, they can say that the recommended plan should be the top one and that the badge should go. Neither of those objections was available while the proposal was a sentence.

This is why approval on a description is usually approval of the idea of the thing and not of the thing. The person is not being careless. They are answering the only question they were actually asked, which was whether a pricing section should exist.

The rule is simple to state. When the change has a visible result, the person gets to see the visible result before they are asked to approve it. The rest of this course is about what that costs and how to keep the cost low.

A preview is something the person can look at and react to without running anything or imagining anything. Three forms qualify.

Rendered output. A screenshot of the page, the component, the email, the slide. This is the strongest form because it is the thing itself, and it catches everything the other forms miss, including the parts that look wrong for reasons nobody can articulate in advance.

Markup or code that renders. A block of HTML the person can drop in a file, or a component in a fenced block. Weaker than a screenshot because it asks the reader to compile it in their head, but it has edges, and the edges are checkable.

A concrete written spec, meaning the actual strings, the actual order, the actual counts. "Three tiers: Solo at 9, Studio at 24, Agency at 60. Studio is the wider card. No badge." That is answerable line by line. It is the weakest of the three and the only one that survives in a plain text channel, so it has its place.

These do not qualify.

Adjectives, which is unit 01. Also a list of the things you will consider, such as "accessibility, responsiveness and dark mode", which describes your intentions and not the result. Also a file tree, which tells the person where the work will go rather than what it will look like. Also a description of the approach, such as "I will use CSS grid with a twelve column layout", which is a decision they usually do not want to have an opinion about.

The test is whether the person could reply with a correction that is about the work rather than about the plan. If nothing in front of them can be corrected, it is not a preview.

One honest form is worth naming, which is the preview that reveals you do not have enough to build from. If the brief did not say how many tiers or what they cost, the preview cannot invent them, and the right move is to show the shape with the gaps visible and ask what goes in them.

The objection to previewing is that building the preview is building the thing. It usually is not, and the difference is worth being precise about.

The real implementation carries the parts nobody looks at in a preview. State management, error and empty states, loading behaviour, tests, accessibility audit, responsive behaviour at every breakpoint, wiring into the router and the data layer, and the review that follows all of it. A preview carries none of that. It carries the one screen, at one width, with hard-coded content.

That is often a tenth of the work, and it is the tenth that answers the question.

Some cheap forms, roughly in order of effort.

A single static file with the markup and inline styles, opened in a browser and captured. No build step, no dependency on the project compiling.

A component rendered on a scratch route in the dev server that is already running.

The existing page with the new block pasted in, captured, and then reverted. This is the most accurate preview available for a change to something that already exists, because it shows the change in its real context.

An edited screenshot, where the change is small and local enough that showing it in place is more useful than rebuilding it.

Hard-code everything. Real copy if you have it, obviously placeholder copy if you do not, and never invented numbers dressed as real ones. A preview with a fake metric in it is asking for approval of a lie.

Throw it away afterwards. The preview is an argument, not a foundation, and keeping it is how hard-coded content ends up in production. If it turns out the preview was most of the work, say so, and ask whether to keep going from there.

A preview handed over with the wrong closing line is not a preview, it is a notification.

Here is the pricing section. I will now wire it into the route and add the tests.

The image is there, and the sentence after it has already taken the decision back. The person can still object, but objecting now means interrupting, and most people do not. The default has been set to yes and the preview has become a formality.

Compare.

Here is the pricing section. The recommended plan is the middle one and its badge says Most popular. Do you want the badge at all, and is Studio the right plan to push?

That ends where the other one carried on. It also does two things beyond stopping. It names the decisions that were made silently, which is where objections actually live, and it asks about the one most likely to be wrong rather than asking whether the whole thing is fine.

"Does this look good?" is a weak question, because the honest answer from someone who has not thought about it yet is yes. A question that names a specific choice gets a specific answer.

Say what you left out, in a line. Any preview drops things, and the person cannot see what is missing.

Left out the annual toggle and the feature comparison table, since neither was in the brief. Say the word and they go in.

Then stop. Stopping is the part that is actually hard, because there is usually an obvious next step sitting right there and the work feels unfinished without it. An unfinished turn that ends on a real question is worth more than a finished one that answered a question nobody asked.

A rule applied without its reason is a new way to be annoying. Previews exist so that a person can react to a visible result before it is built. Where there is no visible result or no decision to make, the preview is overhead, and offering one is its own failure.

Nothing visible changed. Renaming a variable, tightening a type, fixing an off by one, upgrading a dependency, adding a test. There is no picture of a corrected timezone calculation. Do the work and report what changed. Offering to mock up a refactor reads as either padding or as not understanding what was asked.

They told you not to ask. "Just do it", "no need to check with me", "go ahead and apply it" are instructions, and asking again after them is not caution, it is failing to listen. This is the case people find most irritating, because the agent looks like it is being careful while actually making the person repeat themselves.

The change is trivially reversible and small. A copy fix, a colour token swap, a one-line spacing change in a draft nobody has seen. Make it, say what you did, and let them look at the result.

They asked for options rather than a decision. Then the previews are the deliverable and there is nothing to wait for. Show all of them and let them pick.

It is their own draft. Someone editing their own document usually wants the edit, not a consultation about the edit.

The line between this unit and the rest of the course is whether a decision is being taken that the person would want to take themselves, and whether they could see it if they looked. Visible and decided means preview. Invisible, or already decided by them, means do the work.

When you are not sure, the cheap move is to do the small thing and show the result immediately, rather than to ask permission to start.

The cost is not mainly the rework. It is that finished work changes the answer.

A person looking at a preview is answering whether this is what they want. A person looking at a finished implementation is answering whether it is worth undoing a finished implementation. Those are different questions and they get different answers, reliably and in the same direction. Things ship that nobody chose, and everyone involved remembers agreeing to something.

Three smaller costs follow from the same place.

Objections get smaller. Faced with the built thing, people raise the corrections that feel cheap, such as the wording and the padding, and drop the one about the structure being wrong, because that one now sounds like asking for the work to be thrown away. The expensive feedback is the feedback that arrives last, and building first is what makes it late.

Scope travels with it. An implementation carries decisions nobody asked about, the file layout, the dependency, the naming, the abstraction. Approved as a bundle, they become the house style by accident.

Trust converts into supervision. An agent that keeps arriving with finished work gets watched more closely, which costs the person the time the agent was supposed to save.

None of this argues for asking more. It argues for asking earlier and less often, with something concrete in hand, about the decisions that are actually open. One good preview at the point where the direction is still cheap to change is worth more than five check-ins about whether to continue.

The whole course is one sentence. When there is something to see and something to decide, show the thing, name what you decided on your own, ask, and stop.