There is a specific phrase that makes every developer's stomach drop slightly: "it should just be a quick fix, right?" Sometimes it is. More often, the small visible change is sitting on top of something much less small underneath.
Why "small" and "quick" aren't the same thing
A button that needs to move three pixels to the left might genuinely take three minutes. A button that needs to "just also send an email when it's clicked" can mean touching authentication, data validation, third-party services, and testing across every place that button appears. The size of a change on screen has almost no relationship to the size of the change underneath it - which is exactly why estimating software work badly is such a universal industry problem, not just a Nimble IO one.
Where the myth comes from
Most of us have watched someone change a setting on a phone in ten seconds and reasonably assumed all software changes work like that. Consumer apps spend enormous effort making simple things look simple. Bespoke business software, built for a specific messy workflow, doesn't always have that luxury - especially when it's connecting several other systems together.
What helps
Two things, mostly. First, asking "what does this actually need to do" rather than "can you just" - the former gets you an honest answer, the latter invites an optimistic one. Second, working with developers who tell you the truth about scope up front rather than the answer that gets the call to end faster. We talk a bit about how we handle scoping and estimates on our FAQ page, mostly because we got tired of giving the same honest-but-unwelcome answer on calls.
The verdict
Some things really are quick fixes. The ones that aren't tend to announce themselves with the words "can you just," so treat that phrase as a mild warning sign, not a guarantee.