Your developer just told you that's not a bug, it's a feature request. You're thinking: "But it should work this way!"
I get it. But the distinction matters. A lot.
Because bugs are typically fixed under warranty or maintenance. Feature requests are new work that needs scoping and billing.
Here's how to tell the difference.
What's a Bug?
A bug is when the system doesn't do what it's supposed to do.
Examples:
→ The login button doesn't work → The calculation is wrong (shows $105 instead of $100) → The page crashes when you click Submit → Data that should save doesn't save → Something that worked yesterday doesn't work today
Key question: Is this breaking existing, agreed-upon functionality?
If yes, it's a bug.
What's a Feature Request?
A feature request is when the system works as designed, but you want it to do something different or additional.
Examples:
→ "Can we add a filter by date range?" (System works, you want more functionality) → "Can the email notification include the customer's phone number?" (Emails work, you want different content) → "Can we export this to Excel instead of PDF?" (Export works, you want a different format) → "Can users upload 10 files instead of 5?" (Upload works, you want to change the limit)
Key question: Is this asking for something new or different from what was agreed upon?
If yes, it's a feature request.
The Gray Area
Sometimes it's not clear-cut.
Example: "The search function is too slow."
→ If the agreement was: Search should return results in under 2 seconds, and it takes 10 seconds, that's a bug. → If the agreement was: Search should work (no performance SLA specified), and it takes 10 seconds but technically works, that's a feature request (performance improvement).
This is why clear acceptance criteria matter.
Why It Matters for Your Budget
Most development contracts include:
→ Warranty period (30-90 days) where bugs are fixed free → Maintenance agreement where bugs are fixed as part of monthly support → Change request process where feature requests are scoped and billed separately
If you call every feature request a bug, you'll either:
→ Get pushback from your developer (damaging the relationship) → Get billed for "bug fixes" that are actually new work → Burn through your maintenance hours on scope creep
None of those are good.
How ScopeForged Handles This
We define acceptance criteria in every milestone.
Each deliverable has clear criteria for what "done" looks like. This makes the bug vs. feature distinction obvious.
Example milestone acceptance criteria:
→ Users can upload PDF files up to 10MB → Files are stored securely in cloud storage → Users can download their uploaded files → Upload completes in under 10 seconds for files under 5MB
If any of those don't work, it's a bug.
If you later want to add Word doc support or increase the limit to 20MB, that's a feature request.
No ambiguity.
How to Avoid the Confusion
Before calling something a bug, ask:
→ Was this functionality explicitly agreed upon in the scope? → Did it ever work the way I'm expecting? → Or am I asking for something new or different?
If you're not sure, just ask: "Is this a bug or a feature request?"
A good developer will explain the reasoning. And if it's a feature request, they'll help you scope it and prioritize it.
The Bottom Line
Bugs = the system doesn't do what it's supposed to do. Fix them.
Feature requests = you want the system to do something new or different. Scope and prioritize them.
Knowing the difference saves budget surprises and keeps your project relationship healthy.
What's the trickiest bug vs. feature call you've had to make?
#SoftwareDevelopment #ProjectManagement #BugTracking #ClientRelations #TechForBusiness
→ scopeforged.com
Philip Rehberger Founder, ScopeForged scopeforged.com
