The Client Said Cool Eleven Times

I counted. Eleven times.

In a recent technical demo call, I said some version of "cool," "yeah," or "very cool" eleven times. I asked exactly one technical question - "Can you do images too?" - and it was answered in eight seconds. Then I went right back to nodding along.

I'm not telling you this to be self-deprecating. I'm telling you this because what happened on that call is one of the most expensive mistakes that happens between developers and the people paying them. And neither side even notices it while it's happening.

What "Cool" Actually Means

When a non-technical founder or client watches a dev demo and says "cool" - they do not mean I understand what you built and it aligns with my vision. They mean: I don't know what I'm looking at, I don't want to seem stupid, and "cool" is the safest word I have right now.

That's it. That's the whole translation.

I've built and sold five SaaS companies. I've hired dozens of developers. I've sat on the client side of more demos than I can count. And I will tell you plainly: "cool" from a non-technical stakeholder is one of the most dangerous words in a product build. Not because it means they're unhappy. Because it means they have no idea whether they're happy or not. And they won't figure it out until the product ships and doesn't do what they imagined - and by then, you've burned weeks or months of build time going in a direction nobody actually validated.

The dev on the other side of that call had done real work. He'd built a backend that could parse PDFs, Excel sheets, Word docs, URLs, and raw image files. He was using LangChain as the integration layer, LlamaIndex for data orchestration, vector databases for scalable retrieval with no hard limits on data size, and AWS S3 for file storage. He tracked token usage down to the cent - the demo showed a cost of about $0.01 per query. That's thoughtful engineering. That's a real working prototype.

And I sat there and said "cool" eleven times.

I asked about images. He said yes, they can add GPT-4 Vision APIs. I said "okay, cool." And we moved on.

That's the problem.

The Gap Nobody Talks About in Product Builds

There's a concept I keep coming back to in every SaaS build I've done: the distance between what a founder imagines and what a developer builds is not a technical problem. It's a communication problem. And it compounds silently until launch day, when someone finally has to say the thing nobody wanted to say six weeks ago.

Most technical discussions between founders and devs fail in one of two ways:

• The founder drowns the dev in business requirements without giving enough technical direction
• The dev demos working code while the founder nods along, saying "cool," without ever articulating what they actually needed to see

The second failure mode is rarer to talk about, because the code works. The demo runs. Everything looks fine. But fine and right are not the same thing.

On this call, there was a moment where the demo threw errors - the API key hadn't been added yet, a PDF failed to parse on the first try. The dev handled it with good humor: "It always happens in demos, bro." Totally fair. But nobody stopped to ask: when this is in production and it errors out for a real user, what does the error handling look like? What does the user see? What gets logged?

I didn't ask, because I was in nod-and-say-cool mode. The dev didn't raise it, because he was focused on showing what works, not what breaks.

That gap - right there - is where products go sideways.

The One Question That Breaks the Pattern

If you are a developer - whether you're freelancing, working with a startup founder, or inside an agency running a product build - and your client is watching a demo and saying "cool" without specifics, you need to stop the meeting and ask one question:

"What would make this uncool?"

That's it. That's the whole framework.

Not: "Do you have any feedback?" Feedback is too open-ended. Most non-technical clients don't know what feedback looks like on a backend architecture demo. They can't tell you what LlamaIndex is doing wrong. They don't know what a vector database is supposed to feel like.

Not: "Does this match the spec?" That kicks it back to a document that was probably written three weeks ago and is already half-outdated.

"What would make this uncool?" - that question works because it reframes the entire conversation. It doesn't ask the client to evaluate what they saw. It asks them to imagine what would have to be different for this to not work. And nine times out of ten, when you push them to answer that question, they'll say something like: "Well, I guess I'd need to know what happens when a user uploads a corrupt file" or "I'm not sure how this connects to the pricing model we discussed."

And suddenly you have a real conversation. Not eleven cools.

Why Clients Say Cool Instead of Asking Questions

I was doing it too, so I can explain it from the inside.

When you're watching a technical demo as a non-technical founder, you're simultaneously trying to: track what's on screen, evaluate whether it matches your mental model of the product, assess the developer's competence, not seem like you don't understand what you paid for, and manage the relationship so nobody feels criticized.

That's five things happening at once. And the cognitive load is high enough that most people default to the safest, lowest-friction response: cool.

