The Email That Ruins Everyone's Monday

A client wrote to me last year, understandably annoyed. Her site had a search feature. Customers typed in a product name and got results. She wanted to add a filter so people could narrow those results by price. In her mind, that was obviously part of "search." She had paid for search. Why was I quoting her for more work?

I get a version of this message more than almost anything else I hear from clients. Someone believes a developer is either padding the bill or refusing to fix something they broke. Almost every time, what's actually happening is a mix-up between two very different things: a bug and a feature request.

This mix-up causes more friction between business owners and developers than almost any other issue. It's not about dishonesty on either side. It's about two people using the same word, "broken," to mean two different things. Once you understand the real distinction, the argument mostly disappears, and you can plan your budget with a lot less stress.

The One Question That Settles It

Here's the plain-English test I use, and you can use it too: Did we agree it would do this?

If the answer is yes, and it isn't doing that, it's a bug. Something was promised, built, or working, and now it isn't. That's on the developer to fix, usually at no extra charge, because it's a broken promise, not new work.

If the answer is no, meaning nobody ever specified that behavior, then it's a feature request. It's not the software failing to do what it was supposed to do. It's you asking for something it was never built to do in the first place. That's new work, and new work costs money and takes time, the same way asking a contractor to add a room isn't covered by the warranty on the house they already built.

Go back to the search example. The original agreement covered a search box that returns matching products. It never mentioned filtering by price. So even though "search" feels like one feature to a customer, filtering was never part of what got built or agreed to. That makes it a feature request, not a bug.

Why This Distinction Protects Both Sides

It's tempting to think this rule only protects the developer, letting them charge for anything they didn't feel like building the first time. It actually protects you just as much.

Without a clear line between bug and feature, you have no way to know if a quote is fair. If everything can be labeled a "feature," a developer could bill you for fixing their own mistakes. If everything can be labeled a "bug," you could keep expanding the project for free and never pay for the value you're actually receiving. The bug-versus-feature test keeps both sides honest. It says: broken promises are free to fix, and new value costs money. That's a fair trade, and it's the same logic behind any warranty you've ever dealt with, on a car, an appliance, or a piece of software.

This is also why a real specification matters so much upfront. I've written before about how to read a software quote, and the short version is: vague quotes create vague expectations, and vague expectations are exactly what turns a small filter request into a heated phone call.

The Gray Areas, and How to Handle Them

Most cases are clear-cut. A login button that used to work and suddenly doesn't is a bug. A request for a brand-new mobile app when you only paid for a website is obviously a feature. But some situations sit in the middle, and it helps to know how they usually get handled:

  • "It should have been obvious." Sometimes a business owner assumes a capability was implied, even though nobody wrote it down. Reasonable developers will often treat small, genuinely obvious gaps as good faith and fix them for free. But "obvious" is subjective, so the more specific your original request was, the less this comes up.
  • Missed edge cases. If the software crashes on a case nobody thought to test, like a customer entering a name with an unusual character, that's usually treated as a bug, even though it wasn't explicitly listed. The intent was for the feature to work reliably, and it didn't.
  • "Just a small tweak." A lot of feature requests get framed as small changes to make them sound like they should be free. Size doesn't decide the category. A five-minute change to something that was never agreed to is still a feature request. A two-day fix to something that was promised is still a bug.

When something falls in a gray area, the fastest way through it isn't arguing. It's pulling up the original agreement or specification and checking, in plain language, whether the behavior was described. That single step ends most disputes in minutes.

How a Clear Spec Prevents the Argument Entirely

The real fix isn't a better argument during the dispute. It's avoiding the dispute in the first place. A clear, written specification before work begins, listing what the software will actually do, protects you from surprise bills and protects your developer from scope creep. When both sides can point to the same document and ask "did we agree to this," there's nothing left to argue about.

If you've ever felt blindsided by a quote or an invoice, the fix usually isn't a different developer. It's a more specific conversation before the work starts, paired with the kind of ongoing maintenance relationship that clearly separates "keeping what we built working" from "building something new."

The Bottom Line

A bug is a broken promise. A feature request is a new one. Knowing which one you're looking at, and asking the one question that settles it, saves you money, saves your developer a headache, and keeps your project moving instead of stuck in a debate about who owes what.

If you're staring at a quote or an invoice and can't tell which side of the line you're on, let's talk through your situation.