Almost every software project that blows its budget dies the same way: not from one big disaster, but from a hundred small "can we just add" requests that nobody wrote down. Scope creep in software projects is the slow leak that sinks the ship while everyone is watching the horizon for storms.
I have sat on both sides of this. I have been the vendor who watched a clean estimate balloon, and I have been the technical partner brought in to explain to an owner why the "simple app" is now three months late. The honest answer is uncomfortable, because both sides usually contribute to the mess.
Let me lay out how it really happens, and then give you the one habit that stops it. This is not about blame. It is about visibility.
Both Sides Cause It, and Both Sides Pretend They Do Not
Scope creep is a shared crime. Here is each party's contribution.
The client adds "small things." Individually, every request feels trivial. "Can we also let admins export to Excel?" "Can the login remember the device?" "While you are in there, can you add a second language?" None of these feels like a big deal to someone who is not writing the code. Stacked together, they are a second project.
The vendor underprices to win the deal. This is the part vendors rarely admit. To beat a competitor, a vendor quotes the happy path and quietly assumes nothing will change. When change inevitably arrives, they are already behind on a thin margin, so they either absorb the work resentfully or spring surprise costs late. Both poison the relationship.
Nobody logs the changes. This is the real culprit. Because the small requests arrive verbally, in a WhatsApp thread, in a hallway, they are never counted. There is no running tally. So when the project is late and over budget, each side genuinely believes the other is at fault. They are both right, and neither can prove it.
Why "Small" Requests Are Rarely Small
A request that sounds like a sentence often costs a week. "Add a second language" is not a translation task. It touches every screen, every date format, every email template, every error message, plus testing all of it twice. The person asking cannot see that iceberg, and that is fair. It is the technical side's job to surface it.
When the true cost stays invisible, the client keeps asking because the requests appear free, and the vendor keeps saying yes because saying no feels like bad service. The scope grows precisely because nobody is forced to look at the price tag at the moment of the ask.
The Habit That Stops the Bleed: A Visible Change Log
The fix is almost embarrassingly simple. Every change request, however small, goes into one shared log with a cost attached, before any work starts. Not after. Not "we will sort it out later." At the moment of the ask.
The cost does not always have to be money. It can be time, or it can be a trade. But it must be visible and it must be agreed. Here is the template I hand to clients. It lives in a shared sheet both sides can see:
| # | Date | Request | Requested by | Est. effort | Cost | Impact on timeline | Decision |
|---|---|---|---|---|---|---|---|
| 1 | 13 Mar | Add Excel export for admin | Owner | 2 days | Rp 3,000,000 | +2 days | Approved |
| 2 | 15 Mar | Second language (Bahasa) | Owner | 8 days | Rp 12,000,000 | +2 weeks | Deferred to phase 2 |
| 3 | 16 Mar | Remember device on login | Owner | 1 day | Rp 1,500,000 | +1 day | Approved |
That is the whole discipline. Three things make it work:
- Every request is logged, even the tiny ones. The log's power is that it makes the accumulation visible. The owner sees "row 12" and finally understands where the timeline went.
- A cost is attached before work begins. This is not a threat. It is information. Owners make excellent decisions when they can see the price. Many "must-have" requests quietly become "phase 2" the moment a number appears next to them.
- The decision is recorded. Approved, deferred, or rejected, in writing. Now nobody argues later about what was agreed.
What Changes When the Log Is Visible
The behavior shift is immediate and it goes both ways.
Clients stop firing off casual requests because they can now see the running total, and they start prioritizing like the budget owners they are. The conversation moves from "can you add this" to "is this worth two days and Rp 3,000,000 right now, or does it wait." That is a healthy conversation.
Vendors stop absorbing silent scope and stop springing nasty surprises, because the log forces the cost conversation to happen early, when it is cheap, instead of late, when it is a fight. Trust goes up on both sides because there are no hidden ledgers.
This is really a scoping discipline, and it starts before the project does. The cleanest way to avoid creep is to scope tightly in the first place, which I cover in MVP Scoping: What to Cut First and What to Never Cut. And whether you build custom at all is a prior question worth answering in Build vs Buy Software: How to Actually Decide.
The Practical Takeaway
Scope creep in software projects is not a vendor problem or a client problem. It is a visibility problem, and it has a cheap cure.
- Open one shared change log at the start of every project.
- Log every request, no matter how small it sounds.
- Attach an honest cost and a timeline impact before work begins.
- Record the decision in writing.
You will still change your mind during a build. That is normal and often correct. The goal is not to freeze scope. It is to make sure that every time it grows, both sides chose it with open eyes. If you want someone who runs projects this way by default, that is the kind of discipline I bring to a technology partnership.