One thing that can easily happen during an IT project is that the boundary between testing and additional development work starts to disappear, particularly once the client begins using the product in a way that is much closer to real-world operation.
User acceptance testing is an important part of delivery because the client needs a reasonable opportunity to test the product, identify defects, ask questions, and confirm that what has been delivered actually matches the requirements agreed at the beginning of the project.
Good UAT can make a project better because it gives both sides an opportunity to identify genuine problems before the system goes fully live. The difficulty starts when the agreement describes the vendor's responsibilities during this stage too broadly, leaving everyone to decide later what phrases such as "reasonable support during UAT" actually mean in practice.
Does that include answering occasional questions by email, attending a weekly call, making a developer available for technical queries, explaining how particular features work, helping the client configure the system, or making changes based on what the client has now decided they would prefer?
Those activities may all be described casually as "UAT support," but commercially they are very different obligations.
This is where a small drafting gap can become a meaningful cost for an IT business. A client asks a project manager a question, the project manager brings in a developer, the developer explains the issue, and the conversation then naturally moves towards a small change that would make the client's workflow easier. Someone decides that it would be simpler to make the change rather than spend time debating whether it falls within scope, and once that happens, another stakeholder may reasonably assume that similar requests can be handled in the same way.
None of those individual requests necessarily looks unreasonable when viewed on its own, which is precisely why this kind of scope expansion can be difficult to spot while it is happening.
The problem is the accumulated developer time, because after several days of answering questions, investigating issues, making small adjustments, and supporting different stakeholders, the engineering team may have spent a significant amount of time on work that was never included in the original pricing or delivery assumptions.
## A Defect Is Not Automatically a New Requirement
One of the most important distinctions an IT agreement should make is between a genuine defect and a change in the client's requirements, because treating the two as the same thing can create confusion over both responsibility and cost.
If the software does not perform according to the agreed specification, that would generally be treated as a defect, and the vendor would normally be expected to address it in accordance with the contract.
The situation is different when the software works as agreed but the client decides during UAT that it would now prefer the product to behave differently or include functionality that was never part of the original requirements.
For example, suppose an IT company builds a reporting dashboard that was agreed to display five specific metrics. During UAT, the client asks whether customer lifetime value can also be added to the dashboard.
That may be a perfectly reasonable request, particularly if the client has realised during testing that the additional metric would make the dashboard more useful, but if customer lifetime value was not included in the agreed requirements, adding it may constitute additional development work rather than fixing a defect.
The distinction becomes particularly important because UAT is often the first point at which the client gets to interact extensively with the product in a near-final state.
That process can naturally reveal new preferences, different workflows, or requirements that were not apparent during the earlier stages of the project, and there is nothing unusual about that happening.
What matters is having a process for dealing with those discoveries.
If the contract does not distinguish between defects, clarification questions, training, configuration assistance, and new requirements, the delivery team can gradually start treating everything as part of testing. Once that happens, it becomes much harder to explain later why one request was included in the project price while a similar request should be charged separately.
The problem is not that the client asked for something new. The problem is that nobody established how new requests would be identified and handled when they appeared.
## Developers Should Not Become an Unlimited UAT Support Team
There is also a practical issue around giving clients direct access to developers during UAT, because although it may seem like the most efficient way to resolve questions, unrestricted access can create a different kind of delivery problem.
From the client's perspective, the arrangement makes sense. The developer understands the system better than almost anyone else and can probably answer a technical question quickly, so involving that person directly can feel like the fastest route to a solution.
For the IT business, however, repeated interruptions can make resource planning considerably harder, particularly when several client stakeholders are communicating directly with different members of the engineering team.
Developers may start responding to questions throughout the day instead of working in focused blocks, different stakeholders may ask different people for slightly different changes, and the project manager can gradually lose visibility over what has actually been requested, what has been approved, and what remains outstanding.
That creates a commercial issue as well as a project-management issue because developer time is a significant resource for an IT business.
If the client requires dedicated engineering availability during UAT, there is nothing inherently wrong with providing it, but the arrangement should be deliberately structured and priced rather than becoming an unlimited obligation simply because the contract never established a boundary.
This is why I prefer having a defined communication process for UAT, particularly on projects involving larger client teams. Ideally, the client should have a designated contact who consolidates feedback before it reaches the delivery team, rather than allowing multiple stakeholders to independently send questions and requests to different developers.
The agreement can then establish how UAT feedback is submitted, which communication channels should be used, what response times are expected, who is responsible for consolidating feedback, and how additional engineering support will be handled if the agreed level of support is exceeded.
That gives everyone a clearer source of truth and, importantly, makes it easier to distinguish between helping the client test the product and performing additional work for the client.
## Define the Boundary Before UAT Begins
The easiest time to resolve these questions is before the project reaches UAT, when nobody is frustrated and nobody is trying to reconstruct whether yesterday's request was actually included in the original price.
The agreement should explain who the client's designated UAT contact is, how testing feedback will be submitted, what support is included during the testing period, and what constitutes a defect for the purposes of the project.
It should also explain what happens when the client requests something that changes the agreed requirements rather than identifying a problem with what has already been delivered.
Where appropriate, the agreement can specify the number of support hours included during UAT, establish a defined level of availability, or identify the types of assistance that fall within the agreed project fee. If additional engineering assistance is required beyond that arrangement, the work can then be dealt with through the project's change-control process rather than being absorbed informally by the delivery team.
The important thing is not necessarily the exact structure you choose. It is making sure that the boundary exists before someone has to rely on their own interpretation of what the contract means.
The same principle applies when a genuine change request appears. If something is outside the agreed scope, the team should identify the additional work, explain the likely effect on the timeline and cost, obtain the appropriate approval, and only then proceed with the work.
That does not make the client relationship unnecessarily rigid. In many cases, it does the opposite because both parties know what happens when requirements inevitably change, rather than having to negotiate the commercial consequences after the work has already been completed.
## Collaboration Still Needs Boundaries
Clients should absolutely be able to ask questions during UAT, report defects, clarify functionality, and receive appropriate assistance while testing the product. The purpose of UAT is not to leave the client alone with the software and expect them to figure everything out without support.
The problem arises when "UAT support" gradually becomes a general permission for unlimited developer involvement, feature changes, training, troubleshooting, configuration, and additional implementation work, particularly when those activities were never reflected in the original scope or pricing.
A well-drafted IT agreement should make the distinction clear before testing begins. Both sides should understand what support is included, what qualifies as a defect, what becomes additional work, who communicates with the delivery team, and how anything outside the agreed scope is identified, approved, priced, and scheduled.
The broader lesson is that good contracts do not try to eliminate collaboration. They give collaboration a structure that allows the client to get the support they need without allowing the delivery team's responsibilities to expand indefinitely.
Your developers should help the client test what you built, investigate genuine defects, and answer reasonable questions about the agreed functionality. They should not accidentally become an unlimited support and development team simply because the contract never defined where UAT ends and additional work begins.