Payment of ₹ requested by HONEY VIG. Click the link to pay securely via Razorpay: Make 5000 payment Payment of ₹ requested by HONEY VIG. Click the link to pay securely via Razorpay: Make 5000 payment ⭐ If you would like to buy me a coffee, well thank you very much that is mega kind! : https://www.buymeacoffee.com/honeyvig
Hire a web Developer and Designer to upgrade and boost your online presence with cutting edge Technologies

Wednesday, September 30, 2026

Botnado Is Coming for Your Platform

 

Matt Dunphy, a Lead Solutions Engineer at commercetools, posted a story on LinkedIn that reminded me that Reddit has been a dumping ground for ChatGPT content and is turning into a spam ground for everything, and he inspired this Botnado edition of my newsletter, or maybe the approaching Boticane, or maybe we are in the eye of the storm. (Note to self: explain to the readers the movie Sharknado)

The story he posted, a team "currently paused on a commercetools implementation as the complexity came in higher than scoped," reads as if a merchant halfway through a commercetools build were asking strangers what to do next, and Dunphy says the story is fiction. I have not seen the thread, so I am leaving the question of who wrote the story to him.

I spent four days writing, rewriting, analyzing, and scrutinizing this issue. I removed 95% of the Claude content and left the analysis. (I am fully transparent in the article and you can skip the Claude shit if you want)

A bot that posts on Reddit does not deserve the credit ChatGPT gives it, and the evidence is below.

Why Reddit Threads Land in AI Answers About Platforms

Note to the reader: This is lots of research done by Claude. I wouldn't blame you if you just skipped this section.

In the next section, Claude will tell you a ton of stats and lots of bloated info that you may or may not want to read about ChatGPT and Reddit. I have so many sources to reference at the end, it is quite impressive. I will bold the sections I wrote. You can read the bold bits and get most of this section.

Take it away Claude! yippeee

Reddit is one of the sources AI engines cite most. Profound, an AI visibility company, counted 680 million citations between August 2024 and June 2025 and found Reddit at 21.0 percent of Google AI Overviews' top ten sources, 11.3 percent of ChatGPT's, and 46.7 percent of Perplexity's.

Semrush watched ChatGPT cite Reddit in about 60 percent of prompt responses in early August 2025 and about 10 percent by mid-September, which tells you the engines are still deciding how much weight a thread deserves.

People who watch Reddit know what is coming. MediaPost reported in July that AI-generated fake posts are being written to land in ChatGPT and Google AI results, and MediaPost cited Reddit's own figures of 23 million spam views blocked per day and nearly 2 million inauthentic votes revoked per day.

Researchers at the University of Zurich posted more than 1,700 AI-written comments under invented personas to a Reddit forum in 2025, and Reddit's chief legal officer called the experiment "deeply wrong on both a moral and legal level." That was a university experiment with no vendor involved, and I cite the experiment because AI-written posts under invented personas on Reddit are not hypothetical.

Planted text does not need to be large to matter. Anthropic, the UK AI Security Institute, and the Alan Turing Institute found that 250 malicious documents were enough to backdoor language models from 600 million to 13 billion parameters, which is 0.00016 percent of the training tokens, and the researchers say it is unclear whether the result holds for behaviors more complex than the gibberish they tested.

That study covers training data, which differs from the live retrieval an AI does when you ask about platforms, so it shows how little planted text can move a model and stops short of explaining any one thread.

AI slop is producing reviews, updates, and messages about all sorts of platforms all over the internet, especially on Reddit.

Now back to our regularly scheduled program

What I Tell People to Do About It

I would encourage people to filter down and do the research you need to do. If you see someone saying I was about to close on platform X, and I decided on Y then do your due diligence.

I also believe that the AI Slop-Shit that is happening, especially on Reddit, is going to get downgraded. It has to for our own sanity.

Until the Reddit slop gets downgraded, here are ten questions to ask your SI, the system integrator who will build the store, and this list is not comprehensive, only a place to start.

I wrote the questions for the SI and not for the platform because the platform answers most of what you need in public, in its documentation, its release notes, and its customer list, while the SI holds the answers that only come out in a conversation, who will do the work, what the work costs, who carries the overrun, and what happens when the scope changes, and the story that started this issue was a build paused because the complexity came in higher than scoped.

  1. Which projects like mine have you delivered on this platform, and will the clients take a reference call?
  2. Who will work on my project, at what seniority, and how long has each person worked on this platform?
  3. Is the pricing outcome based or time and materials, and who carries the overrun if complexity comes in higher than scoped?
  4. Which parts of the build come out of the box, and which parts are custom code I will maintain?
  5. Which features in the plan are generally available, and which does the vendor's own documentation call beta or experimental?
  6. What does year two cost, including maintenance, upgrades, and licenses?
  7. Which other platforms in my vertical did you consider for me, and why did you rule out the other platforms?
  8. How do you handle change management when the scope changes, including who approves the change and how the change is priced?
  9. Who owns the code, the data, and the accounts when the project ends, and how does my data get used if the platform is SaaS?
  10. Can I run a proof of concept on my own catalog and one checkout path before I sign?

Footnote. Claude helped me come up with these ten questions, and I encourage you to comment with better questions.

You don't want to check just one platform. You want to check other platforms that are in the same vertical as the platform you are interested in. For example, if it's commercetools, you want to look at other headless, API-first platforms that make sense for you to consider. There will always be four to five platforms that fit your vertical.

