How do you accept a web application or a completed project stage?

Application acceptance should not consist of random clicking and a loose collection of comments. Start with the agreed scope and list the most important scenarios: who performs the action, which data they use, what result they should receive and what should happen in an exceptional situation.

Record every result in one place. Separate comments into a scope mismatch, a test blocker, an unclear agreement or a new need. Only then can you consciously accept the stage, accept it conditionally or identify items that must be corrected.

Acceptance criteria are best agreed before development starts. If that did not happen, both sides can still describe the expected behaviour before testing. This should not be used to quietly extend the original scope.

First confirm what you are accepting

The starting point is the agreed result, not everything the application might do in the future. Collect the proposal, stage description, approved changes and items explicitly excluded from the scope. If the agreements are spread across messages and documents, prepare one summary of the binding version before acceptance begins.

The summary should include:

• the problem this stage was meant to solve;
• the functions and processes included in scope;
• users and their roles;
• data, files and integrations required for operation;
• items explicitly excluded;
• the person authorised to make the acceptance decision;
• examples or criteria that show the stage has been completed.

When a company is accepting the first part of a larger system, it should not assess it against features planned for the future. It should, however, verify that this stage delivers the result described in the proposal. How do you choose a web application development partner? explains why these rules should be agreed before cooperation starts.

Prepare acceptance scenarios

An acceptance scenario describes a real user task. It does not need to be technical documentation. It should answer five questions:

1. Who performs the action?
2. What is the starting state?
3. Which data do they use?
4. Which steps do they take?
5. What result should appear in the application and connected systems?

Write down the main path first. Then add the most important exceptional situations that can genuinely occur. Depending on the solution, these may include a missing required field, repeating the same action, duplicate data, insufficient permissions or an unavailable external system.

There is no universal number of scenarios. A simple form requires a different level of verification than a system with several roles, payments and integrations. The number of tests should follow the agreed scope, the importance of the process and the consequences of failure.

Agree safe data and a testing environment

Before testing, decide where it will take place and which data may be used. The safest starting point is a test environment with demonstration data or a properly prepared sample.

Do not put passwords, API keys or full customer records into an ordinary issue spreadsheet. If an action can send a message, create an accounting document, change stock or trigger a payment, confirm first that the test will not have real consequences.

Record:

• the address or name of the environment;
• the application version submitted for acceptance;
• the date and approximate time of the test;
• the role of the account used;
• the test data set identifier;
• active integrations and functions deliberately disabled.

This allows the developer to reproduce a problem. Without these details, the same scenario may produce a different result because the version, configuration or data have changed.

Record results in one table

Screenshots sent individually through several channels quickly lose their context. A shared table is more useful when every important comment has an owner and a decision.

The table organises communication, but it does not replace the developer's technical tests. It is not a full security or performance audit either. If those areas affect the acceptance decision, they need their own scope and criteria.

Separate a defect, blocker and new need

Many misunderstandings begin when all comments are placed on one list as “bugs”. Four types of comment require different decisions.

Not every user comment is a defect. That does not mean it should be ignored. Every important comment should receive a classification, a response and information about the next action.

Check roles, permissions and exceptions

The main path is not enough when an application has several user groups or performs actions with important consequences. During acceptance, check at least the key boundaries:

• whether users see only the data intended for their role;
• whether an unauthorised operation is blocked by the system, not merely hidden in a menu;
• whether invalid or incomplete data produces a clear message;
• whether the system remains in a safe and understandable state after an error;
• whether repeating an operation avoids an uncontrolled duplicate;
• whether the expected behaviour is known when an external integration does not respond.

This check does not replace a web application security audit. It only shows whether the main process follows the agreed scope and avoids exposing obvious actions to the wrong role. The technical security review should reflect the type of data and the consequences of a failure.

Example of one acceptance scenario

Assume a stage should allow a work order to be created from an approved customer order. This is a synthetic example, not a description of a finished product or a client implementation.

This description makes the result testable without discussing implementation details. If the test fails, it is clear whether the problem concerns the main result, a repeated operation or missing data handling.

Accept larger projects in stages

Leaving all tests until the end of a project increases the number of unknowns handled at once. For a larger scope, it is better to accept each area when it is stable enough for reliable verification.

Before the next round:

