The Feature Nobody Asked For That We Built Anyway
A case for building small, unglamorous internal tools before flashy customer-facing ones — plus the 5-question test we now use to decide whether an unrequested feature is actually worth the detour.
Not every feature on the roadmap was on the roadmap.
Sometimes the highest-leverage thing you can build is something nobody explicitly requested — because the person who needed it didn’t know it was possible to ask for.5
questions we now run every unrequested feature through before building it anyway
Developed after this specific project
Midway through a client project, one of our developers noticed the client’s team was manually copying data between two systems every single day — a tedious, entirely unglamorous task nobody had mentioned during scoping, because from the client’s side, it just felt like “how the job works.”
It wasn’t in the brief. Nobody asked for it. Building it would use time that was technically allocated elsewhere. We built it anyway — a small internal sync tool that automated the copy-paste entirely. It took a day and a half. Here’s why we made that call, and the test we now run before making it again.
A feature that scores high across most of these is usually worth the detour. One that scores low on “can it be built in under 2 days” or “does it touch systems already in scope” is a sign to log the idea and raise it formally instead — not to quietly go build it.
1.5 days
Time spent building the unrequested tool
45 min
Time the client’s team was spending daily on the manual task it replaced
~180 hrs
Estimated annual time saved for the client’s team going forward
Why “it wasn’t in the brief” isn’t the same as “it wasn’t needed”
Clients scope projects based on what they know to ask for — and most people outside software genuinely don’t know what’s automatable. A repetitive manual task often doesn’t register as a “feature request” in someone’s mind; it just feels like an unavoidable part of the job, the way filling out a paper form used to feel unavoidable before someone built a form that submits itself. That’s exactly the gap where an unrequested feature can create disproportionate value — the client didn’t ask because they didn’t know it was possible, not because they didn’t need it.The decision scorecard we built afterward
Not every “nobody asked for this but I noticed it” idea is worth building. Scope creep in the other direction — a developer going off-script to build things clients didn’t ask for and don’t actually need — is its own real problem. After this project, we formalized a quick scorecard to separate genuinely valuable detours from well-intentioned distractions:Feature detour scorecard — the sync tool, scored against our 5 questions
| Question | Assessment | Score |
|---|---|---|
| Is this a repeated, manual pain — not a one-time inconvenience? | Done daily, every workday, by more than one team member | High |
| Can it be built in under 2 days without derailing the actual scope? | 1.5 days, absorbed without affecting the original timeline | High |
| Would the client have said yes if they’d known to ask? | Confirmed directly — an easy yes once described | High |
| Does it touch systems already inside the current project’s scope? | Same two systems already being integrated as part of the build | High |
| Is the cost of NOT building it compounding over time? | Yes — daily manual cost, indefinitely, until fixed | High |
What changed after we built it
The clearest signal that this was the right call came in how the tool actually got used, not in how it was received when we announced it:Why we didn’t bill separately for it
The tool fell within the fixed-price scope of the original project — no extra invoice, no surprise line item. We flagged it clearly in our project notes as a value-add, not as billable extra work, because it used time that would otherwise have gone to internal buffer, not time taken from the client’s paid scope.
“The client didn’t need us to build what they asked for. They needed us to build what they actually needed — and those aren’t always the same list.”
Where this test breaks down
To be clear about the limits of this approach: this only works because the detour was small, contained, and directly tied to systems already inside the project. It would be a mistake to use “I thought it would help” as justification for larger, unscoped work — that’s a different conversation, one that needs the client’s explicit sign-off and a proper scope and price adjustment, not a quiet surprise add-on.The 5-question test, as a quick checklist
✓
Is this a repeated pain, not a one-time inconvenience?
✓
Can it be built in under 2 days without derailing the actual scope?
✓
Would the client say yes if they’d known to ask?
✓
Does it touch systems already inside the current project’s scope?
✓
Is the cost of not building it compounding the longer it waits?
Where this leaves you
If you’re working with a development team and notice a repetitive manual process nobody’s mentioned, it’s worth raising — even informally. The best fixes are sometimes the ones nobody thought to ask for, because nobody realized they were fixable.