Designing Products With Cost in Mind

Last week, a founder I respect shared a screenshot of their AI infrastructure bill. It wasn’t outrage — it was disbelief. A single feature, lightly used but constantly running in the background, had quietly become their second-largest expense.

In another thread, someone was dissecting why most developers fail at SaaS. The advice was familiar: validate early, build the right MVP, don’t overbuild. And alongside that, a brutally honest guide on cutting API token costs by 80% was making the rounds.

Different conversations. Same undertone.

We’re rediscovering something product teams periodically forget: every design decision has an economic footprint. Not just for the business — but for the people using and maintaining the product.

As a product design lead, I’ve always cared about craft — alignment, spacing, interaction states, accessibility. But lately I’ve been thinking about another layer of craft that doesn’t show up in Figma files: how our design choices ripple into cost structures, team focus, and long-term viability.

And I think the community is starting to feel that too.

The Hidden Layer Beneath “Build the Right MVP”

“Most developers fail at SaaS because they build before they validate.”

We’ve heard it for years. But what’s different now is the cost of being wrong.

In 2019, building the wrong feature might cost you a few weeks of engineering time and some cloud hosting fees. In 2026, it might also mean:

Persistent AI inference costs
Third-party API usage that scales with every interaction
Data processing pipelines that run whether users show up or not
Ongoing model fine-tuning and monitoring

According to recent cloud reports, over 30% of startup infrastructure spend is tied to underutilized or misconfigured resources. That’s not just inefficiency — it’s design debt.

Because here’s the uncomfortable truth: many of those costs are locked in at the product definition stage.

When we design a feature that:

Requires real-time processing instead of batch
Defaults to “always on” instead of user-triggered
Calls an API multiple times instead of caching or summarizing
Prioritizes novelty over necessity

We’re not just shaping UX. We’re shaping the burn rate.

And yet, most design conversations still treat cost as an afterthought — something finance or engineering will "optimize later."

Cost is not just an operational concern. It’s a design constraint — and often, a design opportunity.

Token Optimization and the Return of Intentionality

The surge of “token optimization” guides is fascinating to me.

On the surface, they’re technical playbooks: reduce prompt size, cache responses, chunk data intelligently, avoid redundant calls. Smart, practical advice.

But beneath that is a deeper shift: we’re being forced to think about every interaction as something that consumes a finite resource.

There’s something almost healthy about that.

For years, digital product design operated in an environment of perceived abundance. Storage was cheap. Bandwidth was cheap. Compute kept getting cheaper. We could afford to layer on features, microservices, and real-time everything.

AI changes the equation. Every request has a measurable cost. Every conversation has a price tag.

And suddenly, questions that used to be philosophical are now financial:

Does this interaction truly need to happen in real time?
Does the user need a 2,000-word answer, or a 200-word one?
Should the system proactively generate content, or wait for intent?
Are we designing for delight, or for dependency?

I worked with a team last year building an AI-powered insights dashboard. Initially, every user action triggered a fresh model call. It felt magical. Instant analysis. Constant updates.

It was also wildly expensive.

We stepped back and redesigned the interaction model around intentional moments:

Users explicitly requested deeper analysis.
The system previewed lightweight summaries first.
Heavy computation happened in batches when it made sense.

The result? Infrastructure costs dropped by nearly 60%. But more importantly, the product felt calmer. More deliberate. Less noisy.

Constraint improved the experience.

That’s not a coincidence.

The Economics of Invisible Infrastructure

Another conversation circulating right now is about B2B fintech — the invisible infrastructure moving trillions behind the scenes.

It’s a good reminder: the most impactful products often don’t look flashy. They’re dependable, predictable, economically sound.

In my early career, I was drawn to highly visible consumer experiences — onboarding flows, growth loops, polished microinteractions. Over time, I’ve come to respect the quiet power of infrastructure products.

The design challenge is different:

Clarity over charisma
Stability over spectacle
Trust over novelty

And here’s what’s striking: in infrastructure-heavy products, cost and UX are inseparable.

