Design has a bill: why every feature has to earn its cost back
A feature costs designer, developer, and QA time — real money. Before you spend a week perfecting it, ask how long it takes to pay that back, and whether shipping rough first would get you there faster.
Siarhei Tarasenka
Product Designer
It’s easy to disappear into the craft. You open the file to design a feature, and eight hours later you’re nudging shadows, re-spacing a card grid, trying a third version of an empty state that maybe forty people will ever see. It feels like work — it is work — but somewhere in there a quiet fact got lost: design is a line item in a budget, and that budget expects a return.
Here’s the part designers rarely do out loud: the math.
The bill
Say a new feature takes a week of a designer’s time. Call it $1,000. Then a week of engineering to build it — another $1,000. Then testing, PM coordination, review, release — round it to $1,000 more. That’s roughly $3,000 on the table before a single user touches the thing.
Now the uncomfortable question, the one that should be asked before the polish and not after: how long does this feature take to earn that $3,000 back — and will it ever? If the feature lifts margin by $500 a month, it clears the bill in six months and everything after is profit. If it lifts nothing you can measure, the payback date is never, no matter how good it looked in the mockup. The design didn’t fail because it was ugly. It failed because it was an investment that never returned.
This is not an argument against spending money on design. It’s an argument for knowing what you’re spending it on. Three thousand dollars is a fine price for a feature that moves the business. It’s a terrible price for a beautifully rendered screen that doesn’t.
The perfection tax
The trap is sharper than “was this feature worth building.” It hides inside the build, in the gap between good enough and perfect.
Most of the metric-moving value of a design shows up early: the flow works, the hierarchy is clear, the friction is gone. The remaining polish — the custom illustration, the third pass on the animation curve, the pixel-hunt nobody but you will notice — is often the most expensive part of the week and the least likely to change a number. That last stretch toward “ideal” is a tax you pay in the currency the business cares about most: time, which is money, which is the payback clock ticking while you perfect an empty state.
Perfectionism feels like conscientiousness. On a spreadsheet it frequently reads as spending the customer’s expected return on details the customer can’t perceive.
Ship, then earn the polish
So here’s the move that saves the most money I know of: ship the version that’s good enough, get real metrics, and then invest polish where the data says it pays.
You cannot know in advance where beauty earns its keep. Maybe the onboarding screen is where extra craft lifts activation and the custom empty state does nothing — or maybe it’s the reverse. Guessing is how you spend the perfection tax evenly across everything, including the parts that would never reward it. Launching the acceptable version and reading the first metrics tells you where the money actually is, so the next week of design goes somewhere with a return instead of somewhere with a portfolio shot. A live product that’s merely good will teach you more in a week than a perfect prototype teaches you in a month, because only one of them is being measured by real users.
Ship it, watch the number, then make beautiful the thing the number says is worth making beautiful.
Where it breaks
This is a discipline, not a license to ship junk, and it fails in three predictable ways.
Some surfaces have to be right on day one. First impressions, trust moments, anything irreversible — payments, account setup, the screen a first-time user meets — don’t get a rough draft. Ship those sloppy and you burn the exact equity you were trying to build; there’s no “iterate later” on the trust a user only extends once. “MVP” is not a coupon for breaking the moments that matter most.
Rough is not the same as broken. There’s a quality floor below which you get no signal at all: users bounce for reasons that have nothing to do with your hypothesis, and now your metric is measuring your bugs instead of your idea. The goal isn’t the cheapest thing you can ship — it’s the smallest thing good enough to produce a number you can trust. Below that floor, “we shipped and measured” is just noise with a launch date.
Iteration has its own bill. Shipping rough and improving in passes isn’t free — every pass is more design, more dev, more QA. Sometimes three cheap rounds cost more than doing it properly once, especially when rework means tearing out what you already built. The ROI math only works if you count the cost of the rework, not just the cost of the first version.
The actual job
None of this makes craft less important. It makes craft accountable. A design is a bet with a price tag on it, and the professional move is to know the price, estimate the return, and refuse to pay for polish the number won’t reward.
Spend the week when the week pays back. Ship rough when rough gets you to the metric faster. And save your best, most expensive craft for the surfaces the data has already told you are worth it. That’s not settling for less design — it’s spending design where it earns.
Siarhei Tarasenka
Product Designer
Product designer, manager, and team lead with 18+ years of experience. Ex-principal designer of a top-charting AI assistant with 100M+ downloads. Creator of the Veritheme design system; IADAS member and judge at the Webby and Lovie Awards.
Follow