Acceptance is not a final glance at the product. It is a check against what was agreed at the technical specification stage. Without that check, "done" means "we ran out of energy", not "finished".
Testing an app before launch matters to the business owner far more than to the developer. The owner is the last to hear about a missed bug: from a customer who could not pay, from a manager who saw someone else's data, or from a server that did not come back after a restart. Stage 10 closes these risks before the product meets real users and real money.
What gets tested
- Interface testing and fixes.
- Testing and fixing scenarios from the specification.
- Testing and fixing integration logic.
- Testing and fixing deployment processes.
Each item is a specific piece of work, not a general "we had a look and it seems fine".
Interfaces
Screens are checked on the devices and browsers named in the requirements. We go through forms, validation, empty and error states and mobile behaviour. Separately, we confirm that each role sees exactly its own screens and buttons.
Scenarios from the specification
Every scenario in the specification is run end to end, the way a real user would run it: sign-up, order, payment, cancellation, refund, status change. A scenario either works as described or goes back for a fix. Disputed points are settled by the text of the specification, not by anyone's memory.
Integration logic
Payment systems, CRM, maps and external APIs are tested for more than a successful response. What matters more is failure: the other system did not reply, replied with an error, or sent the same notification twice. These are exactly the places where money and orders usually go missing.
Deployment is tested too
The fourth item usually surprises people, yet it is what separates a delivered project from a handed-over one. If a product cannot be redeployed without its author, you have not received it. You have rented it together with a person.
So acceptance confirms that the system can be brought up from scratch by a documented procedure: containers, server settings, SSL certificates, background processes and the CI/CD set up during deployment and infrastructure. If deployment depends on manual steps that only one person knows, that is a defect, not a feature.
What you get at the end
- A product checked against the specification, scenario by scenario, with defects fixed.
- A tested deployment procedure that another team can repeat.
- A demonstration of the stage result, usually as a video presentation.
- Sign-off against acceptance terms agreed in the contract in advance, not invented on the last day.
How much testing and handover costs
In the development strategy, Stage 10 costs from $800 to $4700. The price is fixed before the stage starts, so the budget does not grow while testing is under way.
Where a project sits in that range depends on how much has to be checked: how many interfaces and roles the product has, how many scenarios the specification describes, how many external systems are connected and how complex the deployment is. A small service with one role and one payment method sits near the lower end; a corporate system with several integrations sits near the upper end. We give an exact figure after the consultation, once we have seen the specification and the list of integrations.
If another team built the product and documentation is thin, the right starting point is not acceptance but an audit of the existing system. It costs $800 for a written report, or $2400 with an early prototype of the change you need.
What breaks if you cut corners on acceptance
- Interfaces. Customers find the bugs, and some of them simply leave without contacting support.
- Scenarios. Rare branches such as cancellation, refund or repeat payment run for the first time on live money.
- Integrations. A failure on a partner's side turns into lost orders, and nobody can say where they disappeared.
- Deployment. The first server move or the first developer departure stops the product for days.
Each of these failures costs more after launch than checking for it before launch: lost customers and management time are added to the cost of the fix.
An example from our work
In the Goal Decomposer app, testing is built into the project itself. There is a quick server smoke test and an end-to-end interface run in headless Chrome: the AI model is replaced by a stub, and the scenario runs from an entered goal to a finished plan and to the plan being restored after a page reload. Any developer can repeat that run with one command.
In the system for a network of medical centres with twelve roles, the single source of truth about what each role can see is covered by an automated test. Each role's list of screens is checked by machine, so access rules do not drift apart as the system changes. It is a good example of how part of acceptance moves into test automation over time.
What happens after handover
We provide free daily technical support after delivery: if something breaks in the project, we fix it and do not bill for it. This is written into the contract, and we have not seen that clause in any competitor's contract.
From there, the product grows along the corporate development tracks: from security and test automation to search optimisation. When the user base grows, notifications and an action log are usually the first to be added.
Where to go next
The previous step is deployment and infrastructure. The full map of stages is in the app development strategy.
If your product is getting ready for launch, or is already live but you are not sure it could be handed to another team, book a free consultation with an architect. We will work out what to test and how, and after the consultation we will send you a price and timeline broken down by stage.
