When negotiating the price of a custom software project, the unit most commonly aligned between Party A and Party B is “man-days”: how many engineers, for how many days, at what unit price. This model works well when requirements are stable and delivery boundaries are clear; however, once on-site rules change frequently, AI tools boost coding efficiency, yet Party A still conducts acceptance based on “stacking heads,” conflicts inevitably erupt—Party B feels the scope has expanded, while Party A thinks, “We didn’t add more people, but there’s still no more output.”
Policy signal: shifting from selling man-hours to selling outcomes
In September 2026, the Ministry of Industry and Information Technology released the “Special Action Plan for ‘AI + Software,’” which repeatedly emphasizes transforming software production models and developing “Model-as-a-Service” and “Agent-as-a-Service,” explicitly aiming to establish benchmark applications of agent-based software in key industries by 2028. The document does not reject custom development, but it conveys a clear direction: when evaluating software value, increasing emphasis will be placed on tangible results rather than merely counting man-days.
For enterprises currently implementing ERP, MES, CRM, or industry-specific management systems, this means that if contracts still only specify “XX people × XX days,” they may easily end up in disputes after go-live, where “the code is finished, but the business can’t use it.” A more sustainable approach is to break down deliverables into verifiable business outcomes.
Business logic: milestones should be more concrete than man-days
Upgrade the project payment structure from “phased payments” to “milestone payments,” with each milestone required to simultaneously meet four conditions:
- Business scenarios: who uses it and what operations it solves (e.g., “warehouse staff scan to record inventory entry” instead of “complete the inventory entry module”).
- Data metrics: which master data, status fields, and permission scopes are involved, along with sampling rules.
- Acceptance scripts: given test data, which processes must be executed and what documents or reports should be generated.
- Exception handling: how the system responds upon failure, who has authority to make changes, and whether logs are retained.
Milestones should ideally last no longer than 2–4 weeks each; overly long milestones risk reverting to “black-box development.” Typical breakdown examples include: master data and permissions → core document workflow → reporting and reconciliation → interfaces and go-live transition.
Design logic: scope, changes, and “intelligent assistance” should all be specified in the contract
AI-assisted coding, automated test case generation, and intelligent document completion will alter man-day consumption for the same functionality, but they do not automatically reduce business complexity. It is recommended to separately list these items in the contract and requirements specification:
- Scope baseline (Baseline): a list of features plus an Out-of-Scope inventory; any changes must follow a formal change order.
- Change pricing rules: new milestones should be priced based on “scenario + acceptance script,” rather than adding man-days on the fly.
- Intelligent assistance boundaries: which stages can leverage AI for efficiency (code generation, draft documentation), and which require manual approval (security, compliance, external commitments).
- Knowledge retention ownership: who holds process documentation, configurations, and scripts to prevent operational gaps after delivery.
Development implementation: automated acceptance and observability
To make “outcome-oriented” approaches actionable, the technical team needs to support three key measures:
- Acceptance test cases stored in the repository: each milestone corresponds to a set of automated or semi-automated test cases, enabling repeatable regression testing.
- Environment and data isolation: UAT environment data can be reset to avoid situations where “it only passes in the demo environment.”
- Observable logs: critical operations generate audit logs, allowing traceability during disputes to determine who modified what.
If the project includes agents or rule engines, acceptance should incorporate an additional random sampling mechanism: randomly input boundary cases to verify whether rejection responses, human escalation, and permission blocking align with design specifications, rather than simply checking if “it can chat.”
Three common types of disputes and preventive measures
Dispute #1: “All the functions have been implemented, so why isn’t the business using them?”—Prevention: tie milestones to specific job roles and training sign-in records, and conduct on-site walkthroughs during acceptance, rather than relying solely on PPT demonstrations.
Dispute #2: “Why do we have to pay extra for a small additional requirement?”—Prevention: clearly document affected milestones, scripts, and timelines in the change order, and proceed with development only after both parties sign off.
Dispute #3: “With AI boosting efficiency, can we cut back on man-days?”—Prevention: distinguish between “implementation costs” and “business complexity” in the contract; efficiency gains can be reflected in total cost or timeline, but acceptance standards must remain unchanged.
Pilot recommendation: start with a single closed-loop module
No need to wait for the entire system to rewrite the contract. Choose a module that can achieve a closed loop within 2–3 weeks (such as inbound/outbound inventory, work order reporting, or expense approvals), and use a new template to sign supplementary agreements listing scenarios, scripts, exceptions, and payment milestones. Once successfully tested, expand to the entire project. To measure success, look at whether change orders reduce time spent on disputes, and whether UAT pass rates increase, rather than focusing on how much fewer man-days Party B reported.
Man-days won’t disappear overnight, but they’re transitioning from being the sole pricing unit to serving as a reference for cost estimation. Writing milestones and acceptance scripts into the contract is the fundamental skill that allows custom software to continue delivering trustworthy results even in the era of “AI + Software.”
Coordinating with fixed-price contracts and agile iterations
Milestone-based acceptance does not exclude agility: each Sprint can still deliver demonstrable increments, but payments and formal acceptanceare tied to larger milestones. Fixed-price contracts especially need to clearly define the “scope freeze point”—after which reviews, any new requirements must follow a formal change order, avoiding ad-hoc additions of features. For modules containing agents, it’s recommended to conduct separate milestone acceptance focused on “rule version + pass rate from random checks,” rather than tying everything to a one-size-fits-all full-site launch.
Industry data shows that approximately one-thirdof software project failures stem from unclear requirements and acceptance criteria, rather than technical implementation itself. Defining “what constitutes completion” upfront in the contract is far more valuable than debating whether AI replaced a few programmers. At the next project review, consider asking: if all Party B employees were on leave tomorrow, could we judge whether the current milestone meets standards based solely on the script? If you can’t answer, it indicates that acceptance criteria haven’t been clearly defined yet.