“It’ll only take a moment”
Anyone working on building or maintaining a website, app or system knows this message.
“Can you just change this button?”
“It’s really a minor fix.”
“Please just move this element.”
“Can it be done quickly?”
“It should be five minutes, right?”
And sometimes it really is.
Sometimes changing a button color takes a few minutes. Sometimes fixing a typo is one click. Sometimes a developer opens the code, changes one line and that’s it.
The problem is that not every change that looks small from a user’s perspective is small from the system’s perspective.
And an even bigger problem appears when there are a dozen, dozens or hundreds of such “small changes” in a month. Then something interesting starts to happen.
A company may feel like it isn’t ordering anything major. And at the same time the IT team spends a significant portion of its time on precisely those small tasks.
And here comes the question: How much does one “Fix it quickly” button really cost?
Let’s start with a simple example
Imagine marketing sends the software house a message:
“Hey, we just need to change the text on the button. Instead of ‘Check the offer’ it should say ‘Discover the offer’. It’s a small thing — please just do it quickly.”
Sounds trivial. But from the technical team’s side it can look completely different.
A developer must:
1. Analyze the request
Where is that button located?
Is it only in one place?
Does it appear in several versions of the page?
Is the text hard-coded?
Is it managed by a CMS?
Does the change concern desktop and mobile versions?
Is the button part of a component used elsewhere?
2. Make the change
Change the text.
Refactor the component.
Update content in the CMS.
Or modify the code.
3. Check the result
Does the button still look right?
Does the text overflow its area?
Does everything work on mobile?
Has the change affected other places?
4. Test
Can you click it?
Does the link point to the right place?
Has any error appeared?
5. Deploy the change
If the change requires a deploy, it needs to go to production.
And suddenly it turns out that: “Just changing text”
doesn’t necessarily mean: “Just 5 minutes of work”.
How much can one small change cost?
Let’s assume a very conservative scenario.
The developer spends:
- 15 minutes analyzing,
- 20 minutes implementing,
- 15 minutes testing,
- 10 minutes preparing and deploying.
Total: 60 minutes of work.
And here we reach an important point. If the team’s hourly rate is, for example, 200 zł net, one seemingly minor change costs roughly: 200 zł net.
But that’s not all. In the real process there may be:
- task handovers,
- scope clarifications,
- questions to the client,
- waiting for answers,
- the reporter checking the result,
- fixes after feedback,
- re-deployment.
One hour can thus very easily become two. And one small change can turn into several hours of the whole team’s work.
The most expensive part isn’t executing the change
This may sound paradoxical. Sometimes performing the task itself takes 10 minutes. But preparing for it takes another 20. Then there are tests, deployment, communication, and context switching.
And that last element is often the most underestimated.
Context switching — the hidden cost of small tasks
A developer is working on a large feature. They have code open and are focused.
Suddenly a message appears: “Hey, just a small thing. Can you fix the button?”
The developer interrupts their work. Opens the ticket. Checks the page. Searches the code. Makes the change. Tests. Deploys. Returns to the previous task...
And then they have to remember: “What was I actually working on?”
This is context switching, and it can be very costly. Not because each individual change requires a lot of work, but because each change interrupts the thought process.
The more complex the task, the higher the cost of returning to it. So 10 micro-tasks aren’t always 10 × 10 minutes. In practice it can be much more.
One button is nothing. A hundred buttons is a process.
Assume the company sends the technical team:
- 20 small changes per month,
- each taking on average 45 minutes.
That gives: 15 hours of work per month.
At a rate of 200 zł net: 3000 zł net per month.
Annually: 36,000 zł net.
And we’re only talking about 20 small tasks per month. No major features. No product development. No new modules. No integrations. No design.
Just: “change this”, “fix that”, “move this”, “add that”, “remove this”.
Now imagine an organization with 50 such tasks per month. Or 100.
The scale suddenly looks completely different...
Micro-tasks have another cost — they block development
This is one of the most important parts of the whole picture.
If the development team spends 20% of its time on small fixes, it cannot spend that 20% on product development. Sounds obvious. But in practice this is often not visible.
The company asks: “Why isn’t the new feature ready yet?”
The developer answers: “We had many ongoing topics.”
“Like what?”
“Fixes, small changes, updates, minor tasks.”
Each of them was small. But together they created a huge work block. It’s a bit like phone notifications. One notification doesn’t bother you. Ten — somewhat. A hundred? Suddenly you realize you spent the whole day reacting.
Micro-tasks are similar.
“Small task” isn’t always a small task
It’s also worth understanding that not every change is the same. Changing text in a CMS may indeed take a few minutes.
But changing text in an application can require:
- finding the component,
- changing code,
- updating translations,
- running tests,
- rebuilding the app,
- deploying.
Changing one field can require modifications to:
- front-end,
- back-end,
- database,
- API.
Changing a single element in the system can affect other elements.
Therefore the question “How long will changing this button take?”
often has no sensible answer without knowing the system architecture.
You first need to check. Only then can you estimate.
Why does a developer sometimes say: “I need to check this”?
It’s not avoidance. It’s often a sign of professionalism.
A good developer should not promise: “Sure, five minutes.”
if they don’t know what’s under the hood.
They should say: “I’ll check where this element is used and let you know.”
That may take 10 minutes. But those 10 minutes can save several hours of problems. Because the most expensive change is often not the one that takes an hour.
The most expensive change is the one that:
- breaks another function,
- causes a production error,
- requires an urgent rollback,
- generates follow-up tickets,
- requires intervention from several people.
Therefore analysis before changing is part of the work, not a waste of time.
How can a client reduce micro-task costs?
It’s not about stopping reporting small changes. Small changes are a normal part of product development. It’s about managing them well.
1. Group small tasks
Instead of sending:
“Change the button.”
“Also fix the header.”
“And by the way add this link.”
“And move this element.”
It’s better to collect them into one batch.
The team can then make several changes in one work cycle.
Less context switching.
Less communication.
Fewer deployments.
Lower cost.
2. Set priorities
Not everything is urgent.
If everything is labeled:
URGENT
then nothing is really urgent.
It’s worth dividing tasks into:
- critical,
- important,
- planned,
- cosmetic.
This helps the team work more efficiently.
3. Consider whether the change needs code
If the company regularly changes:
- texts,
- images,
- banners,
- links,
- messages,
maybe the problem isn’t the developer’s speed.
Maybe the problem is the architecture.
If each content change requires a developer, consider a CMS or admin panel.
A well-designed system should allow business users to manage what truly doesn’t require a developer’s intervention.
A good system should answer: who should make this change?
This is a very important design principle. Not every change should go to a developer.
If marketing can independently:
- change text,
- replace an image,
- add an article,
- reorder sections,
then there is no point involving a developer.
A developer should deal with what requires their skills.
Namely:
- creating new features,
- system development,
- integrations,
- optimization,
- security,
- architecture,
- resolving technical problems.
Otherwise the company starts paying developers to do work that a system user could do.
It’s a bit like hiring a car mechanic to fill up the tank. They can do it — but is it really necessary?
When is it worth saying: “Let’s do this differently”?
If the same request appears regularly, it’s worth pausing and asking:
Why do we have to do this manually every time?
If we ask to change the same element every week, maybe we should create:
- a CMS setting,
- a configuration,
- an admin panel,
- automation,
- a self-service mechanism.
The one-time cost of building such a solution may be higher. But later each subsequent change may take seconds instead of hours.
This is the difference between: paying for each change and investing in a system that allows changes to be done independently.
Micro-tasks and cooperation models with a software house
This is also an important topic for clients.
If cooperation with a software house is based solely on the model: “you report — you estimate — we accept — you execute”, every small change can generate additional organizational overhead.
That’s why for ongoing cooperation the following often work better:
- hour packages,
- maintenance subscription,
- a dedicated team,
- a task backlog,
- regular sprints,
- agreed deployment windows.
This doesn’t mean every client should choose the same model. It’s about matching the cooperation method to the project’s nature.
If a company needs one change per month, a complex process may be unnecessary. If a company sends 50 tasks per month, lack of process can be very costly.
Should every change be billed?
It depends.
In some projects, billing every minute precisely makes sense. In others it creates more administration than savings.
That’s why it’s worth looking at cooperation more broadly.
The most important question isn’t: “How much did this one change cost?”
A better question is: “How much does the way we manage all changes cost us?”
If a company pays 200 zł for one change but avoids errors and has confidence that everything works correctly, that may be a reasonable cost.
If, however, each month the company pays several thousand zł for dozens of similar micro-tasks, it’s worth considering whether the problem can be solved systemically.
The most expensive words in IT?
Perhaps they are: “It’s only a small change.”
Not because small changes are bad. They are necessary.
A digital product lives. Customer needs change. Markets change. Marketing changes. Technology changes. Changes are natural.
The problem starts when an organization doesn’t see their cumulative cost.
One small change? — No big deal.
Ten? — Still not much.
A hundred? — That’s a process.
And if there are dozens of such processes? Suddenly a company realizes it isn’t spending money on product development — it’s spending it on continually fixing little things.
Instead of counting buttons, let’s count time
Well-managed digital product development isn’t about forbidding the client from reporting small changes.
It’s about knowing:
- which changes really require a developer,
- which can be done independently,
- which are worth automating,
- which should be grouped,
- which are truly urgent,
- which can be planned,
- which are worth solving systemically.
Because sometimes the best answer to: “Fix it quickly.”
is not: “Okay, we’ll do it.”
but: “Let’s think about why we’ll have to fix this again in a month.”
This is where a software house stops being only an executor of tasks and becomes a technology partner. A good partner not only implements requests.
They also help to see that sometimes the cheapest change is not the one we do faster. The cheapest is the one we won’t have to do for the hundredth time.
And that’s precisely why one “Fix it quickly” button can cost an hour.
But a well-designed system can make it so the next hundred similar changes you perform yourself in minutes.
This isn’t about saving on developers. It’s an investment in better processes, better architecture, and smarter use of the whole team’s time.
