"Can you just add a button?"
It's one of the most common requests in software development. And on the surface, it sounds reasonable. A button is small. It's visible. It looks like it should take an hour or two.
So when developers come back with an estimate of days or weeks, clients are sometimes shocked. The quote feels inflated. The timeline feels padded. Surely it can't be that complicated?
But here's the thing: it usually is.
Let's take a real example. A client asked us to add a "Cancel" button to their event management platform. One button. How hard could it be?
Here's what that button actually required.
The UI work was the easy part. Adding the button itself, positioning it correctly, handling loading states, showing confirmation dialogs, displaying success or error messages. Maybe half a day.
The backend was where things got interesting. Cancelling an event isn't just flipping a status. It triggers a chain of consequences. In this case, we needed to figure out everyone who should be notified: people who had registered, event organisers, partner venues. Each group needed a slightly different email with different content. We had to ensure nobody received duplicate messages. That meant building email handlers for every case, creating templates for every recipient type, and passing different data to each template.
The database needed updates too. We added history records to every entity that got affected, so there was a clear audit trail of what happened and when. Some records needed soft deletes (marked as cancelled but kept for reporting), others needed hard deletes. Each decision had downstream implications.
The API layer required a brand new endpoint with request validation, response formatting, documentation, authentication checks, and permission logic to control who could actually cancel an event.
Testing covered unit tests for the business logic, integration tests for the email flows, and end-to-end tests for the full user journey. Edge cases needed coverage too. What happens when you cancel an event with no registrations? What about one with hundreds?
That "simple" button took one developer a full week to build properly.
This pattern repeats constantly in software development. The features that look simplest from the outside often carry the most hidden complexity.
"Add a filter" sounds easy until you realise it needs to work with pagination, preserve state across page refreshes, handle multiple filter combinations, and not destroy performance on large datasets.
"Let users export to CSV" sounds like an afternoon until you factor in formatting edge cases, memory limits on large exports, background job processing, and handling special characters that break spreadsheets.
"Add a search bar" sounds trivial until you need fuzzy matching, relevance ranking, indexing for performance, and handling searches that return thousands of results.
The visible part of a feature (the button, the input field, the link) is usually about 10% of the work. The other 90% is infrastructure, validation, error handling, testing, and making sure the new code plays nicely with everything that already exists.
At Shape, we build software to last. That means every new feature follows the same patterns as the rest of the codebase. New API handlers. New commands. Proper dependency injection. Unit tests. End-to-end tests. Audit logging where appropriate.
This takes longer upfront. But it means the codebase stays maintainable. It means bugs get caught before they reach production. It means the next feature is easier to add, not harder.
Cutting corners on a "simple" button creates technical debt that slows everything down later. We've seen codebases where years of "just add a quick button" decisions have made even minor changes take weeks because nobody knows what will break.
When your development team gives you an estimate that feels high for something that looks simple, they're probably not padding the numbers. They're accounting for everything the feature actually needs to work reliably.
The best thing you can do is ask them to walk you through it. A good developer will happily explain where the time goes. And once you see the full picture, the estimate usually makes a lot more sense.
Trust your developers. Simple-looking features have hidden depth. And good software requires proper infrastructure to stay good.
