Everything can look ready in a demo: pages load, buttons work, and an order appears in the account. But that is not enough for acceptance. After handover, the project must work under the agreed conditions, belong to the client to the agreed extent, and not depend on the only person who knows how to run it.
Acceptance is not about finding a reason to avoid paying developers. It is a review of the overall result: what has been delivered, which limitations remain, and who is responsible for the system after launch. The earlier the team and client agree on these conditions, the fewer disputes there will be at the end.
Below, we explain what you can check yourself, what evidence to request, and where you will need a technical specialist.
1. Test workflows, not individual screens
Acceptance should be based on the requirements and user workflows agreed before development. If expectations exist only in messages, first consolidate them into a shared list and separately identify the changes the team agreed to implement.
Test the entire journey. For an online store, that means not just the product page, but selecting a variant, calculating the price, placing an order, paying, receiving confirmation, and having the order appear in the manager's interface. For a booking service, a reserved slot must disappear from available times, and cancellation must update the schedule correctly.
For each workflow, test more than just the successful outcome:
- What happens when data is invalid or permissions are insufficient?
- Can clicking a button twice accidentally create two orders?
- What will users see if the connection drops or an external service is unavailable?
- Is the result preserved after refreshing the page and signing in again?
- How are cancellation, refunds, and error correction handled?
Test on the agreed devices and browsers, using different user roles. Test payments in the provider's test mode first. Agree separately on any real transaction test, including the amount, refund, and person responsible, so acceptance does not create accidental expenses.
Record issues with reproduction steps, the expected result, and a screenshot or video. Saying “payment behaves strangely” is less useful than a specific scenario the team can reproduce.
2. Obtain the code, access, and control over accounts
A source code archive sent through a messaging app is no substitute for a proper project handover. The client needs repository access, the release version, and an understanding of which code is running on the server. The change history helps another team understand past decisions and continue development.
Ask for an inventory of resources:
- Repositories and the organization that hosts them.
- The domain, DNS, and registrar account.
- Servers, cloud services, databases, and file storage.
- The payment provider, email services, and external APIs.
- Analytics, monitoring, app stores, and associated accounts.
For each resource, identify the owner, administrators, access recovery method, and payment source. Critical accounts should be registered to the client where the service's terms allow it. The contractor can retain operational access, but it must not be the only way to manage the product.
Transfer passwords and secret keys through an agreed secure channel, not a shared spreadsheet or public repository. After handover, review permissions, enable multifactor authentication where available, and rotate sensitive keys according to an agreed plan. Abruptly replacing all keys without checking dependencies can bring the service down.
3. Make sure the project can be deployed and restored
Documentation is useful if someone can use it to do the work, not just read an architecture description. The handover package should include instructions for running, building, and updating the project, a list of required services, and an explanation of environment configuration without exposing secrets.
You also need procedures for database changes, backups, and release rollback. It is important to know not just where a backup is stored, but what it contains: the database, uploaded files, configuration, or only part of the system.
A good handover test is to have an engineer who was not involved in development deploy the project in a separate environment using the documentation. If they keep having to ask the code's author which commands to run, the instructions still need work.
Backup restoration should also be tested separately, not over the live database. After restoration, verify that the data is readable and the core workflows work. A file named backup does not prove that recovery is possible.
Agree on acceptable data loss and recovery time. A small informational website and a service that takes orders around the clock will have different requirements. There is no universal standard here, but without an agreement, the business has no clear plan when a failure occurs.
4. Check security and data handling
The client does not need to read all the code to ask the right questions. Ask the team to demonstrate how roles are separated, where secrets are stored, what data goes into logs, and what happens when someone tries to open another user's order or document.
A hidden interface button is not a security control. Restrictions must be enforced on the server: a regular user must not obtain administrative data just because they know a request URL.
A basic review typically includes:
- Access controls for other users' data and administrator actions.
- No secrets in public code or the client build.
- Correct handling of duplicate payment notifications.
- Limiting unnecessary data in logs, exports, and API responses.
- Reviewing dependencies and resolving or documenting significant risks.
The scope of the review depends on the consequences of a failure. A product handling users' money, sensitive data, or smart contracts may need an independent audit. Agree on its boundaries: what was reviewed, which code version the report covers, and which findings have been resolved.
A passing test or report does not guarantee that every vulnerability is absent. It provides evidence of specific checks. Acceptance should record remaining risks and responsible parties, rather than come down to a promise that “everything is secure.”
5. Clarify rights and post-launch support
Access to source code and the right to use or modify it are not the same thing. Review the contract and handover documents for the scope of transferred rights, terms for using design and content, and third-party component licenses. For disputed issues, consult a lawyer with regard to the applicable law.
Not every library becomes the client's property along with the project. Some components are used under a license; others require a subscription. You need a list of these dependencies, restrictions, and recurring expenses, including fonts, images, and external services.
Before final handover, agree on what happens after release:
- Who monitors errors and system availability?
- Which defects are covered by warranty fixes, and for how long?
- How is a bug fix distinguished from a new feature or a requirements change?
- How are support requests submitted, and what response times have been agreed?
- Who is responsible for updates, backups, and service renewals?
Acceptance should not require endless free modifications. But handing over a project without clear responsibility boundaries also creates risk: at the first failure, each party may believe the other should handle it.
6. Review AI-assisted development separately
Using AI is not a drawback in itself. AI can help write standard code, tests, and documentation faster. But the client accepts a working system, not a count of generated lines.
Ask for evidence that changes undergo review, core workflows are covered by tests, and the team knows which dependencies are in use. Permissions, payments, and error handling are particularly important: seemingly convincing code in these areas can contain serious defects.
Generated documentation must match the actual project. A deployment test in a separate environment quickly reveals whether the listed commands, variables, and services actually exist.
You should also agree on rules for using AI tools: which data may be sent to the provider, whether uploading private code is allowed, and how secrets are protected. The terms depend on the tool, configuration, and contract. Responsibility for the chosen process and the result remains with the team.
Acceptance table: what to request from the team
| What to check | Evidence to obtain | What blocks launch |
|---|---|---|
| Core workflows | Test results against the agreed checklist | A critical workflow cannot be completed |
| Code and access | Repository, release version, and account inventory | The client does not control critical resources |
| Deployment | A verified deployment using the instructions | The project cannot be reproduced without its author |
| Backups | A recovery test in a separate environment | Recovery of critical data has not been verified |
| Security | Review results and a list of remaining risks | A known critical vulnerability or access to other users' data |
| Rights | Agreed documents and a list of licenses | The rights needed for the intended use are missing |
| Support | Documented areas of responsibility | There is no agreed failure response plan for launch |
Not every issue should stop a release. A minor visual discrepancy can be moved to an agreed fix list if it does not interfere with use. Data loss, incorrect charges, or access control failures cannot be deferred. Both parties should document priorities and acceptable limitations together.
A properly handed-over project can be understood, deployed, restored, and developed further by another team. Together with working user workflows and clear rights, this is what acceptance should deliver. A polished demo shows the interface. A complete handover shows that the business has truly received its own product.