A feature can look small from the user's side and still require changes across several parts of a web application.
Login and signup are a good example. The visible result might be two new screens, but the application may also need authentication, user records, password recovery, permissions, email verification and changes to how existing data is associated with users.
That extra work is easy to miss when a feature is described only by what appears on the screen.
We run into this fairly often when scoping web applications at retroXpect. A client might ask for something that sounds like a minor addition, then we start tracing what needs to change behind it and find that it touches the frontend, backend, database and existing workflow.
This article explains where that extra work comes from.
For a broader overview of project pricing, see our web application development cost guide for Singapore.
A Small Feature Can Touch the Whole Application
Most web applications have several layers working together.
The interface is the part users see, but there is usually application logic running behind it, a database storing information, APIs moving data between different parts of the system, and permissions controlling who can access what.
A new feature may affect only one of those layers. Quite often, it affects several.
Take a button that allows a manager to approve a job.
The frontend needs the button and its different states. The backend needs an endpoint or function that processes the approval. The database has to record that the job has been approved, who approved it and potentially when it happened.
Other parts of the system may also depend on that status. The approval could trigger an email, unlock the next stage of the workflow or make the job visible to another user.
The button itself is easy. The workflow attached to it is where most of the work sits.
Login and Signup
Login and signup are among the most common examples we see.
Clients sometimes ask to add user accounts after the initial application has already been scoped. From the outside, it looks like a small addition because the user mainly sees a registration form and login page.
Once accounts are introduced, we need to decide how those accounts behave.
The application may need to handle:
- Account creation
- Authentication
- Password resets
- Email verification
- Sessions
- User-specific data
- Access permissions
Existing parts of the application may need changes as well.
Suppose the original system stores customer enquiries without any concept of a logged-in customer. After adding accounts, those enquiries may need to belong to specific users. The database changes, the API changes and the frontend needs to know which records belong to the person currently signed in.
If different users have different levels of access, the scope grows further.
A request for "login and signup" can therefore turn into a much larger account system once the requirements are properly mapped.
User Roles
Adding another user role can have a similar effect.
Our electronic bunker survey project is a useful example. The system had several different roles, and each role had its own dashboard and responsibilities within the survey process.
Adding a role was not simply a matter of copying the dashboard and changing a few buttons. The application had to understand what that user was allowed to see, which actions they could perform and where they fit into the overall process.
Permissions also have to be enforced in the backend.
If a normal user should not be able to view an administrator's records, hiding the admin page from the navigation menu is not enough. The API itself must reject requests from users who do not have permission.
More roles also mean more combinations to test.
A workflow that behaves correctly for administrators may behave differently for staff or customers. Each path needs to be checked.
This is one reason applications with several user roles can take noticeably longer to build even when the dashboards themselves look fairly simple.
Workflow Changes
A small change to a workflow can spread further than expected because later steps may depend on earlier ones.
Imagine an application where a job moves through:
Created → Assigned → Completed
A client later asks for an approval stage before completion:
Created → Assigned → Pending Approval → Completed
That looks like one extra status.
The change may affect the database, the interface, notifications, reports and any logic that previously assumed an assigned job could move directly to completed.
If administrators can reject the approval, another path appears. The system then needs to know what happens after rejection and who is allowed to resubmit the job.
Existing records may also need to remain compatible with the new workflow.
Changes like this are common in business applications because the software gradually starts reflecting more of the company's real operating process.
Admin Tools
Admin features tend to look smaller from the client's side because they are not part of the main customer experience.
A request such as "let the admin edit the user" can involve more decisions than expected.
Which fields can the administrator edit? Can they change the user's email address? Can they reset passwords? Can they deactivate the account? Should changes be recorded somewhere?
The answers depend on the application.
A simple admin function may genuinely be quick to build. A group of small admin requests, however, can eventually turn into a fairly substantial internal dashboard.
This is why "admin panel included" in a software quotation can be surprisingly vague. Two projects can both have an admin panel while containing completely different amounts of functionality.
Integrations
Features involving another platform have an extra dependency: we do not control the other platform.
Suppose an application needs to send information to an accounting system after a job is completed.
The basic flow may be straightforward, but we still need to work with the external API, handle authentication and map our application's data into the format the accounting platform expects.
Failure handling also matters. If the external platform is unavailable when the request is made, we need to decide what happens to the transaction.
Some integrations can be completed quickly because the API is well documented and the workflow is simple. Others take longer once we start dealing with restrictions, unusual data formats or missing functionality.
Our API integration cost guide covers this area in more detail.
Data Changes
Changes to the database deserve more care once an application is already running.
Adding a new field to an empty application during development is usually straightforward.
Adding the same field after thousands of existing records have been created may require us to decide what value those existing records should have and whether anything else in the application depends on it.
More substantial changes can require a data migration.
For example, an application may originally store one contact person per company. A later requirement might allow each company to have several contacts.
The database model now needs to change from one contact field into a proper relationship between companies and contacts. Existing data has to be moved into that structure, and anywhere that previously assumed one contact per company may need updating.
The user may only see an "Add another contact" button.
The underlying change is much larger.
Existing Features Can Be Affected
The cost of adding a feature also depends on how much existing functionality it touches.
Consider a booking system that already supports cancellations.
A client later adds deposits.
The cancellation workflow now needs to understand what happens to the deposit. Does the customer receive a refund? Is part of it retained? Does the answer depend on how close the cancellation is to the booking date?
The reporting side may need changes because revenue and refunds are now handled differently.
A feature rarely exists completely on its own once the application has matured.
This is one reason adding something to an existing system can occasionally take longer than building the same feature into a new application from the beginning.
Testing Gets Bigger Too
Development time is only part of the change.
The affected workflows also need to be tested.
If we add a new user role, we need to check what that user can access and make sure existing roles still behave correctly. If a payment flow changes, successful transactions are only one part of the testing. Failed and cancelled payments need to behave properly as well.
The amount of testing depends on the consequence of something going wrong.
A small visual adjustment does not need the same level of checking as a change to access permissions or payment processing.
As applications become more interconnected, the chance of one change affecting something elsewhere also increases.
The Existing Codebase Matters
Two clients can ask for the same feature and receive different estimates because their existing systems are different.
In a well-structured application, the code needed to support the new feature may already be organised in a way that makes the change straightforward.
Another application might have tightly connected components or assumptions that were made years earlier. The developer may need to refactor part of the existing system before the new feature can be added safely.
This is particularly common when taking over older applications.
Before quoting a significant change, we may need to inspect how the current application is structured rather than estimating purely from the requested feature.
How We Estimate Small Changes
For us, the useful part of estimating a change is tracing what it actually affects.
If a client asks us to add a feature, we look at the existing flow and identify which parts of the application need to change.
For example, with login and signup we would need to understand:
- Who is creating an account?
- Are there different types of users?
- What information belongs to each user?
- Which parts of the application require login?
- Do existing records need to be connected to new accounts?
- Does an administrator need to manage those accounts?
A very simple implementation may still be a small change. If those answers introduce permissions, account management and changes to existing data, the estimate will reflect the additional work.
This is also why we prefer understanding the requirement before giving a number.
How to Keep Change Requests Smaller
The clearest way is to describe what you are trying to achieve rather than prescribing the feature immediately.
If the requirement is "customers need to see their previous jobs", adding a complete account system is one possible solution. There may also be a simpler way to achieve the same result depending on the application.
The development team can only make that judgement if they understand the purpose of the request.
It also helps to group related changes together. If user accounts are going to be introduced soon, it makes sense to consider the related permissions and user-specific data at the same time rather than changing the account structure repeatedly over several releases.
For completely new applications, our software development requirements checklist can help identify these requirements earlier.
Frequently Asked Questions
Why can login and signup be expensive?
Login and signup may introduce authentication, account management, password recovery, user-specific data and permissions. Existing parts of the application may also need to be changed so they understand which user owns each record.
Does every small feature become expensive?
No. Plenty of changes are genuinely small.
The cost increases when the feature has dependencies elsewhere in the application or changes an existing workflow.
Why does adding another user role cost more?
A new role may need its own interface, permissions and workflow. It also creates additional paths that need to be tested.
Is it cheaper to include features during the original build?
Sometimes.
A feature can be easier to incorporate when the application is originally designed around it. Adding the same requirement later may involve changing existing data or workflows.
That does not mean every possible future feature should be built from the start.
How do developers estimate a feature change?
We normally look at which parts of the current application are affected, how much new logic is required and how much testing the change needs.
Final Thoughts
When a feature request receives a higher quote than expected, the useful question is what has to change behind the interface.
Login and signup might introduce an account and permission system. A new approval button might alter an existing workflow. One extra user role may need changes across several screens, APIs and access rules.
Some requests really are small. Others only look small because most of the work happens somewhere the user never sees.
Understanding those dependencies makes software quotations much easier to evaluate.
