Every design proposal is priced the same way: research, wireframes, screens, a prototype, a design system, handoff files, and a number at the bottom. You need something concrete to approve and something to point at when you report progress. Fair enough.

What that list can’t show you is whether the decisions behind it were reasoned or improvised. At the moment you’re reviewing a file, both look the same: a well-considered screen and a lucky one are the same screen.

The difference shows up later, as cost: in how long your next release takes, and how much your team can change without calling anyone. So the real question at the start of a project isn’t what will we receive. It’s what will this cost us to change afterward and that’s decided before anyone opens a file.

The price of changing your mind

Take one small change: moving a step in a user flow. Not a redesign – just one step, moved. The cost of that change depends entirely on when you make it.

During research, it’s a conversation and nothing is built yet. In a prototype, it’s a few days. In the final design, it’s about a week, plus another round of review. In development, it’s a full sprint, because the step now lives in code, tests, and analytics. After release, it’s a migration, a comms plan, and support load, because by then the step also lives in user habits and other people’s integrations.

Same change. Five completely different price tags. This isn’t an argument against changing your mind – it’s an argument for where you do it. Early stages exist to be the cheapest room in the building to be wrong in. If your research didn’t change anything the team already believed, the questions were too safe to be useful.

The most valuable thing we produce is a shorter list

There’s a number that never shows up in any report: the cost of the features you didn’t build. No line item reads “saved eleven weeks by deciding in week two that nobody wanted this”.

That’s why cutting scope is a hard task: it looks like paying for less. But a feature costs money twice: once to build, and then forever, in QA, documentation, support tickets, and the limits it puts on everything you build next.

So in early-stage work, don’t look for comprehensiveness. Look for three things: an explicit list of what’s not being built and why, the single riskiest assumption in the plan named out loud, and one sentence describing what the first release has to prove. If none of those are there, you paid for a summary of your own brief.

Some decisions you only get to make once

Not every design decision is equally reversible. The difference comes down to one thing: how many people have to agree before you can change it.

A screen can change in a day: one team, no one outside the product involved. The visual language takes longer, because design, brand, and marketing all move together. Structural changes are harder still: every existing user has to unlearn a habit, and every integration built on the old shape has to be rebuilt by someone who isn’t on your team.

The hardest layer to change is the one nobody protects: the words themselves. Open your product and find the name for the main thing in it (a deal, a case, a shipment, a run). That word lives in your database, your API, your URLs, your support macros, and the integration your biggest customer built two years ago. It was usually chosen in week two, without a meeting.

“Some decisions are consequential and irreversible or nearly irreversible, one-way doors, and these decisions must be made methodically, carefully, slowly. But most decisions aren’t like that – they are changeable, reversible, they’re two-way doors.” – Jeff Bezos, founder of Amazon.

Ask your engineering lead what it would cost to rename that word everywhere. Whatever number comes back is the price of a decision nobody discussed.

Getting it right the first time isn’t complicated: start from the word users already use, not your internal one. Check it isn’t claimed elsewhere in your category. Write it down as a rule with a boundary (this word means exactly this, never that). If the choice is close, pick the plain option over the clever one.

A design is finished when it stops producing questions

There’s a version of finished that means the file looks complete, and a version that means it answers everything someone will need to ask.

Three questions tell you which one you have:

• What does this look like when there’s no data yet?
• What does it look like when the request fails?
• What does it look like when the text is three times longer?

If the answer is “we’ll figure that out in development,” the decision wasn’t skipped, it was handed off. Someone still has to decide what an empty state looks like, what an error should say, how far the layout can stretch. Now it’s an engineer, alone, working from a ticket instead of the reasoning that shaped the rest of the screen. The context that would have taken five minutes to share in a review takes a support thread to reconstruct months later, usually after a user already hit it. A review where nobody raises questions like these isn’t a sign of a clean design – it’s usually a sign that no one in the room thought to ask.

Time-to-market is the metric everyone sells. Nobody measures time-to-change.

Every agency competes on speed to launch, because it’s easy to measure and easy to compare. But almost no product is won at launch. It’s won by the team that can still move quickly two years later, when something happens nobody predicted at kickoff.

Here’s the trap: shipping fast by deciding well, and shipping fast by leaving decisions unmade, look exactly the same on release day.

On Isora, a governance and compliance platform we redesigned for SaltyCloud, deciding structure well upfront meant releases shipped 50% faster, and the team kept moving at 2x speed afterward, without renegotiating the model every time.

The difference shows up on the second and third feature. Each one asks the same questions: where does this sit in the navigation, what is this object called, what does an error look like here. In a product with reasoned structure, those already have answers. In one built on improvisation, every question reopens and the third feature costs more than the second, because now there are two inconsistent precedents to reconcile instead of one rule. The simplest tell: if your team is still debating button hierarchy on the seventh feature, nothing was ever settled.

Every team needs a way to end a design argument

Someone doesn’t like the blue. Someone wants the logo bigger. Someone thinks the flow should start somewhere else. There’s no way to argue against any of that, because taste has no evidence and in an argument without evidence, the most senior person in the room wins by default. Everyone knows this isn’t productive, but nobody has an alternative, so the meeting ends the way it was always going to end.

The most useful thing a design process leaves behind is that missing alternative: a principle with enough standing that a junior designer can point to it. When it exists, the argument changes shape. “I don’t like this” becomes “this competes with the primary action on the screen we’re measured on”, a claim that can be agreed with, disagreed with, or tested.

Most written principles can’t carry that weight, because they were written to sound reasonable, not to be used. The ones that work are specific enough to be wrong: “we optimize for the daily user over the first-time user” can be argued with. “We value clarity” never will be. And a good principle occasionally costs someone senior their preference. If it never does, it isn’t really a principle.

So, what do clients actually get?

Not a nicer file. A process like this leaves you with:

• The ability to tell when a mistake is still cheap to fix, and when it’s already load-bearing.
• A shorter build than you asked for, with a documented reason for everything left out.
• A structure where the reversible parts stay flexible, and the parts everyone depends on, starting with what things are called, get decided on purpose, not by accident.
• Screens that don’t quietly become an engineer’s problem the moment something wasn’t specified.
• A product that’s still fast to change on its twentieth feature, not just its first.
• A way to settle the next design argument without it coming down to who’s most senior in the room.

None of that shows up on a deliverables list. All of it shows up in what the next twelve months cost.

To wrap up

None of this shows up in the file you sign off on. It shows up later in what still has to change, and what that costs when it does.

At Phenomenon, we see this from both ends: early products, where the risk is locking in structure before anyone knows the real shape, and mature ones, where the risk is disturbing something thousands of people already rely on. The deliverables look nothing alike. What we’re trying to leave behind is the same: a product that’s cheap to change, and a team that knows why it’s built the way it is.

Deliverables are what you can see on the day. What you’re paying for is the price of every decision that comes after.