Examples of Checking Your Platform

I did the slow version on two platforms I like. On the Shopware side, the press release promised "100% MCP coverage," while the developer docs say the MCP server is experimental and still in beta. A merchant reading only the press release would come away with a different picture than a merchant reading the docs. The open issues tell a good story too. A bug that broke the extension's install was fixed within two days, with an apology.

On the commercetools side, the MosAIc page describes a preview and asks visitors to express interest, and the AI Hub page lists customer logos without saying which of them run on agentic channels. Which of those customers run on agentic channels is a question for a reference call, and a fake thread has no reference to call.

The list of platforms is much larger, but I chose these five, and I think all five are winners, commercetools, Shopware, SCAYLE, BigCommerce, and of course the elephant in the room, Shopify. A thread that nobody can trace to a person helps none of them. (I don't believe Shopify is the best solution for B2B, but I'd love to hear why others think it is.)

Three of these platforms, commercetools, Shopware, and SCAYLE, are German, and SCAYLE is just getting its footing in the US. Shopware is primarily B2B. So I have a question for you, are these Reddit posts geared to the German market?

Platforms I Have Already Written About

I chose Shopware and SCAYLE because Dunphy's post mentioned them, and I added BigCommerce and Shopify because I wanted a few more. I can only name a few platforms in one issue, and I apologize to the ones I leave out. Here are a few I have already written about, so you have my research to start from.

To restate my premise, when an AI names a platform to buy, what do you check before you trust the answer? Do you look at the citations? Or do you read what people are saying on Reddit?

Claude did the research and drafted the first pass of this issue, and I edited before anything went out. Shopware presented issue 63 of this newsletter and has no part in this issue.

More than 95 percent of this issue is in my words, and the remaining 4 percent is sourced facts and links. Claude gathered the Reddit research, and I left the Reddit section as written.

SOURCES

Posted by H at 5:07 AM 0 comments
Labels:

How GPU Prices Can Double While AI Gets Cheaper

 

GPU prices have doubled in the last six months, from $4.40 to $8.08 per GPU-hour. But AI prices are falling. How can that be?

Article content

It is not a simple answer. Higher GPU costs are likely to remain while the industry races to build out new data centers. Every component of the buildout is increasing in cost, from concrete to copper to credit.1 Above all, electricity remains the limiting factor, which Oracle is experiencing : last week it invoked force majeure on its New Mexico campus after the natural-gas pipeline feeding it slipped by six months.2

Demand continues to explode. Inference companies & model companies are posting record-setting growth, which emboldens investors to value them more richly, provide them more capital, & up the bidding on those limited GPU-hours, to generate more revenue. The flywheel spins.

Meanwhile, AI efficiency is improving just as rapidly. Claude Opus 5.5 costs 40% less to run than the previous model.3 OpenAI cut Luna 80% in July, then another 50% in September, presumably powered by margin innovation.4 The same benchmark threshold that cost $0.55 eighteen months ago now clears for $0.0015, a 377x reduction.5

But capital is more expensive. As rates have risen, the relationship that governed tech multiples has come undone. The 10-year Treasury has been the strongest historical predictor of tech valuations : higher rates, lower multiples. Over the full history the correlation runs −0.50. Over the last two years it has flipped to +0.39.6 Rates climbed from 3.63% to 5.18% while the NASDAQ rose roughly 78%. The market is no longer repricing tech on the cost of money. It is betting the growth math works out.

Article content

Today, the capital markets are fueling this torrid growth, betting the math works out positively. The metric that will ultimately matter is gross profit dollars per GPU-hour.7 As GPU costs increase, are efficiency gains outpacing them? Microsoft says it generates 90% more tokens per GPU year over year, concentrated in its smaller models.8 If that pace continues, the two curves are at least running neck & neck.

So for now, the industry seems to be holding both forces in balance.

Posted by H at 2:53 AM 0 comments
Labels: , ,

Monday, September 28, 2026

Find the Missing Approval Behind a Stalled B2B Quote

 

When a quote goes quiet, a price cut is a costly way to guess what went wrong.

The buyer may still want the product. But the person who asked for the quote may be waiting for someone else to approve the spend, accept the risk or confirm the installation plan.

My view: before changing the price of a stalled B2B quote, find the unresolved decision. Then help the buying group work from one shared set of facts.

Price may be the real barrier. Establish that before giving away margin.

Interest does not settle approval

A buying group is simply the people who help decide whether a company should buy. Their jobs can give them different reasons to support, delay or reject the same order.

Gartner’s 7 May 2025 research release describes a survey of 632 B2B buyers, conducted in August and September 2024. It identifies conflicting goals and disagreement over the next step as sources of buying-team conflict. It also argues for information that helps the group understand shared goals, rather than reinforcing each person’s separate position. Gartner’s original research release.

This is older evidence, not this week’s news. The public release does not disclose respondent geography or enough method detail to treat it as an Indian SME benchmark.

My takeaway is narrower: a positive reply from one contact does not establish that the remaining approvals are in place.

Picture a compressor quote

Consider a hypothetical industrial supplier quoting an air compressor to a factory. This is an illustration, not a client result.

The plant engineer is satisfied that the proposed model meets the stated pressure and air-volume needs. Sales marks the quote as promising.

Then the order stops moving.