A poorly designed dashboard in a fintech ops tool doesn’t just frustrate users. It leads to errors. Errors lead to manual work. Manual work increases operational cost. That cost gets passed on — to customers, to partners, to the system.

There’s a direct line from interface friction to financial friction.

Research from McKinsey has shown that companies with strong design practices outperform industry benchmarks by up to 32% in revenue growth. That’s often framed as “good design drives growth.”

But I’d phrase it differently:

Good design reduces unnecessary cost — cognitive, operational, and financial.

And in complex systems, that reduction compounds.

Leadership, Drift, and the Price of Ambiguity

One of the quieter threads in the community this week was about leadership and product clarity. When clarity isn’t a priority, teams drift.

Drift is expensive.

Not always immediately. But over time.

Ambiguity in product direction leads to:

Features built “just in case”
Redundant tools and workflows
Parallel experiments with no shared learning
Infrastructure layered on top of infrastructure

Each decision makes sense in isolation. Together, they create a system that’s harder to reason about — and more expensive to run.

I’ve seen this firsthand during a redesign of a mature SaaS platform. Over five years, the team had added AI suggestions, automation rules, analytics panels, integrations — each solving a real request.

But no one had stepped back to ask:

Which of these capabilities are core?
Which are rarely used but constantly maintained?
What are we paying — in complexity and compute — for marginal value?

When we audited usage data, we found that nearly 40% of advanced features were used by fewer than 5% of accounts. Yet they accounted for a disproportionate share of engineering maintenance and backend processing.

The design work wasn’t about making things prettier. It was about making choices.

We deprecated features. Consolidated workflows. Reduced background jobs. Clarified the primary user journey.

Churn didn’t spike. In fact, activation improved — because the product became easier to understand.

Simplicity reduced cost and increased clarity at the same time.

The Slow Death of the Power User — or a Shift in Who We Design For?

There’s a narrative emerging about the “slow death of the power user.” As AI automates more workflows, the argument goes, we’re designing for casual users while experts lose control.

I’m not sure that’s entirely true.

What I think is happening is more subtle: the economics of complexity are being exposed.

Power-user features often:

Require deeper configuration layers
Increase system state complexity
Demand extensive documentation and support
Trigger edge cases that are costly to maintain

That doesn’t mean we abandon expert users. It means we need to be more intentional about the value exchange.

When I design advanced functionality now, I ask three questions:

Who is this truly for?
What measurable value does it create for them?
Is that value proportionate to the long-term cost of supporting it?

If we can’t answer those clearly, we’re not being bold. We’re being careless.

Designing With the Bill in Mind

None of this is an argument for austerity.

Delight matters. Ambition matters. Experimentation absolutely matters.

But I’m increasingly convinced that mature product design includes financial empathy — understanding that:

Every real-time animation uses resources.
Every background process consumes compute.
Every new feature creates long-term maintenance obligations.
Every added layer of complexity shapes team focus.

In my own practice, this has changed how I run early discovery workshops.

Alongside user journeys and pain points, we map:

Ongoing operational costs
Third-party dependencies
Maintenance surface area
Potential failure points

Not to constrain creativity — but to sharpen it.

Because when teams see the full picture, design conversations get more honest.

We stop asking, “Can we build this?”

And start asking, “Should this exist — at this scale, in this way?”

That question feels heavier. But it’s also more responsible.

The Craft Beneath the Interface

I still care deeply about typography. About motion curves. About accessible color contrast ratios. Those details shape how a product feels.

But there’s another layer of craft that’s becoming just as important: architecting experiences that are economically coherent.

Not bloated. Not fragile. Not dependent on infinite resources.

When I look at the conversations unfolding right now — about failing SaaS products, ballooning API costs, invisible infrastructure, leadership drift — I don’t see panic.

I see recalibration.

We’re being reminded that great products aren’t just usable or innovative.

They’re sustainable.

And sustainability isn’t a marketing slogan. It’s the quiet alignment between:

What users truly need
What teams can realistically support
What the business can afford to sustain

That alignment doesn’t happen by accident.

It’s designed.

And sometimes, it starts with something as simple — and as sobering — as looking at the bill and asking what story our product decisions are telling.

Not just about growth.

But about care.