• close earlier comments or record their current status;
• identify one application version for testing;
• repeat the corrected scenario;
• retest the most important neighbouring actions that may have been affected;
• move new ideas to a separate future-development list.

We do not impose one method on every project. Acceptance should reflect the scope, risk and the client's way of working. In our work, we separate the agreed stage result from later ideas so that both sides make decisions against the same list.

Make one explicit decision after acceptance testing

A list of comments is not yet a decision. At the end of an acceptance round, clearly select one of three results.

Accepted

The agreed criteria are met. Other ideas or functions excluded from the stage are moved to future development.

Accepted conditionally

Clearly described items remain, but they do not block the agreed use. Each item has an owner, a date or an agreed next action. This option should follow the parties' agreement rather than appear automatically.

The submitted scope is not accepted

An important agreed scenario does not work or cannot be verified reliably. Specify the exact result, data and condition for a repeat test instead of only stating that “the application is not ready”.

The effect of acceptance on payment and the contract depends on the particular agreement. This article is not legal advice or a formal acceptance protocol template.

Check operational readiness before deployment

An accepted scope is not always ready for safe release. Before deployment, agree:

• who performs the deployment and when;
• whether a current backup and a practical rollback option exist;
• who provides missing configuration, accounts and access;
• which important operations will be monitored after launch;
• who makes a decision on the client and developer side if a problem occurs;
• where and during which hours urgent issues are reported.

Response times, support hours and additional availability become commitments only when they are written into the proposal or contract. The application and online store maintenance page explains how these responsibilities can be separated.

Make sure the stage is handed over properly

Before closing the work, confirm what the company receives in addition to access to a working application. Depending on the project, this may include:

• access to the application, repository and relevant accounts;
• instructions required by users or administrators;
• information about dependencies, licences and external services;
• known limitations and decisions postponed for later;
• agreed information about backups, deployment and maintenance;
• acceptance results and a list of future ideas.

If acceptance is connected with changing a developer or taking over a complete system, use the application handover checklist. It helps verify code, data, accounts, infrastructure and documentation. The tool does not automatically send the information you enter.

Frequently asked questions

Who should accept the application on the company side?

Choose someone who knows the process and can confirm the expected result. For an important system, combine the process user's knowledge with the decision of the person responsible for scope. The developer should not be the only party confirming their own work.

Can acceptance be performed without technical knowledge?

Yes, when scenarios describe user tasks, data and the expected result. A non-technical person can verify a business process. Code, security, performance and infrastructure testing still need an appropriate technical scope.

What if acceptance criteria were not written down earlier?

Collect confirmed agreements, examples and exclusions before testing. Then jointly describe scenarios that follow from the agreed scope. If a disagreement appears, do not hide it behind a new criterion. Mark it as requiring clarification.

What is the difference between a defect and a new feature?

A defect or mismatch exists when agreed behaviour does not work according to scope. A new feature extends or changes that scope. Resolving the boundary may require returning to the proposal, approved changes and examples used during planning.

Does every comment block acceptance?

No. The significance of a comment depends on the agreed result and its effect on use. A major mismatch in the main process may block acceptance. A minor item may follow an agreed conditional-acceptance procedure.

Do user acceptance tests replace the developer's tests?

No. User acceptance mainly confirms the process from the company's perspective. The developer remains responsible for the agreed technical tests. Separate audits may be needed where security or performance risk is higher.

Must an application be tested with real data?

Not always. Start with demonstration data or a properly prepared sample. Real data may be required for a controlled migration or a special case, but its scope, access and protection should be agreed in advance.

What should be handed over after acceptance?

It depends on scope. Confirm access to the application and agreed materials, acceptance results, known limitations, external services and the information needed for deployment and maintenance.

Agree acceptance before the next stage begins

If you are planning a new application or developing an existing system, see Domin Software development services. In the first scope, we establish the problem, result, required data and a way to verify the completed work. A larger or unclear project can first be organised through business analysis and application MVP planning.

For the first conversation, prepare a description of the current process, users, important data and the result that should work after the first stage. Do not send passwords, keys or a customer database. After reviewing the description, we will indicate which information is still needed to define the scope and estimate.

Sources

• OWASP Application Security Verification Standard, OWASP, stable version 5.0.0 published 30 May 2025, accessed 30 October 2026.
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, published February 2022, accessed 30 October 2026.