Fixed-Scope vs Custom Automation Project: How to Choose the Right Contract (With Price Bands, 2026)

Fixed price protects both sides on known work and neither side on unknown work. The decision table, the seven signals a fixed scope is unsafe, what a milestone contract includes, and what each costs.

Last verified: 10 September 2026 · Prem Patel, Nex Automations

Choose a fixed-scope automation project when the workflow and its acceptance test are stable today. Choose a custom, milestone-based project when the system still has to be discovered, integrated and released in stages. The dividing line is not size. It is uncertainty and what happens when the automation is wrong. A fixed price on known work protects both sides; a fixed price on unknown work protects neither.

This guide is the contract half of choosing an engagement, written from 1,200+ automations for 210+ clients as a Make.com Level 5 Expert and Zapier Certified Expert. The service half, which type of engagement you need at all, is in which automation service do you need. Every price band here is published on our own service pages and was checked 10 September 2026.

The decision table

What a good fixed scope looks like

A strong fixed scope describes the trigger, the included applications, the required fields, the actions, the branches, the sample inputs, the success tests, the revision allowance and the handover. It also names what is excluded. "Connect our forms to our CRM" is a wish. "When a Typeform submission arrives with budget over 2,000, create a HubSpot contact and deal, assign by territory field, and post to the sales channel; anything else goes to a holding list" is a scope, and it can be priced.

Fixed scope is ideal for one stable workflow, an audit against a defined checklist, migrating a known scenario between platforms, a document template automation, or a focused repair. It gives you cost certainty and gives the builder a clear finish line. Two of our own migrations are the clearest example: a marketing client moved from Zapier to Make on the same workflow set and saved $720 a year; a second client running near 50,000 tasks a month saved $11,000 in twelve months. Both were fixed scope, because the workflows already existed and the test was "does it do exactly what it did before, for less".

When fixed scope becomes unsafe

Do not force a fixed price onto a process that has undocumented exceptions, unclear data ownership, several decision-makers, unknown APIs or changing requirements. The apparent certainty comes back later as disputed scope, rushed corners or a quiet second invoice, and it damages the relationship on both sides.

Move to discovery or milestones if any of these are true:

• the team cannot agree on how the process runs today;
• production data has not been sampled;
• the API, permissions or rate limits are unknown;
• the workflow sends money, deletes records or messages customers at scale;
• AI must decide from ambiguous input;
• several departments must approve the release;
• monitoring and recovery are part of the requirement, not an afterthought.

What a custom project actually includes

A custom engagement usually begins with architecture and a thin production slice, one real path working end to end. Later milestones add integrations, exceptions, dashboards, AI steps or rollout groups. Scope can evolve through written change control without the project becoming an open-ended hourly bill.

A production-ready system carries things a fixed-scope build rarely needs: idempotency so a retried event does not double-post, queues and retry rules, rate-limit handling, alerts, audit records, confidence thresholds with a manual-review path, backups, release documentation and ownership training. Those are not padding. When we rebuilt an invoice process for a transportation company, the 77% reduction in processing time came from the workflow; the fact that it kept running when an upstream record was malformed came from that list. A document generation system built the same way still ships 75 percent of a bad batch instead of stopping on the first error.

Milestones, and why they protect you

A milestone is a deliverable you can test before paying for the next one. That is the whole mechanism. A sensible shape for a three-milestone system:

1. Architecture and a thin slice. The process map, the data model, the risk list and one path in production. You learn whether the integration is what everyone assumed.
2. Core implementation. The remaining paths, the exception handling, the manual-review route. You test against real, sampled data.
3. Hardening and rollout. Monitoring, alerts, documentation, training, and the release to the wider team.

If milestone one changes the picture, milestones two and three are re-scoped in writing. That is a feature. A fixed price would have absorbed that change as either a loss for the builder or a corner cut for you.

Direct, marketplace or milestone contract

A marketplace package works for a repeatable, tightly defined outcome where the escrow and checkout are the value. A milestone contract, direct or through a platform that supports it, works for specialist projects organised around deliverables. Direct work with a written proposal fits anything with unknowns.

The platform does not determine project quality. The statement of work does. Whatever the route: keep accounts and billing in your name, avoid sharing primary passwords, specify access boundaries, use representative test data, and document the handover. The service guide has the full pre-hire checklist.

A statement of work you can copy

Nine headings. If a proposal you receive is missing any of them, ask why before you sign.

