What happens when you answer “Can you show us sample projects?” with “Can we look at your website instead?”
In my last article, I wrote about a question that has quietly shaped my whole career: “What is the real goal here?” I talked about how asking it turned me from a designer executing briefs into someone who helps write them.
What I didn’t talk about is where that question gets asked most often these days.
It’s not in a Figma file or a sprint planning meeting. It’s in the first conversation with a prospective client — usually right after they ask:
“Can you send us some case studies?”
It’s a fair request. When you’re about to trust a team with your website, your product, or your platform, you want proof they know what they’re doing. For a long time, I answered it the standard way: a portfolio, a few links to things we’ve shipped, even a deck when applicable.
But over time, I noticed something about those conversations. The deck rarely did the work I wanted it to do.
The Case Study Problem
Case studies show a client what has been built for someone else. A polished deck says, “We’ve done good work.” What it can’t say is, “We understand your problem.” And for most of the companies that come to us: SMEs, nonprofits, growing teams, their problem is specific. Their site, their users, their constraints, their internal reality. No slide about someone else’s project was ever going to capture that.
So we tried something different. Instead of leading with our portfolio, we offered to start with theirs:
“Let us take a look at your website. No commitment. We’ll tell you what we see.”
That’s how the UX audit became our front door. And it changed the kind of conversations we were having almost immediately.
The most convincing case study isn’t one you send. It’s one you build around their actual problem.
What We Actually Look At (Hint: It’s Not Just the Pixels)
I’ve written before about dropping jargon in client meetings, so let me describe an audit the way I’d describe it across a table, not in a proposal.
When we look at a website, we’re really asking a handful of plain questions:
- Can a first-time visitor tell what you do within five seconds?
- Can they find the thing they actually came for?
- Does the site work on the phone they’re holding right now?
- Does Google know you exist — and does it like what it finds?
- Where do people give up?
Under the hood, that means looking at usability, content clarity, performance, search visibility, and conversion paths. But on the surface, it just means using the site the way a real person would — and being honest about where it fights back.
The findings are rarely exotic. A homepage that says everything, and therefore nothing. A contact form that asks twelve questions before it lets you say hello. An FAQ page that feels clunky — not because of the layout, but because the content lives somewhere nobody on the team can actually update, so it’s been quietly aging for two years.
None of these are mysteries. They’re just things nobody inside the company has time to see, because they’re too close to it.
Most UX Problems Are Symptoms
This is the part I find most interesting — and the part clients least expect.
When you start pulling on a UX thread, you almost always find something underneath it.
A slow website isn’t a design problem. It could be infrastructure. A clunky checkout flow isn’t just a UI issue. It’s how the systems behind it were stitched together years ago. “We can’t update our own content” isn’t a content problem. It may be the code, maybe how things were put together.
What looks like a design problem is sometimes an engineering problem in disguise.
That’s exactly why an audit is such a good place to start. Not because the website is the biggest problem a company has — but because it’s the most visible one. The website is where the deeper issues surface. It’s the symptom you can actually point at.
And once a client sees that connection — once they understand that the thing bothering their customers on the surface is tied to how things were built underneath — the conversation naturally gets bigger. Not because we push it there. Because that’s where it actually exists.
The Audit Stands on Its Own
I’ll be honest: when we first started offering audits, part of me worried we were giving away the work for free. Why would someone pay for help if we just… tell them what’s wrong?
People walked away from the audit with a clear picture of where they stood — some things they could fix themselves, some things they’d need help with, and a much better sense of what mattered and what could wait. Even when that didn’t turn into a project, it turned into something else: trust.
People remember who told them the truth. They come back. They refer. They call six months later when the “small website issue” has become impossible to ignore.
The deliverable of an audit isn’t a report. It’s clarity — and clarity has a way of coming back around.
Why We Put a Price on It
When the audit was an informal, free thing we did in early conversations, something predictable kept happening. People loved it. They nodded along, said “this is so useful,” and then — filed it. The findings were real, the quick wins were obvious, and a lot of it never got acted on. Free advice, it turns out, is very easy to appreciate and very easy to postpone.
So we did the thing that felt slightly uncomfortable: we productized it. We gave it a fixed scope, a fixed framework, fixed deliverables — a severity-ranked report, a mix of quick wins you can fix today and strategic improvements to plan for tomorrow, and a live walkthrough where we talk through all of it. We put it on our website as a real thing you can book, at a deliberately small price.
And I mean deliberately. $39.99 is not a revenue strategy. It’s a commitment signal.
I can’t show you a chart proving that paid audits get acted on more than free ones, it has just been launched. But the bet we’re making isn’t a wild one, and I’d rather tell you what we’re betting on than pretend we have results we don’t have.
First: people have expectations on what they pay for. Anyone who’s ever received a free trial they never opened, or sat through a free webinar they half-watched, knows this in their bones. Secondly, putting a price on it forced us to define exactly what it is. No more vague “we’ll take a look.” What does the report include? What happens in the walkthrough? What can you expect to walk away with? Productizing the audit made the audit better — a lesson I probably should have remembered from all those years of scoping client projects.
Free advice gets filed. Paid advice gets used.
So consider this an open invitation to be one of our first data points. If it works the way we think it will, you’ll get a sharper website out of it. If you’ve simply been curious what a structured, outside pair of eyes would find on yours — there’s never been a cheaper way to find out.
It Stands on Its Own — That’s the Point
The audit is yours, whatever happens next.
Some teams take the report and fix the quick wins themselves. Some hand it to their own developers. Some come back to us for the bigger items. All three are good outcomes. A paid, standalone deliverable means nobody owes anyone anything, and that’s exactly why it builds trust.
People remember who told them the truth. They come back. They refer. They call six months later when the “small website issue” has become impossible to ignore.
Where the Small Questions Lead
Almost every substantial conversation we’ve had — about cloud infrastructure, about rebuilding a platform, about a mobile app, about AI tools — started as a small question about a website.
I want to be careful about how I say this, because it can sound like a sales strategy, and it isn’t. We don’t walk into an audit hunting for a bigger project. We walk in curious. But when you genuinely follow a problem wherever it leads, the trail rarely stops at the homepage. A slow site may lead to hosting. Hosting may lead to infrastructure. Infrastructure is to how the whole system was designed — and whether it can carry where the business wants to go next.
The website is just where the story starts. Being a small, hands-on team means we get to follow it all the way through — from the first audit conversation to designing, building, and running whatever comes out of it. That continuity is honestly the part I enjoy most. You don’t hand off the problem. You stay with it.
It Starts With One Question
In my last article, I ended with this thought: the best conversations start with someone willing to ask, “What is the real goal here?”
I’ve come to believe the same is true of websites. Behind every “Can you send us a case study?” There’s a quieter question: “Something about our digital presence isn’t working — can you help us see what it is?”
You don’t need a deck to answer that. You need a fresh pair of eyes, a structured way of looking, and the honesty to say what you find — on the surface, and underneath it.
If you’ve ever looked at your own website and felt that something wasn’t quite right, but couldn’t put your finger on it — that’s usually where our conversations start. These days, it starts even simpler: the audit is live on our site, and you can see exactly how it works at uxaudit.base87.tech. Get a clear look at where you stand , and you’d be surprised how often that small question turns out to be the beginning of a much bigger one.
Thanks for reading! 💗