Maintenance wants to know who will handle a breakdown and whether key spares are available. Finance needs the installed cost and the assumptions behind running-cost estimates. Procurement needs clear delivery, payment and warranty terms. The plant head needs an installation window that will not disrupt production.

A lower equipment price might help finance. It will not, by itself, answer the maintenance or shutdown questions.

Sending four separate sales pitches could also leave the group comparing different promises. The engineer may hear about performance, while finance hears about savings with conditions the engineer has never reviewed.

The shared decision should be clearer: can this option meet the factory’s stated needs within an agreed cost and installation plan?

Marketing’s role here is to make the evidence easy to use. Sales should not have to assemble a new argument from scattered brochures, emails and verbal promises.

Replace the reminder with a decision note

For the next suitable stalled quote, ask the account owner to prepare a one-page decision note with the buyer’s main contact.

Start with a simple question: “What still needs to be checked internally before you can decide?”

Then record four things:

  • The shared goal: the business problem the purchase must solve.
  • The open decisions: technical fit, service, cost, timing or terms, as relevant.
  • The evidence needed: the document, test, calculation or confirmation that could resolve each question.
  • The next step: who will check it and the agreed review date.

Ask which roles need to review the note. One person may cover several roles in a small company. Do not force a large-company committee onto every order.

Keep unknowns visible. “Service response time to be confirmed” is more useful than a promise nobody has approved.

The note should make it easier to compare the offer with alternatives, including postponing the purchase. It is a decision aid, not a device for hiding objections.

Give each part an owner

The account owner confirms the buying process and keeps the next step current.

Marketing turns existing, approved evidence into a short document the buyer can forward without needing a salesperson to explain every page.

A technical or service owner checks specifications, exclusions and delivery or support claims. The commercial owner approves price, payment and warranty terms.

Use the existing customer record or a simple shared document. No new software is required for this test.

Ask the main contact how other reviewers should be involved. Going around that person to contact colleagues can damage trust. Sometimes the right approach is a joint call; sometimes it is a document they share internally.

Measure a resolved question, not another email

Try the note on five suitable stalled quotes from one product line. Five is a manageable starting point, not a statistically meaningful sample.

Choose them before the test and record their current stage, age and known blocker. Review the same five after two weeks.

Count how many have:

  • A buyer-confirmed unresolved decision.
  • An agreed evidence requirement and responsible reviewer.
  • A buyer-confirmed next step, a clear pause or an explicit rejection.

Also record time spent preparing the note. If it takes hours of repeated custom work, the process needs simplifying.

Do not count an email open as approval. Do not call every newly identified stakeholder progress. The useful change is less uncertainty about the decision.

Two weeks can test whether the process improves clarity. It cannot prove higher revenue or a shorter sales cycle. Track eventual orders and margin separately, comparing quotes at similar ages and acknowledging differences between buyers.

Know when this adds work

A routine reorder may need no decision note. An owner-led business may have one genuine approver. A tender may already specify the required evidence and communication route.

And a buyer may simply lack budget, prefer another supplier or have no reason to act now. More documents will not fix that.

The aim is to find the barrier, including a commercial one, without assuming that silence means price resistance.

Before the next discount request, ask your team to name the decision still waiting for approval. If they cannot, use one shared note to find it.

Whose unresolved question is holding up your next order?

Posted by H at 7:18 AM 0 comments
Labels: ,

Sunday, September 20, 2026

Stop Treating CSS Container Queries Like Traditional Media Queries

 

Despite broad browser support, container queries remain surprisingly underused and frequently misunderstood. Let’s look at how they differ from media queries, when to reach for each, and how container queries help reusable components respond naturally to the contexts in which they appear.

To be completely honest with you, I missed the news when CSS Container Queries first shipped. And when I finally heard about it, my very first thought was, “Why exactly do I need this when media queries already exist?”

I’m not proud of that reaction, knowing what I know now, but it was comforting to know that I wasn’t alone. In fact, there are legions of us out there.

What baffles me is that container queries aren’t a new feature, as it currently sits at around 94% browser support. And yet, very few people are actually using it. According to the State of CSS survey, 86% of developers are aware of container queries, but only 41.4% actually use them. Surveys can be biased and not completely representative of our entire field, but this one is certainly the best indicator we’ve got.

Kevin Powell also talked about this at SmashingConf Amsterdam 2026: Container Queries adoption has been terrible. And that is so strange to me, knowing that the ability for components to adapt to the size of their outer container has been at the top of so many CSS wishlists over the years.

I’m not particularly interested in how many people are using container queries as much as in how they are using them. I can’t account for everyone, but from what I’ve seen — including in my own early attempts — many of us are using them wrong.

The bottom line is that incorrect use comes down to the same impression I had when learning about them: they absolutely look just like media queries at first glance. And since they look similar, it’s easy to assume they serve similar purposes and work the same way.

They don’t.

Note: I should state up front that what I’m focusing on in this article is using container size queries, i.e., a responsive design technique for responding to the size of a particular container. There are also container style queries that respond to a container’s computed styles (and are experimental at the time of this writing). You can catch up on those in Juan Diego’s piece here on Smashing Magazine where he examines their possible use cases

Media Queries Look Outward #

The viewport is a proxy. It always has been. Media queries are what gave us the illusion that screen width alone is responsible for how responsive apps adapt to their environment.

Ask yourself this: When you write @media, what are you asking the browser?

