Project acceptance used to be the gentlest stage of a software build. The supplier ran a demo, walked the client through the main user journeys, fixed a handful of cosmetic defects and collected a signature against the functional requirements. On most fixed-price contracts it was treated as a small buffer at the end of the final milestone, not as a phase that needed its own plan, budget or owner.
That picture no longer holds. On 10 September 2026 the custom software firm SCAND published a case study from a fixed-price microservices platform in which the client’s technical team used AI assistants to review source code, cloud configuration and API specifications line by line. IT project acceptance on that job took around 14% of total project effort and ran to five separate review iterations. Clients, SCAND wrote, “are no longer passive evaluators during handover”.
This guide explains what has changed, why cheaper AI-assisted builds are producing more expensive handovers, and how to price the acceptance phase honestly. It covers the evidence a client’s AI reviewer will expect, the contract terms that stop review rounds running on indefinitely, and separate playbooks for buyers and suppliers. It builds on our guides to software development contracts and changing development partners.
Table of contents
- What Changed in Project Acceptance When Clients Use AI
- The Market Paradox Squeezing Project Acceptance
- What an AI Reviewer Checks During Project Acceptance
- How to Price Project Acceptance in a Fixed-Price Build
- The Project Acceptance Evidence Pack
- Writing Project Acceptance Criteria Into the Contract
- From Delivering Software to Delivering Technical Autonomy
- Regulation Is Raising the Project Acceptance Bar
- A Project Acceptance Playbook for Buyers
- A Project Acceptance Playbook for Suppliers
- Project Acceptance FAQs
- References
What Changed in Project Acceptance When Clients Use AI
Clients now review deliverables with the same class of tools their suppliers use to write them, and that single shift has changed the economics of the final phase of a build.
From demo sign-off to technical audit
The traditional acceptance meeting tested what a system did, not how it was built. A client representative clicked through the screens, compared behaviour with the specification and raised defects. The code itself was rarely read, because reading it properly needed a senior engineer the client usually did not employ.
AI tools removed that barrier. A client can now point a model at a repository and ask whether secrets are hard-coded, whether error handling is consistent, whether the deployment scripts match the architecture diagram and whether every line item in the statement of work maps to a commit. Project acceptance has shifted from a demonstration to an audit, and the audit is thorough in a way a demo never was.
What the SCAND handover looked like
SCAND describes review comments that “were not high-level feedback; they were precise, AI-assisted audits covering architecture, secrets management, and service dependencies.” The client wanted exported API files rather than a hosted documentation page, secrets held in a managed vault, alerting on container lifecycles and runbooks detailed enough for its own team to operate the platform without the supplier.
The table sets the four acceptance domains SCAND reported beside the traditional expectation. The last two rows are our additions, drawn from the sources cited later in this guide.
| Acceptance domain | Traditional sign-off | AI-era client expectation |
|---|---|---|
| Documentation | Hosted Swagger UI endpoints | Standalone OpenAPI JSON files kept in version control for off-grid maintenance |
| Infrastructure and deployments | Basic cloud setup and shared access | Secrets Manager integration, container auto-start checks, lifecycle alerting and isolated staging runbooks |
| Operational autonomy | Supplier-managed maintenance or a retainer | Documentation that lets the client’s own team build, run, host and change the code |
| Deliverable auditing | Feature sign-off against the original scope | Contract line items checked against commits, database schemas and background job logic |
| Security evidence (our addition) | A penetration test report, if requested | Verification against a named standard such as OWASP ASVS, plus a software bill of materials |
| Code provenance (our addition) | Rarely discussed | A clear account of where AI-generated code was used and how it was reviewed |
Why this is a supplier problem and a buyer opportunity
For suppliers, deeper scrutiny means more rework after the build is supposedly finished, often on a fixed price that assumed a light handover. For buyers, it is leverage they did not have before. SCAND’s point is that “even non-technical clients now possess technical leverage via LLM-assisted code analysis.” Project acceptance is where that leverage gets spent, and both sides need to plan for it.
The Market Paradox Squeezing Project Acceptance
SCAND frames the pressure as a paradox with three parts: clients want fixed prices for budget certainty, AI coding assistants have lowered base development estimates, and handover now demands far more detail than it used to.
Cheaper builds, dearer handovers
Clients read about AI coding assistants and expect faster, cheaper builds. Suppliers compete on those expectations, so development estimates fall. But the same tools let the client inspect the result far more closely, so effort moves from writing code to proving the code is sound. A quote that trims the build and leaves project acceptance at a token allowance ends up underpriced exactly where the scrutiny is heaviest.
The productivity illusion
The time AI saves during the build is also less certain than the market assumes. In a randomised trial published by METR in July 2025, 16 experienced open-source developers worked through 246 real issues. When AI tools were allowed they took 19% longer. They had expected a 24% speed-up, and even afterwards they believed AI had made them 20% faster.
The study is small and used early-2025 tools, so it does not prove AI always slows teams down. It is a warning against pricing in a build-effort discount that nobody has measured, and then discovering during project acceptance that the saving never existed.
Trust is now the bottleneck
Developers are sceptical of what AI produces, which is exactly why clients check it. The chart sets headline figures from the two largest 2025 developer surveys side by side, with each bar labelled by its source.
Google’s 2025 DORA research, based on nearly 5,000 technology professionals, found that AI adoption now has a positive relationship with delivery throughput but “does continue to have a negative relationship with software delivery stability.” More code is shipping, and less of it is stable. That is the gap a rigorous project acceptance process exists to catch.
What an AI Reviewer Checks During Project Acceptance
An AI-assisted reviewer does not get tired, skip files or take a supplier’s word for anything, so the questions it asks are worth knowing in advance.
The client’s AI reviewer reads everything
A human reviewer samples. A model with repository access can read every file, every migration and every configuration template, then cross-reference them against the contract and the documentation. Inconsistencies that a demo would never surface, such as an endpoint described in the specification but missing from the code, become review comments. Each comment is cheap for the client to raise and expensive for the supplier to answer.
What machine review catches that demos never did
The findings cluster in predictable places. Knowing them lets a supplier fix the issues before the client’s tools find them, which is the single cheapest way to shorten project acceptance.
| What the reviewer checks | Typical finding | How to pre-empt it |
|---|---|---|
| Secrets and credentials | Default passwords, keys in config files, credentials in commit history | Move secrets to a managed store, rotate anything ever committed, scan history before handover |
| Error handling and logging | Swallowed exceptions, inconsistent log formats, stack traces shown to users | Agree a logging and error standard at kick-off and lint against it |
| Documentation drift | API documentation that no longer matches the code | Generate specifications from code in the pipeline and commit the output |
| Scope traceability | Contract line items with no matching commit, schema or job | Keep a traceability matrix from statement of work to pull requests |
| Infrastructure as code | Manual console changes missing from templates | Rebuild staging from the repository alone before handover |
| Dependencies | Outdated or vulnerable packages, unclear licences | Produce a software bill of materials and dependency audit for every release candidate |
Where AI review still needs human judgement
AI review raises false positives as well as real findings, and it cannot know that a design trade-off was agreed in a meeting six months earlier. GitHub’s documentation for Copilot code review is blunt: “Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes. Always validate Copilot’s feedback carefully.”
Both sides should therefore agree that an AI-generated comment becomes a defect only once a named person on the client side has confirmed it against the acceptance criteria. Without that rule, project acceptance turns into a stream of machine-generated tickets that nobody has read.
How to Price Project Acceptance in a Fixed-Price Build
SCAND’s first rule for estimating in the AI era is to price the acceptance and handover phase explicitly, rather than hiding it inside general contingency.
Why a 2–3% buffer no longer works
SCAND says acceptance “can no longer be treated as a 2-3% buffer at the end of a milestone” and recommends reserving 10–15% of total project scope on fixed-price engagements. That reserve covers technical documentation, step-by-step runbooks, secrets handover and iterative client verification. Its own project landed at about 14%. The gap between a 3% allowance and a 14% outcome is 11 percentage points of total effort, which on a fixed price comes straight out of the supplier’s margin.
Worked example: a £120,000 build
To put that in money, take an illustrative £120,000 fixed-price build. A 3% buffer is £3,600. A 10% reserve is £12,000, SCAND’s 14% outcome is £16,800 and a 15% reserve is £18,000. On SCAND’s ratio, the shortfall between the old buffer and the real cost of project acceptance is £13,200. Bar lengths below are scaled to the 15% reserve.
What each review round costs
SCAND’s 14% was spread across five review iterations, an average of 2.8% of total effort per round. On the £120,000 example that is £3,360 a round. Pricing project acceptance by the round, with a fixed number of rounds included and a day rate for any beyond them, turns an open-ended risk into a line item both parties can see.
The line items to price
Breaking the phase into named line items makes the reserve defensible in a proposal and easy to track once the work starts.
| Line item | What it covers | Who normally owns it |
|---|---|---|
| Technical documentation | Architecture, API specifications, data model | Supplier |
| Runbooks | Build, deploy, restore, scale and rotate secrets | Supplier, validated by client operations |
| Secrets handover | Transfer and rotation of every credential | Supplier and client security lead together |
| Verification rounds | Answering review comments and fixing confirmed defects | Supplier, within the agreed number of rounds |
| Client review time | Running tools, triaging findings, confirming defects | Client |
| Knowledge transfer | Walkthroughs and pairing with the client’s team | Shared |
Fixed price or time and materials for acceptance?
A hybrid often works best: a fixed price for the build, plus a capped time-and-materials allowance for any project acceptance rounds beyond the included number. Our comparison of fixed-price and time-and-materials contracts explains the wider trade-offs between the two models.
The Project Acceptance Evidence Pack
The quickest route through acceptance is to hand over evidence before the client asks for it. Each item below answers a question an AI reviewer will otherwise raise as a comment.
API specifications in version control
A hosted documentation page disappears when the supplier’s environment is switched off. The OpenAPI Specification describes an HTTP API in a language-agnostic file that “allows both humans and computers to discover and understand the capabilities of the service”. Export it, commit it next to the code and regenerate it in the pipeline so it cannot drift.
Secrets management and default credentials
Every credential should live in a managed store, not in code or configuration files. AWS describes the benefit of Secrets Manager plainly: “you no longer need hard-coded credentials in application source code.” Whatever platform is used, the pack should list every secret, where it is stored, who can read it and when it was last rotated.
Monitoring, alerting and a rebuildable staging environment
Clients now expect alerting on container and service lifecycles and a staging environment they can rebuild from the repository alone. Google’s SRE book describes a production readiness review as a way to “verify that a service meets accepted standards of production setup and operational readiness”. The same idea works as a project acceptance gate: if the client’s team cannot rebuild staging from the runbook, the handover is not finished. Our DevOps services team treats that rebuild as a standard test.
Security and dependency evidence
Name the standard the application was verified against. The OWASP ASVS, whose version 5.0.0 was released on 30 May 2025, “provides a basis for testing web application technical security controls”. Pair it with a software bill of materials, which CISA describes as “a nested inventory, a list of ingredients that make up software components”, and commission independent penetration testing for higher-risk systems.
A statement on AI-generated code
Suppliers use AI tools too, and clients increasingly ask where. A short statement of which parts of the codebase had AI assistance and how that code was reviewed answers the question before it becomes a review comment, and it shows the supplier has nothing to hide.
| Evidence item | What done looks like | Useful reference |
|---|---|---|
| API specification | Exported OpenAPI file committed and regenerated in CI | OpenAPI Specification |
| Secrets register | Every secret listed, held in a managed vault, rotated at handover | AWS Secrets Manager or equivalent |
| Runbooks | Client team rebuilds staging from the repository unaided | Google SRE production readiness review |
| Security verification | Chosen ASVS level stated and results attached | OWASP ASVS 5.0.0 |
| Dependency inventory | Software bill of materials for the release candidate | CISA SBOM guidance |
| AI usage statement | Where AI tools were used and how their output was reviewed | Veracode GenAI Code Security Report |
Writing Project Acceptance Criteria Into the Contract
The contract decides whether review rounds end on a date or run until somebody gives up, so the terms matter as much as the engineering.
Define acceptance before the first sprint
Acceptance criteria written at the end of a project are written in the middle of a dispute. Agree them at contract stage instead: what evidence is required, which standards apply, how defects are classified and who has authority to accept. Our software development RFP guide shows how to put these expectations into a tender, so every bidder prices the same project acceptance workload.
Cap and time-box the review rounds
Fix the number of review rounds included in the price, the time the client has to raise comments in each round and the time the supplier has to respond. Add a deemed-acceptance clause, so a deliverable is accepted if no confirmed defects are raised within the window. Without these limits, AI-assisted review can generate new comments indefinitely.
Separate defects from new requirements
Much of the friction is scope drag: a reviewer finds something the contract never asked for and logs it as a defect. Classify every comment as a defect against the agreed criteria, an improvement or a change request, and price only the first kind inside project acceptance. Improvements and change requests go through normal change control.
1. The Price includes up to [three] Acceptance Review Rounds. Each round starts when the Supplier delivers a Release Candidate with the Evidence Pack described in Schedule [X].
2. The Customer shall notify Confirmed Defects within [ten] Business Days. Comments produced by automated or AI tools become Confirmed Defects only when a named Customer representative verifies them against the Acceptance Criteria.
3. Items outside the Acceptance Criteria are handled under the Change Control Procedure.
4. If no Confirmed Defects are notified within the review window, the Release Candidate is deemed accepted.
Treat that wording as a starting point for a conversation with a lawyer, not as a finished clause. Our software development contract checklist covers the related terms on code ownership, escrow and exit rights.
From Delivering Software to Delivering Technical Autonomy
SCAND’s third rule is the most far-reaching. Modern clients, it says, “do not just want a running application, they want full operational sovereignty.”
What operational sovereignty means
Operational sovereignty means the client’s own team, and its AI tools, can build, run, host and change the system without calling the supplier. That requires deployment scripts, seed data generators, clean API specifications and documentation written for someone who never attended a project meeting. It changes what done means: working software is necessary, but the client being able to run it alone is the real test.
Handover when the relationship changes
The same evidence protects a client that later changes supplier or brings development in-house. Repository ownership, credential transfer and knowledge transfer are far easier when they were part of the original acceptance rather than an afterthought negotiated at the end of a relationship that has already gone wrong.
Support after sign-off
Autonomy does not mean abandonment. The UK government’s Software Security Code of Practice asks vendors to “provide information to the customer specifying the level of support and maintenance provided” and to give at least a year’s notice before support ends. Writing the support period into the acceptance documents keeps expectations clear after the final signature.
Regulation Is Raising the Project Acceptance Bar
Law and government guidance are moving in the same direction as client expectations, which makes the evidence gathered at handover more valuable than ever.
The EU Cyber Resilience Act reporting duty
The EU Cyber Resilience Act entered into force on 10 December 2024. Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents, and the Act’s main obligations apply from 11 December 2027. Where a supplier’s software ends up inside such a product, the cybersecurity evidence gathered during project acceptance becomes part of the manufacturer’s compliance record.
The UK Software Security Code of Practice
In the UK, the government’s code sets out 14 principles under four themes: secure design and development, build environment security, secure deployment and maintenance, and communication with customers. It gives buyers a ready-made list to reference in acceptance criteria, and gives suppliers a recognised benchmark to show they meet.
Why AI-generated code draws extra attention
There is no separate regime for AI-written code, but the risk data explains why buyers ask about it. Veracode’s 2025 GenAI Code Security Report found that AI-generated code introduced risky security flaws in 45% of tests across more than 100 models, and that larger, newer models did not improve security. A figure like that turns a general security question into a specific project acceptance requirement.
A Project Acceptance Playbook for Buyers
Buyers now hold more power at handover than they have ever had. Used well, it produces better software; used badly, it produces a stalled project and a strained relationship.
Before the contract
Put acceptance criteria, the evidence pack and the number of included review rounds into the tender. Ask bidders how they price project acceptance and how they use AI tools during development. Our list of questions to ask a software development company includes several on quality and handover that fit this stage.
During the build
Ask for the evidence pack incrementally rather than all at the end. Review API specifications, secrets handling and runbooks at each milestone, so problems surface while they are still cheap to fix. Agree early who on your side will confirm AI-generated review comments before they reach the supplier.
At handover
Run your AI review against the agreed criteria, not against everything a model can think of. Triage findings before sending them, rebuild staging from the runbook yourself and sign off once confirmed defects are closed. Resist the temptation to use the acceptance window to add new requirements.
A Project Acceptance Playbook for Suppliers
Suppliers cannot stop clients using AI to review their work, and should not try. The winning move is to make that review boring by getting there first.
Run the client’s review before the client does
Point your own AI reviewer at the repository with the questions a client would ask: hard-coded secrets, error handling, documentation drift and scope traceability. Fix what it finds and keep a record of what you checked. SCAND’s second rule is to make sure “default credentials, configuration scripts, logging, and error-handling routines meet production standards before submitting for review.”
Automate the evidence
Generate API specifications, software bills of materials, test reports and dependency audits in the pipeline, so the evidence pack is a build artefact rather than a document written in the final week. Clean, current evidence shortens every review round that follows.
Budget, time-box and record every round
Price project acceptance as its own phase, track effort per review round and compare it with the estimate at every milestone. Over several projects that data becomes the most reliable basis for the next quote. Disciplined IT project management makes that tracking routine rather than a chore.
Project Acceptance FAQs
What is IT project acceptance?
IT project acceptance is the formal process by which a client confirms that delivered software meets the agreed criteria and takes ownership of it. It usually combines acceptance testing, documentation review and the handover of access, and ends with a signed acceptance that often triggers the final payment.
How much of a project budget should acceptance take?
SCAND recommends reserving 10–15% of total project scope on fixed-price engagements, and its own recent project used about 14% across five review iterations. Smaller or lower-risk projects may need less, but a 2–3% buffer is unrealistic whenever the client plans a code-level review.
Can a client use AI tools to review code during acceptance?
Usually, if the contract gives the client access to the source code, as most custom development agreements do. Agree in advance which tools will be used, how confidential code will be protected and that AI-generated comments count as defects only once a person confirms them.
Does AI-assisted development make project acceptance faster?
Not automatically. AI tools can speed up parts of a build, but METR’s 2025 study found experienced developers took 19% longer with them, and DORA links AI adoption to lower delivery stability. A more rigorous acceptance phase is the usual result, not a shorter one.
What should an acceptance evidence pack include?
At minimum: exported API specifications, a secrets register, runbooks tested by the client’s team, security verification results, a software bill of materials and a statement of where AI tools were used. Together they let the client and its AI reviewers confirm the system without relying on the supplier.
References
SCAND: The New Reality of IT Project Acceptance in the AI Era
METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Stack Overflow 2025 Developer Survey: AI
Google Cloud: Announcing the 2025 DORA Report
DORA: State of AI-assisted Software Development 2025
Veracode: 2025 GenAI Code Security Report
GitHub Docs: Copilot Code Review
OpenAPI Initiative: OpenAPI Specification
AWS: What Is AWS Secrets Manager?
OWASP: Application Security Verification Standard
CISA: Software Bill of Materials
Google SRE Book: The Evolving SRE Engagement Model
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.