Why One Feature Almost Never Costs What You Think

It usually starts with a very innocent sentence.

"Let's just change the colour of the button."

Or:

"Let's add one more filter. It's a couple of hours of work, tops."

If you work in tech, you've heard this dozens of times. And sometimes it really is that small. But far more often, that sentence is the entry door to a tiny project that quietly takes on a life of its own.

Not because the engineers are slow. Not because the process is broken. But because building product almost never equals writing code.

Example 1. "Just change the button colour"

At first glance, the task looks like this: open the file → change the colour → check → ship.

Expected cost: ~$120. Sounds reasonable. Now let's zoom out.

What actually happens:

• someone phrases the task;
• someone clarifies why we're changing it at all;
• the designer checks contrast and accessibility;
• the PM verifies it doesn't break a scenario;
• the developer makes the change;
• QA checks several devices;
• someone signs off the release;
• after release, someone makes sure everything still works.

And suddenly it's not one person anymore. It's a team.

Average loaded team cost: ~$1,400. For a button. Yes, sometimes it's cheaper. But almost never as cheap as it looks at the start.

Example 2. "Just add a filter"

This is where it gets interesting. Because a filter is rarely just a filter. Questions start showing up:

• which fields can be filtered?
• what happens when there are no results?
• do we remember the user's selection?
• do we need analytics on it?
• is the mobile version the same?
• does it affect performance?
• do users actually need it?

A couple of days later, the discussion has taken longer than the implementation.

Cost: ~$2,800. And it no longer looks like a couple of hours of work.

The most expensive part of a feature is rarely called "development"

Here's an interesting pattern. The more experienced a team becomes, the less time it spends writing code - and the more time it spends making decisions. Because almost anything can be written. What's harder is deciding:

• what to do;
• why to do it;
• how to measure the outcome;
• what NOT to do.

Sometimes a single cancelled feature saves more money than ten successfully shipped ones.

Where companies actually lose money

Not in development. Usually here:

• constant changes of decisions;
• no clear owner;
• too many approvers;
• launching without a clear goal;
• endless "just one more thing";
• unfinished initiatives.

An unfinished feature almost never creates value. But it almost always creates cost.

What you can try tomorrow

Before the next task, try asking three questions:

1. What exactly are we trying to change?
2. How will we know it actually got better?
3. What happens if we don't do it at all?

Sometimes the best way to save budget isn't to speed up the team. It's to remove half of the tasks.

The takeaway

Most features cost more than they look. Not because people work badly. But because product isn't built by code. It's built by decisions. And often the fastest way to move faster is to do fewer things - and actually finish them.