The 15-minute test that tells you if your developer actually listens

A business owner tells a developer, “I need a customer portal,” and the developer says, “Absolutely.” Sounds promising, right?

Myth: the developer who agrees fast is the one who gets it.

I used to think that too. Quick confidence feels good. It feels efficient. You explain the problem, they nod, maybe toss in a few technical terms, and now it seems like the train is moving.

But in software, fast agreement is often fake progress.

A developer who really listens usually does something less comfortable in the first 15 minutes: they slow the conversation down. They ask what problem the portal is supposed to solve. They ask who will use it. They ask what your staff is doing manually today that this thing is supposed to replace. They ask what would make you say, three months from now, “Yes, this was worth building.”

That is the test.

Not “Are they friendly?” Not “Do they sound smart?” Not even “Did they repeat my request back to me?” The real test is this: after 15 minutes, do you feel like your own problem got clearer?

A good developer doesn’t just take your order like a drive-thru speaker. They act more like a contractor walking through a remodel. If you say, “I want this wall gone,” the good one doesn’t just grab a sledgehammer. They ask whether it’s load-bearing.

That matters because unclear requirements are one of the biggest reasons software projects go sideways. The Standish Group has been pointing that out for years. Rework is expensive. Confusion is expensive. Building the wrong thing efficiently is still building the wrong thing.

This is why I’m skeptical of developers who jump straight to features, timelines, or price before they’ve pinned down the goal. It’s one of the bigger developer red flags business owners miss. If you want a deeper list, read how to evaluate a developer when you do not know code and red flags that your developer is in over their head.

Here’s what I’d look for in that first short meeting:

• They ask about users, not just managers
• They separate the problem from the requested feature
• They point out assumptions or missing details
• They suggest a smaller first version to test the idea
• They send a clear written recap afterward

That last one matters more than people think. Listening is not a performance. Some developers are warm and chatty. Some are quiet and methodical. I wouldn’t confuse style with substance. A strong developer may not be the smoothest talker in the room, but they’ll leave behind a clean summary that proves they understood the job.

And to be fair, this test doesn’t only judge the developer. Sometimes the brief is the problem. If you walk in saying, “Build me an app like Uber, but for my business,” you’re not giving someone much to work with. Good software project management starts with a real conversation, not a vague wish list. That’s true whether you’re working with a freelance developer, a bigger shop, or someone local in Northwest Arkansas.

I see this a lot in custom software development: the best early conversations are not the ones where everyone agrees quickly. They’re the ones where the fog lifts.

If your developer leaves the first meeting with a feature list, that’s fine. If they leave with a sharper definition of the problem, that’s better.

So next time you explain what you think you need, ask yourself this: did they just hear your request, or did they actually help you understand your own business better?