In 2026, clients price front-end work like AI drafts—who covers the integration and acceptance days?

In 2026 projects, AI drafts mainly cut the time to produce the first version of page structure. The hours for integration, compatibility testing, and launch acceptance do not disappear with it. When negotiating a front-end budget, if those later stages are also converted at AI draft speed, a common result is a schedule that looks loose early and tight late, with problems clustering in the week before launch. A steadier approach is to split the quote into three stages—draft, integration, and acceptance—and discuss each separately with its own preconditions.

What sits between an AI draft quote and a launch-ready quote?

Putting the two side by side makes it clearer. A draft solves 'it looks like it can run.' Delivery solves 'when something breaks, someone is accountable.' Between them sit several workstreams: APIs, error states, multi-device adaptation, and acceptance criteria. Each one takes real hours.

• Draft stage: When copy and visuals are largely settled, a typical range is 0.5-2 person-days to produce the first version of the structure. The lighter the interaction, the closer it sits to the lower end.
• API integration: Field alignment, pagination, login state, and retry on failure typically take 2-5 person-days. If API docs arrive late or fields change repeatedly, it can exceed the upper end.
• Multi-device and compatibility: Mainstream mobile browsers, in-app browsers such as WeChat, iOS safe areas, and keyboard occlusion typically take 1-4 person-days. The more devices, the higher it goes.
• Performance and crawlability: First-screen assets, images, and font budgets; pages that need to be indexed also require crawlable content and internal links, typically 1-3 person-days.
• Acceptance and regression: Failure states, no-permission states, timeout prompts, plus regression after revisions, typically 1-3 person-days. More review rounds make it longer.

These are orders of magnitude that recur in projects. They are experience ranges, not a precise quote sheet. What really determines which end of the range you land on is the number of devices, API stability, and the frequency of post-launch changes.

There is another often overlooked point: waiting is also a cost. Time spent waiting for API docs, assets, and design confirmation is often left out of quotes, but it genuinely squeezes the integration window and shows up as overtime or delays.

Three chunks of work that are easy to leave out when negotiating price

Based on 2026 habits for taking on work and scheduling, the parts most likely to be omitted from a quote are often not page building, but the following stages.

1. Integration waiting and rework: Late API docs, inconsistent field naming, and last-minute changes to pagination rules commonly add 1-3 person-days of rework, which is usually not included in the draft price.
2. Acceptance back-and-forth: Visual review, product trials, and test regression commonly take 2-4 rounds. Each round carries communication and change costs. The more rounds, the harder it is to compress.
3. Post-launch maintenance: Early launch issue response, copy adjustments, and adding analytics events commonly take 0.5-2 person-days. During promotions or ad campaigns, they cluster more.

Leaving these three out of a quote does not mean they will not happen. It just moves the cost from the budget to the delivery team's overtime. Making them clear during negotiation is easier than arguing after launch.

Which projects can be priced like AI drafts, and which should not be?

The test is not whether AI can write pages, but who is accountable when something breaks and how often changes are needed. Projects with clear scope, few changes, and a single device usually fit a draft-based price. The opposite calls for caution.

• Can be priced like AI drafts: One-off campaign pages, purely presentational corporate sites, internal explainer pages. Copy and assets are finalized in advance, little changes after launch, and it is viewed on only one device.
• Needs caution: Content sites, product listing pages, and pages that need to be indexed by search engines. Crawlability, internal link entry points, and first-screen assets need separate hours.
• Not recommended for this pricing: Transaction flows, logged-in back-office systems, cross-platform apps and mini programs, and business pages with monthly revisions. In these projects, the draft is only a small part of the whole.

A useful boundary sentence: if a page needs to connect to real APIs, pass platform review, and continue changing after launch, the quote should reserve hours for the stages where a person is present. For purely presentational static pages, closing out is usually much lighter.

Delivery scene: after scheduling by AI draft speed, where does the rework bill come from?

One campaign H5 had a budget agreed at 'AI draft plus a small amount of manual work,' with a schedule three to four days tighter than usual. The constraints were typical: API fields were still changing during integration, both iOS and Android had to be checked, and operations added share cards and analytics reporting requirements just before review submission.

The approach at the time had three steps: first compile API fields into a checklist for the backend to confirm; then fill in items one by one from an error-state checklist (no data, timeout, retry on failure, no permission); finally reserve a day for multi-device review. The result: launch was about two days later than planned, and the extra integration and acceptance hours fell into the typical range of 3-6 person-days. That range is hard to eliminate in similar projects. The only options are to reserve it in advance or narrow the scope.

There is also the opposite example: a purely presentational campaign page with assets finalized in advance and viewed on only one device. After the AI draft, only share images and analytics events were added, and close-out was completed within 1-2 person-days. The difference between the two is not how fast the tool is, but the number of APIs and devices.

Common questions

Can pages from AI drafts be quoted directly as finished products?

Not recommended. A draft usually covers only the main path. APIs, error states, multiple devices, and acceptance all need separate hours. If you quote directly as a finished product, gaps tend to surface before launch.

If the front-end budget is squeezed by draft speed, which part is safer to cut back first?

Cutting scope is usually safer than cutting process. Dropping non-core devices or delaying secondary pages is more controllable than compressing integration and acceptance, which tends to push risk past launch.

For a small project using AI drafts plus manual close-out, how many hours should be reserved?

A presentational single page typically takes 1-3 person-days; a page with APIs, multiple devices, or platform review typically takes 5-10 person-days, depending on the number of devices and change frequency.

How can draft and delivery be written separately when negotiating price?

List hours separately for draft, integration, and acceptance, with experience ranges and preconditions such as when API docs will be ready, the device list, and the number of review rounds. That is easier to align than a single total price.

If the other side insists on settling only at the draft price, what is a reasonable way to handle it?

Narrow the scope to what you can take on, and write the acceptance criteria and change pricing method into the agreement. Clarifying scope usually saves more communication than arguing over hours afterward.

If in 2026 you are planning to use AI drafts to compress a front-end budget, do one thing first: split the quote into draft, integration, and acceptance, and write down the preconditions and typical hour ranges for each. For presentational, single-device projects that will not change after launch, a draft-based price is not a major problem. For pages involving transactions, login, cross-device use, or ongoing revisions, it is still advisable to keep those human hours in the budget. The basis for judgment is scope, number of devices, and change frequency—not how fast the tool runs.