There was a moment in the call where the dev mentioned the "bring your own keys" architecture - a model where users supply their own OpenAI API key and the platform charges based on token usage per session. He showed a cost tracker down to the dollar amount, with tokens used per prompt. That's a specific product decision with real implications for pricing, user experience, and billing logic. It directly affects how I'd sell the product.

I should have stopped right there and said: "Okay, walk me through what a user sees when they hit their token budget. Is there a hard cutoff? A warning? What's the UX on overages?"

Instead, I said: "So we're on the same page in terms of users aren't using their own API key - we're using ours."

And then my audio cut out.

That's the other thing about these calls: connection issues, rescheduled meetings, last-minute setup scrambles - all of it chips away at the quality of communication that actually needs to happen. The dev mentioned he'd just gotten home and saw the rescheduled meeting with little notice. I'd enabled screen sharing for him only partway through. Small friction points, but they add up. Every technical hiccup in a demo call is one more excuse for everyone to move fast through something that deserved more time.

What Good Technical Feedback Looks Like

I'm not a developer. I don't need to be. But I've built enough products to know what a non-technical founder's job is during a demo: translate the technical output back into user experience, and flag every place where those two things might diverge.

In this specific call, the right questions would have looked like:

• When the PDF parsing fails silently, what does the user experience? Where does the error surface?
• The vector database scales to tens of thousands of rows - great. What does query latency look like at that scale?
• You mentioned GPT-4 Vision for images. Is that a separate cost line, or is it rolled into the token tracking we already saw?
• You showed a summary of a Medium article from a URL. In production, what happens with paywalled URLs? Login-required pages?
• The "upload file" API sends to AWS S3 - what's the file size limit? What happens when someone uploads a 500MB file?

None of these questions require me to understand the code. They require me to think about the product from the outside, as a user would experience it, and then bring that perspective into the room.

That's the job. And I wasn't doing it. I was saying cool.

This Problem Scales

Look, this isn't just a "founders are bad at giving feedback" post. This is a systems problem.

In any product build, the further you get from early feedback, the more expensive the corrections become. A question that takes five minutes to answer in week two of a build takes five weeks to fix in week ten. That's not a developer being slow - that's just how compounding works when you're building on top of a misunderstood foundation.

The token cost tracker this dev built was showing $0.01 per query. Impressive. But if the billing logic underneath that tracker is based on an assumption I never confirmed - like who's eating that cost, the platform or the user - then the entire monetization model could be built on a wrong answer to a question I thought was resolved but never actually asked.

Eleven cools, zero confirmations.

If you're building something technical and you want the person on the other side of the demo to actually engage, don't accept passive approval. Make it slightly uncomfortable to just nod. Ask: "Before we move on, what's one thing about what you just saw that you're not sure about?" or "If this were going live next Monday, what would worry you?"

Force the conversation out of performance mode and into problem-finding mode. That's where the real work happens.

The Broader Lesson About Product Communication

One of the things I've learned from building multiple software businesses - and helping founders and agency owners through programs like Galadon Gold - is that the product problems almost never show up as product problems at first. They show up as communication problems. Vague approval. Assumptions that weren't checked. Decisions that felt obvious to one side and were never mentioned to the other.

The dev on this call built something real. LangChain, LlamaIndex, vector databases, AWS S3, token cost tracking per prompt, multiple file format support including PDFs, Excel, Word docs, and URLs - that's a working RAG architecture. That's not a prototype in the bad sense of the word. That's infrastructure.

But infrastructure only matters if it's pointed in the right direction. And the only way to know it's pointed in the right direction is to stop saying cool and start asking what would make it uncool.

One question. That's all it takes to flip the dynamic from passive demo to active validation.

I'm going to ask it more. And if you're a dev building for a founder who keeps nodding and saying "cool" - do everyone a favor and ask it for them.

Because what lives inside eleven cools is almost never approval. It's usually a list of assumptions that haven't been tested yet. And the sooner you pull those out into the open, the less expensive they are to fix.

If you want frameworks for running better discovery calls and client alignment sessions, the Discovery Call Framework I put together covers the specific questions that actually surface what a client needs - versus what they say they need. And if you're building out a product or agency and want to work through this stuff live, check out Galadon Gold - that's where these coaching sessions happen in real time.

Cool? Cool.

Actually - tell me what would make it uncool.