1. Trigger and outcome. What starts the workflow and what it ends in, in one sentence each.
2. Systems and access. Every application touched, and who owns each account and subscription. Yours, always.
3. Fields and rules. The data that moves and the decisions made on it, including the branches.
4. Exceptions and the human route. What the automation refuses to decide, and where those cases go.
5. Sample data and acceptance tests. The records you supply and the sentence that defines "it worked".
6. Revisions and change control. How many rounds are included, and how a new requirement becomes a new line item rather than an argument.
7. Error handling, monitoring and alerts. What happens at 2 a.m., and who is told.
8. Documentation, handover and training. What you receive, and the credential-revocation step at the end.
9. Exclusions, price and validity. What is not included, the fixed price for this scope, and the date it expires.

Fixed-scope projects fill all nine in one document. Milestone projects fill the first five for milestone one and revisit the rest at each gate. Either way, a price without the other eight headings is a guess with a currency symbol.

How price should be handled

Website ranges, case-study budgets and marketplace starting prices are context, not permanent offers. A valid project price references a specific scope and a date. It says what is included, how changes are approved, which subscriptions you pay for directly, and what happens after handover.

For a fair comparison, ask every supplier to price the same acceptance criteria and the same risk controls. A cheaper proposal that excludes testing, monitoring or documentation is not the same deliverable at a lower price; it is a different deliverable. The platform cost is the one part you can price yourself in advance, with the Zapier vs Make vs n8n cost calculator.

How to change scope without breaking the price

Both shapes survive change if the change is written down before it is built. The mechanism is the same on a $500 workflow and a $5,000 system: the request is described in one paragraph, the builder replies with the effect on price and date, and nothing moves until both sides have agreed in writing. On a fixed-scope project that reply is a new line item, priced against the same acceptance-test standard as the original. On a milestone project it is folded into the next gate, where it can be tested with everything else.

What breaks projects is the informal version: a message on a Friday, a "sure, quick one" on the Monday, and a disagreement at the invoice about whether it was included. Three habits prevent that. Keep one document as the scope of record. Number every change. Tie each change to a test, because a change nobody can test is a change nobody can sign off.

Which should you choose

Choose fixed scope if a knowledgeable stakeholder can approve a written workflow and its test cases today. Choose custom if important facts will only emerge during architecture, integration or user testing. If you are unsure, start with the smallest fixed-scope piece that proves the integration, and let what you learn become milestone one.

The fastest way to find out which you are is a free 30-minute consult: bring the process, leave with the shape, a rough scope and a price. The packages behind those bands are on our services page.

Frequently asked questions

Is a fixed-price automation project cheaper than a custom one?

Usually, for the same work, because the builder is not carrying the risk of unknowns. It is only cheaper if the work really is known. A fixed price on a process with undocumented exceptions is not a saving; it is a dispute scheduled for later, when the exceptions surface and neither side agreed who pays for them.

What should a statement of work for an automation project include?

The trigger, the applications, the fields and actions, the branches, the sample inputs you will supply, the acceptance tests, the number of revision rounds, the documentation and handover, and a list of exclusions. If it also names who owns each account and subscription, most later arguments never happen.

How do milestones work on a custom automation project?

Each milestone is a deliverable you can test before paying for the next one. A common shape is architecture and a thin production slice first, then the integrations and exception handling, then monitoring, documentation and rollout. Scope can change between milestones through written change control without turning the whole project into an hourly bill.

When does a fixed scope become unsafe?

When the team cannot agree on the current process, production data has not been sampled, the API or permissions are unknown, the workflow sends money or messages customers at scale, AI has to decide from ambiguous input, or several departments must approve the release. Any one of those is a reason to buy discovery first.

Can I start fixed-scope and move to a custom project later?

Yes, and it is often the best route. A fixed-scope build of one contained workflow proves the integration, the data quality and the working relationship. What you learn becomes the first milestone of the larger system instead of a guess.

What are typical prices for fixed-scope and custom automation work?

On our service pages, checked 10 September 2026: a single stable workflow is $300 to $800 in 3 to 7 days, a multi-workflow system is $1,500 to $5,000 over 2 to 4 weeks, and ongoing operation starts at $5,000 a month. Platform subscriptions are separate and stay in your name.

Related reading

• Which Automation Service Do You Actually Need?
• How to Prepare for an Automation Discovery Call
• How Much Does Make.com Automation Cost?
• Transportation Invoice Automation: 30 Days to 7 Days