@media (min-width: 1024px) {
  .card {
    display: flex;
  }

I, like most developers, am asking the browser: How wide is the screen right now? That’s it.

Media queries answer that beautifully, but what happens when this .card component is placed in a grid cell that’s 300px wide on a 1920px desktop screen?

The media query doesn’t care; it does its job. The viewport is still 1920px, so min-width: 1024px fires and the matched query styles are applied, even though the card only has 300px of space to work with. Eventually, everything in the card deforms, overflows, or cramps up.

“Media queries are dumb. Not dumb in terms of the concept, but dumb in that they don’t know very much. In fact, most people assume that they know more than they do.”

— Kevin Powell

It’s common to think of responsive design purely as a system for updating complete page layouts, like going from two columns on a large screen to a single column on a small screen.

Container Queries Look Inward #

Container queries are smarter than that. They make responsive layouts more reliant on what’s happening inside a component rather than on the outer context that has no insight into a component’s contents. It is more like: “How much space is available for me in this specific spot, right now?”

Here is the same card code example we looked at in the last section, but with a container query:

.card-wrapper {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 450px) {
  .card {
    display: flex;
    flex-direction: row;
  }
}

This changes everything. The card isn’t influenced by the viewport; its only concern is whether the .card component’s parent wrapper has at least 450px of inline (i.e., horizontal in a left-to-right writing mode) space. If that condition is true, the component goes horizontal; if not, it goes to its default block display.

See the Pen Viewport vs Container 

“Macro” Layout Vs. “Micro” Layouts #

A very interesting way to distinguish @media and @container queries is the layout type.

Media queries are for the “macro” layout; they look outward. Stuff like page structure, the header that spans the window, footers, main grid layout, system preferences (prefers-color-scheme), device capabilities (touch screens). You know, anything that is majorly true to the entire page structure.

Container queries, I’d say, are for “micro” layouts, i.e., most things that live inside the “macro” layout. We use them when any content needs to responsively fit whatever space it is allocated. Components that come to mind are things like cards, widgets, forms, navigation, and so on.

In other words, think “page layout” vs. “component layout”.

An element shouldn’t magically become “tablet-sized” just because the width exceeds an abstract width threshold like 768px. Instead, it should switch layout when it has enough space to do so, whether that happens on a mobile viewport or inside a desktop sidebar.

In case you’re still not convinced, did you know there are over 2,300 unique viewport sizes on the modern web? Do you think it is possible to account for all of them?

I’m not hating on media queries. It’s that in this era of responsiveness and component re-use, layout logic is closer to the container than the viewport. When we think in terms of containers and components, we’re effectively relying on the content to determine layout, not the viewport.

“

This is how it should be.

Example: Fluid Typography Inside A Component #

Responsive typography is a good example of something many of us have relied on media queries for. The fact that media queries come with their own CSS units — e.g., vw, vh, and so on — that are relative to the viewport size makes media queries look really good for adjusting font size based on the user’s screen size.

.card-title {
  font-size: clamp(100%, 1rem + 2vw, 24px);
}

This works until that same component is moved into a different context, like a sidebar, where the viewport is completely irrelevant. Now, because we tied the responsiveness to the wrong reference point, the scaled typography can get too big or too small.

Container queries come with their very own units — cqi, cqw, cqb, among others — and we can take responsive components further by coupling those units with the CSS clamp() function, using it for fluid typography that scales with the component rather than the viewport:


.card-title {
  font-size: clamp(1rem, .5rem + 3cqi, 2rem);
}
See the Pen Fluid Typography [forked] by Vayo.

With this in place, the entire code is self-contained to that element’s specific container.

Example: Flexbox Wrap Detection #

Interestingly, container queries can, in a way, detect the state of a component’s internal layout. It’s not bulletproof, but it is also something media queries simply cannot do because they only observe the external browser window and are structurally blind to internal layout events like when, for example, flex items wrap onto a new line. Let’s poke at that.

Flexbox is superb at wrapping content (flex-wrap: wrap), allowing flex items to automatically wrap to new lines when the flex container runs out of space to fit them in a single row. But CSS by itself can’t tell when that wrap happens. There isn’t something like a :wrapped pseudo-class or a media query like @media (flex-wrapped: true) that would get us there.

Media queries only observe the browser window, as they can’t see internal changes. That is pretty much what flex wrapping is: a width state change on the item itself.

For example, if you have a horizontal menu that is lined up with flexbox and you want the items to restyle themselves only when wrapped, you’d be in JavaScript territory, using ResizeObserver to get that information. However, when we nest container queries inside flex items, we can come up with a workaround to get what we need without JavaScript, thanks to this technique I learned from Kevin Powell. The core idea is to allow a flex item to flex-grow: 1 when we query the container’s inline size.

See the Pen Fluid Typography [forked] by Vayo.
Normal and wrapped states of two responsive items.
(Large preview)

The logic works like this:

  1. When there’s enough room, both items (.flex-item) sit side-by-side, each exactly half the parent container’s width.
  2. When there is limited space, the second item wraps to the next line.
  3. Because flex-grow is active on each item, the wrapped items stretch to fill most of the parent’s width.
  4. If the item is a container itself, it detects the sudden width expansion and fires.
/* The flex parent */
.flex-layout {
  display: flex;
  flex-wrap: wrap;
}

/* Register a flex item as a container */
.flex-item {
  container-type: inline-size;
  flex: 1 1 390px; /* Grow to fill space, wrap at 390px */
}

/* Default Card Styles (narrow / side-by-side) */
.card {
  display: flex;
  flex-direction: column;
  background: #f4f4f4;
}

/* Once there's enough room for a full row */
@container (min-width: 600px) {
  .card {
    flex-direction: row;
    align-items: center;
    background: #e2f0d9;
  }
}

This works. As the parent size shrinks and the cards wrap to two lines, the card item expands, the container query fires, and applies the necessary styles.

See the Pen Flex Wrap Detection Using Container Queries [forked] by Vayo.

Container Queries Do Have Side Effects #

Container queries, like all things, come with some side effects or caveats you will want to watch for before reaching for them.

1. A Container Requires An Extra Wrapper #

Container queries need something similar to a parent-child relationship to function as expected. Let’s say we have this markup:

<div class="card">
  <div class="card-content">...</div>
</div>

We can’t actually query the .card component to adjust the .card-content, like this:

/* DOES NOT WORK */
.card {
  container-name: card;
  container-type: inline-size;
}

@container card (min-width: 400px) {
  .card {
    display: flex;
  }
}

This doesn’t work because a container cannot query itself. In that last example, we’re querying a card container and then attempting to adjust that container’s display based on its size. It’s an infinite loop.

Instead, we need an additional wrapper that makes the .card a descendant of the container:

<div class="cards">
  <div class="card">
    <div class="card-content">...</div>
  </div>
</div>

From there, we can query the .cards container and adjust the .card layout accordingly:

.cards {
  container-name: cards;
  container-type: inline-size;
}

@container cards (min-width: 400px) {
  .card {
    display: flex;
  }
}

In media queries, this doesn’t matter as @media does not care which element you style inside the block; its only concern is the viewport, which is always available. So you can just slap a condition on any element and call it a day.

2. Querying A Container’s size Could Collapse Your Layout #

This happens when querying the container’s size (i.e., its block, or vertical, size) instead of its inline-size:

/* Collapses to 0px even if it has content inside */
.hero-banner {
  container-type: size;
}

Why? Because the browser calculates the container’s dimensions without looking at its children. If we don’t give the .hero-banner an explicit height (or min-height or aspect-ratio), the browser sets a height of 0px.

For that reason, it’s often better to query a container by its inline-size instead. That is, unless you genuinely need to query the container’s block size.

Media queries aren’t affected by this, as they treat height the same way they treat @media (min-height: ...) does, i.e., ask the viewport and move on.

3. Queries Cannot Accept Custom Properties #

Another container query limitation: we can’t query against a custom property value:

:root {
  --breakpoint-lg: 1600px;
}

/* DOES NOT WORK */
@container (min-width: var(--breakpoint-lg)) {
  /* ... */
}

This is because custom properties depend on values that cascade down the DOM tree. There’s the possibility that a container query that relies on a custom property can change that same custom property. And it can quickly get complicated:

:root {
  --breakpoint-lg: 1600px;
}

/* DOES NOT WORK */
@container cards (min-width: var(--breakpoint-lg)) {
  .card {
    --breakpoint-lg: 1000px;
  }
}

When To Reach For Media And Container Queries #

I don’t think any project should wholesale use @container instead of @media. Media queries still play an important role in responsive layouts. It’s about understanding the separation of concerns.

I tend to reach for container queries when a component is used in more than one layout context. For example, a .card element could live in a full-width grid or a narrower sidebar. If that’s the case, then we’ll want the component’s content to determine when it adjusts rather than a media query that looks at the outer viewport.

Similarly, I reach for media queries when a component solely exists at the page level. This would be something like a main navigation that always sits at the top of the page. It is directly influenced by the viewport’s size, meaning that the viewport is a reliable reference for when the navigation needs to adjust. Again, it’s all about “macro” layout versus “micro” layouts.

Here’s a diagram for how I reason about which type of query to use:

Flowchart for choosing between media and container queries
(Large preview)

Conclusion #

At the end of the day, the core reason why container queries look incredibly similar to media queries is simply familiarity. They’re not exactly “new”, but they are way less understood and adopted than media queries. But media queries have plenty of their own limitations; otherwise, we wouldn’t need container queries to fill those gaps.

What we have is a more effective feature for detecting when a specific component’s context changes and a means for adjusting styles based on its content, as it should be when that component can exist in multiple contexts.

 
Posted by H at 7:38 AM 0 comments
Labels: , , ,

Saturday, September 19, 2026

Building A UX ROI Case That Survives The Boardroom

 

Strong UX ideas do not secure investment on their own. Through a worked example,  breaks down how to define business value, calculate costs, test causality, and build a credible case for the return on a design initiative.

Sooner or later, a CFO looks at your wireframes and asks what any of it actually does for the bottom line. Storyboards don’t answer that question, and the era when a 5-minute pitch could answer it ended, unfortunately, a while ago.

These days, if you want to win budget, buy-in, and backing for UX, the design has to be provably good for the business, not only for the people using it.

And proving that takes more than taping a dollar sign to a redesign. You have to understand how your organization defines value in the first place, how it measures that value, and how a credible line gets drawn between a design initiative and an outcome leadership already cares about.

Rather than scatter tips, this article follows one worked example the whole way through. Meridian is a mid-size B2B SaaS company, and it is entirely made up — that label matters, so it gets repeated where it counts. Its onboarding redesign carries the same figures from goal-setting through cost accounting, causal testing, and the final ROI number, because a framework only becomes tangible when the numbers connect. Every step is one you can rerun inside your own organization.

Why ROI Matters More Than Ever in UX Conversations 

Companies now want clarity on what every dollar buys, and “delightful user experiences” stopped clearing that bar some time ago. I still remember a former colleague celebrating a $1 million redesign he’d gotten greenlit mostly on the strength of a couple of three.js tricks. Try that pitch in front of a finance team today and see how far the particles get you.

Executives don’t hate UX, they just hate vagueness. A pitch built on “users will find it easier” loses, every time, to the department promising 12% more sales in Q3. The difference is the one between a streamlined checkout flow that reduced cart abandonment with completed purchases up 22%, and the same work rewarded with “the QA testers like it.” One of those goes on your resume. The rest of this article is about earning the first version, with Meridian’s numbers doing the work.

 

When Business Goals And KPIs Don’t Exist Yet

Most writing about UX ROI makes a convenient assumption: that the organization already owns clean business goals and KPIs for you to hook your work onto. Real companies are messier than that. Plenty run on ambitions like “grow faster” or “improve the customer journey” that nobody ever broke into anything measurable, and an ROI case built on that ambiguity sounds impressive right up until somebody scrutinizes it.

So the first job is often to help the organization define what success even looks like. Interview stakeholders across departments — what does product consider a good quarter, where does customer success watch users struggle, where do sales deals stall — and listen for the themes that keep resurfacing across conversations, because those recurring themes are the company’s latent business objectives. A useful forcing function is the OKR model (Objectives and Key Results), which doesn’t tolerate vagueness.

At Meridian, the stated ambition was “improve the rate of new users’ adoption of the platform,” which you can neither design toward nor measure against. Interviews turned up the real shape of the problem. Trial users needed a median of 14 days to reach first value, most churned before getting there, and onboarding questions were burying the support queue. Out of that came an OKR with actual edges: reduce median time-to-first-value from 14 days to 7 with the use of a guided setup flow, and lift trial-to-paid conversion from 8% to 9.5%.

One warning about formalizing KPIs: Impose them from inside the UX team and leadership will suspect you’ve rigged the field in your own favor, so co-create them with whoever owns the outcome — though never at the price of accepting targets that set your team up for an uncomfortable situation. Meridian’s head of product agreed that setup-completion rate was a fair proxy for onboarding usability, and customer success signed off on time-to-first-value, a number already sitting on their own dashboard.

A KPI ladder that ends at a metric somebody already watches buys you credibility before any design work starts.

Quantifying The Full Cost Of The Investment

ROI has a denominator, and the denominator is where most UX teams go wrong. You can’t calculate a return without strategic financial planning, yet cost usually gets counted as designer salaries or consulting hours and nothing else. A finance team will find the rest whether or not you counted it, so count it first.

Direct costs are the visible ones. Meridian’s redesign ran $45,000 in design and research labor plus another $8,000 in tooling and participant incentives. Licenses for Figma, UserTesting, Hotjar, analytics platforms, research incentive spend — all of it belongs in the total, and that’s before the inevitable instances of vendor lock-in every UX team eventually faces. Engineering sits in the same column, because a UX redesign doesn’t stop at the mockup. Building the guided setup took two frontend sprints plus a QA pass, $38,000 worth, and the project generated about $4,000 of coordination overhead along the way in new syncs and shared dashboards.

The line item nearly everyone misses, and the one worth stealing from this article if you steal nothing else, is stakeholder time. Workshops, design reviews, and feedback sessions all pull senior people away from their primary work. A VP of Product spending four hours a week in UX reviews is a VP not spending those hours on roadmap planning or partner negotiations. Log the attendance — who came, for how long, at what seniority — and price it at fully loaded cost, meaning salary plus benefits divided by productive hours. A quarter’s worth of workshops, reviews, and interviews at Meridian priced out at $22,000.

Add it all up: $45,000 in design labor, $8,000 in tooling, $38,000 in engineering, $22,000 in stakeholder time, $4,000 in coordination. The investment is $117,000. Saying that number out loud beats saying “we spent $45K on design,” precisely because it already includes everything a finance team would have dug up on its own.

Proving Causation, Not Just Correlation

Most UX ROI pitches die right here. Conversions rose after the redesign, sure — and the CFO wants to know how you ruled out the new pricing, the seasonal traffic bump, and the marketing campaign that shipped the same week. Without a convincing answer, your entire ROI story crumbles.

After all these years, the gold standard for proving causation is still A/B testing: run the old experience against the new one on an even traffic split until the sample means something.

Onboarding happens to suit a phased rollout, which is why Meridian could do this cleanly. For eight weeks, half of new trial signups received the redesigned guided setup while half stayed on the legacy flow. Control converted to paid at 8.0%. The variant came in at 9.4%. With roughly 6,100 trials inside the window, the difference was statistically significant, but a 1.4-point gap on a single test is still the kind of result that deserves a second look before anyone builds a budget on it, which is one reason the team held back on attribution below. Where a split isn’t feasible — a change too structural, a user base too small — fall back to a time series instead. Measure steadily for weeks before the change, implement, then keep measuring against the baseline you established.

Documenting whatever else happens around the same time as your UX change is the unglamorous half of causation.

A pricing-page test from Meridian’s marketing team overlapped weeks five through eight of the rollout. The UX team noted it, confirmed it hit both cohorts evenly, and still chose to attribute only 70% of the observed lift to the redesign in the final math. There is no formula that produces that number; treat it as an illustrative assumption for this example.

The team asked how much of the lift could plausibly belong to the pricing test if it had helped one cohort slightly more than the other, settled on a ceiling of about a third, and rounded the redesign’s share down to 70%. Your figure will differ. What matters is that it is written down and argued for before the results arrive, not fitted to them afterwards. That restraint is worth money in a skeptical room. “We attribute roughly 70% of the lift to the onboarding change, with the remainder likely influenced by concurrent pricing work” survives cross-examination; claiming everything does not. Cohort analysis then backed the number up, since the lift held across acquisition channels and tenure bands, and at that point the skeptics had very little left to work with.

Leading and lagging indicators belong on the same slide, because each covers the other’s weakness. Meridian’s leading indicators moved first — setup completion climbed from 62% to 89%, median time-to-first-value dropped from 14 days to 6.5 — and the lagging trial-to-paid number followed. Mechanism first, business outcome second. Presented together, they form a causal chain that’s harder to poke holes in than either one alone.

 

The ROI Calculation, End to End

So what did Meridian actually earn? The company sees about 40,000 trial signups a year. Lifting conversion from 8.0% to 9.4% adds roughly 560 paying customers annually, and at an average of $1,800 in annual recurring revenue per account, those customers represent about $1,008,000 in new ARR. Applying the conservative 70% attribution from the causal work trims the defensible figure to roughly $706,000.

Set that against the full $117,000 investment and the first-year ROI lands near 5:1, with payback arriving in roughly two months. There’s a second line, too. Onboarding-related support tickets dropped about 30%, some 3,600 fewer tickets a year, worth another $54,000 annually at $15 per resolved ticket. Keep it as its own line rather than folding it into one swollen headline number. The case reads as more honest that way and loses none of its force.

Three assumptions carry that result, and each belongs on the slide next to it. The 40,000 signups and the $1,800 average ARR are the prior year’s actuals held flat, so a growth or pricing change moves the outcome in either direction. The 70% attribution is the illustrative assumption from the causal work, not a measured quantity. And the two-month payback counts new ARR as it lands rather than revenue recognized net of churn, which flatters the timeline; on a net basis the payback stretches to roughly a quarter. State those three plainly and a finance team can adapt the example to its own numbers. Hide them and the whole thing starts to look like marketing math, however careful the experiment was.

What persuades in the final presentation is not sophistication. Open with the baseline: what stalled trials and support volume were already costing. Show the delta in terms leadership reads fluently, metrics like conversion rate uplift chief among them. A chart of setup completion climbing from 62% to 89% will beat a paragraph of UX jargon, and a translation like “each abandoned setup costs us 0.3 support tickets” beats the chart. Above all, keep every figure identical from the first slide to the last. A room full of finance people forgives many things, but never numbers that wobble between slides.

Tailoring The Case To Whoever Holds The Purse Strings

Budget decisions come out of coalitions. A CFO may hold the final say when adding AI to the checkout process, but marketing, product, and customer success all lean on that decision, and each means something different by “value.”

A CFO hears cost, revenue, and risk. A CMO hears conversion and acquisition cost, since UX is a lever for increasing marketing ROI. Product counts support tickets; customer success thinks in retention. The underlying numbers never change; only the framing rotates, and a CFO wants a projection, not a moodboard. Meridian’s CFO slide read “the onboarding redesign protects roughly $706,000 in new ARR a year against a $117,000 investment,” while the CMO version led with what a 9.4% trial conversion does to blended acquisition cost.

Beyond the Dollar Sign: Qualitative and Non-Financial Metrics

Some UX outcomes never translate cleanly into revenue, and pretending they do weakens the parts of your case that are solid.

The trick with qualitative evidence is collecting it rigorously enough that nobody can wave it off as anecdote.

Scores like Net Promoter Score (NPS), CSAT, and Customer Effort Score already sit inside most reporting cadences, which makes them cheap to borrow. Tie your work to their movement, and segment wherever the data allows.

Meridian could say that NPS among trial users on the redesigned onboarding was 51 against 34 for the legacy flow, which lands far harder than any blended average. Verbatim feedback from surveys, support transcripts, and app store reviews adds the emotional weight the scores lack. Internal tools deserve the same discipline, since employee experience is increasingly recognized as a business driver — a dashboard redesign that hands account managers 45 minutes a day back is a productivity gain, a satisfaction gain, and a retention lever all in one.

Brand perception resists direct measurement but leaves tracks in repeat visits, organic referrals, and social sentiment. It carries extra weight in trust-sensitive industries like finance or healthcare, and it forms fast, given that UX design influences the first impressions of a whopping 94% of customers.

Whatever you collect, systematize the collecting. Run pre- and post-surveys with consistent question sets, use structured usability testing with task-based scoring, and put the qualitative right next to the quantitative when you present.

“Setup completion rose from 62% to 89%, and in post-test interviews 8 of 10 participants called the new flow intuitive, against 3 of 10 for the old one” — a pairing like that is much harder to dismiss than either half on its own.

Making the Case Stick #

UX loses the budget battle unless it’s mapped to company-wide objectives, so phrase the proposal in the words of this year’s board presentation.

Nobody at Meridian pitched “simplify the onboarding UI”; the pitch was a redesigned trial experience worth 1.4 points of upgrade rate, roughly $1M in annual recurring revenue before attribution. Bring evidence in both registers, since that is what social proof is for: the case, clearly labeled, plus screenshots, impact graphs, and user quotes. Find internal allies who can repeat the ROI narrative in rooms you’ll never enter, and write the playbook down, because repeatable ROI is what earns recurring investment.

Resources for Going Deeper

This topic has been explored extensively by researchers, practitioners, and consultancies. Here’s a curated set of resources worth studying if you want to build a stronger ROI practice around UX.

  • “Measuring the User Experience” by Tom Tullis and Bill Albert is the definitive guide to UX metrics. It covers everything from task-based measurements to survey design to statistical analysis, and it’s written for practitioners, not academics.
  • Jared Spool’s “The $300 Million Button” case study is a classic example of how a single UX change (removing a mandatory registration step) generated massive revenue uplift. It’s a story every UX professional should have in their back pocket.
  • Forrester’s research on UX ROI provides enterprise-focused frameworks for building business cases around experience design, including their widely cited finding that every dollar invested in UX returns $100.
  • “UX Strategy” by Jaime Levy bridges the gap between design thinking and business strategy, offering practical tools for aligning UX initiatives with organizational goals and market positioning.
  • The Design Value Index by the Design Management Institute tracks publicly traded companies that invest heavily in design against the S&P 500. The data consistently shows that design-led companies outperform the index by significant margins, and it’s a powerful data point for executive presentations.
  • Google’s HEART framework provides a structured approach to selecting UX metrics at scale. HEART stands for Happiness, Engagement, Adoption, Retention, and Task success, and it’s particularly useful for teams that struggle to decide which metrics to track.

Conclusion

A seat at the table never comes from beauty or novelty. It comes from measurable, defensible impact, which means UX leaders have to trade the artist’s posture for the strategist’s. Speak in outcomes rather than outputs. Connect pixels to profit.

When someone challenges the numbers, don’t flinch. Show the controlled experiment, the cohort analysis, and the before-and-after metrics, every figure holding steady from the first slide to the last, the way Meridian’s did, with the customer quotes and the employee-satisfaction data sitting right beside the revenue impact. Prove the work does more than delight users, and be ready to defend the ratio line by line. That’s when the CFO leans in, and that’s when design stops being optional.

Posted by H at 7:33 AM 0 comments

The Death Of The Button: Why The Best Interface Is No Interface

 

The web is evolving beyond menus, forms, and endless clicks toward experiences shaped around human intent. For UX designers, understanding this shift means re-evaluating their role, moving from designing visible interfaces to guiding transparent, intent-driven AI experiences.

Ever since the commercialisation of the Graphical User Interface pioneered by systems like the Xerox Star and popularised by the original Apple Macintosh, software has relied heavily on point-and-click interactions. If you wanted to book a trip, buy a pair of shoes, or research a health symptom, you were expected to navigate a labyrinth of user interfaces. You click menus, adjust range sliders, fill out multi-step forms, deal with cookie pop-ups, and open dozens of browser tabs just to cross-reference basic information. We have become accustomed to spending more time managing the software rather than actually achieving our goals.

That contract is officially changing. Driven by advances in artificial intelligence and large language models, a new generation of web tools is pioneering a radical philosophy: Intent-Driven Design. Rather than expecting our users to learn complex menus and click through elaborate sales funnels, these platforms operate by capturing high-level human goals and silently executing the grunt work in the background.

This vision builds on long-standing HCI concepts like Golden Krishna’s “The Best Interface Is No Interface” and Don Norman’s principles of human-centered design.

The ultimate goal of modern web design is no longer to build prettier buttons or flashy animations; it is to eliminate the interface entirely.

“

Well, at least what we understand based on our current experience.

It is essential for UX designers to understand the changes we’re witnessing and even re-evaluate our role, shifting our focus from designing visible interfaces to guiding transparent, intent-driven AI experiences.

The Death Of The “10-click” Process

To understand where web design is going, we first have to look at the friction we have accepted as “normal” for decades.

Consider the traditional workflow of buying a flight online. The user experience is intentionally hyper-interactive:

  1. Navigate to a travel aggregator or airline website.
  2. Select “Round Trip” from a dropdown menu.
  3. Type the origin city and wait for auto-complete.
  4. Type the destination city and wait for auto-complete.
  5. Click a calendar modal, toggle through months, and select departure and return dates.
  6. Choose the number of passengers and cabin class.
  7. Click “Search” and wait for the results page to load.
  8. Filter by price, layover duration, departure time, and airline.
  9. Sort the results and scan through dozens of individual options.
  10. Click through a three-page checkout funnel dodging upsells for rental cars and travel insurance.

This is a classic point-and-click UI paradigm. The computer acts as a passive container of data, and the human acts as the orchestrator, manually inputting parameters, interpreting raw outputs, and executing each micro-step along the way.

Intent-driven design flips this dynamic entirely. Instead of forcing you to navigate the mechanical steps of how to find a flight, the interface asks a simple question: What are you trying to accomplish?

When you express a goal, such as “Find me a non-stop flight to Chicago next weekend under $300 that arrives before 5 PM”, the software reads your intent, executes the multi-step search query behind the scenes, compares the options, and presents a single actionable resolution. The ten clicks dissolve into one clear intent outcome.

10-click process vs AI-driven intent flow.
10-click process vs AI-driven intent flow. Image generated by Gemini. 
Posted by H at 7:29 AM 0 comments
Subscribe to: Posts (Atom)