Why "fixed price" doesn't always mean what you think
A fixed price is only as good as the scope behind it. If a vendor quotes a flat fee before they understand your systems, your data, and your edge cases, that number is a guess dressed up as certainty. Someone pays for the gap between the guess and reality — usually you, in the form of change orders, delays, or a workflow that quietly breaks in production.
A fixed price without discovery isn't a commitment. It's a placeholder that gets renegotiated the first time reality shows up.
This is a practical checklist for what a real fixed-price automation or software project should include, and the warning signs that it won't.
Discovery before a price exists
Before anyone can responsibly quote a fixed price, they need to understand:
- What systems are involved (CRM, spreadsheets, email, forms, internal tools)
- What the current process actually looks like, including exceptions
- What "done" looks like from your side, not just theirs
- What data quality problems already exist
Skipping this step doesn't save you time. It moves the discovery work into the build phase, where it costs more and shows up as delays. A short paid discovery session — a recorded workflow review, for example — is cheap insurance against a scope built on assumptions. See our Ops Teardown for one version of this.
The written scope of work (SOW)
Every fixed-price project should have a written SOW covering:
- In-scope: the specific workflows, screens, or integrations being built
- Out-of-scope: explicitly named, not just implied — e.g., "does not include migrating historical records" or "does not include a mobile app"
- Assumptions: what the vendor is assuming about your data, access, and team availability
- Dependencies: things you must provide (API keys, admin access, sample data, sign-off windows)
- Timeline: milestones with dates, not just a total duration
If a vendor can't produce this before you sign, ask why. A one-page SOW takes an hour to write once discovery is done.
Acceptance criteria: agree on "done" up front
Acceptance criteria are the specific, testable conditions that determine whether the work is finished. They should be written and agreed before the build starts, not negotiated after delivery.
Example for a lead-response automation:
| Criterion | Testable? |
|---|---|
| New form submissions are routed to the correct rep within 2 minutes | Yes — timestamp comparison |
| Duplicate leads are flagged, not double-routed | Yes — test with a repeat email address |
| Failed routing triggers a Slack alert to the ops channel | Yes — simulate a failure |
| Rep receives lead source and form data, not just an email address | Yes — check message payload |
Vague criteria like "the workflow should work well" are not acceptance criteria. They're opinions waiting to happen.
Change orders: how scope changes should be handled
Requirements shift once people see a working system. That's normal. What matters is the process:
- Changes are described in writing (what, why, effort estimate)
- The buyer approves the price and timeline impact before work starts
- Approved changes are added to the SOW, not handled off the books
"We'll just squeeze it in" sounds friendly, but it hides cost. Untracked changes stretch timelines, blur what was actually delivered, and make it hard to hold either side accountable later. A vendor who insists on documenting changes, even small ones, is protecting you as much as themselves.
Ownership: code, repo, accounts, keys, data
Before signing anything, get clear, written answers to:
- Who owns the source code — you, outright, on delivery or on final payment?
- Is the code in a repository you control, or one the vendor controls and never shares?
- Do you have admin access to every connected account (CRM, email platform, automation tool)?
- Do you hold the API keys, or are they buried in the vendor's own accounts?
- Who owns the data flowing through the system?
"Client owns the code" should mean the contract states the deliverable code and configuration transfer to you at project completion, hosted or stored somewhere you control, with no ongoing dependency on the vendor's infrastructure to keep it running. Anything less is a lock-in risk. This is general information, not legal advice.
Documentation and handover
A project isn't finished when it works. It's finished when someone other than the builder can maintain it. Ask for:
- A runbook: what the system does, step by step, in plain language
- Architecture notes: what's connected to what, and why
- Full credentials transfer: logins, API keys, service accounts
- A recorded walkthrough: someone talking through the system on screen, not just a slide deck
If a vendor is reluctant to hand over documentation, that's usually a sign they want to stay indispensable.
Support terms after launch
Ask specifically:
- What's the response time for a broken workflow — hours, or days?
- What counts as a "bug" (covered) versus a "change" (billed separately)?
- What happens once any included warranty period ends — is there a retainer, or are you on your own?
Vague answers here turn into disputes later, usually at the worst possible time (e.g., a workflow fails during a launch or a sale). Ongoing coverage, like our Run & Improve retainer, exists specifically to answer this question in advance.
Security basics that should be table stakes
- Least-privilege access: the vendor's accounts and API keys should only reach what they need, not admin access to everything
- No secrets in spreadsheets: API keys and passwords belong in a password manager or secrets vault, not a shared sheet
- Audit logging: who changed what, and when, especially for anything touching customer data
- PII handling: know what personal data flows through the system and where it's stored
- Offboarding: when the engagement ends, access should be revoked or transferred — not left open indefinitely
Pricing context: what the market actually looks like
Costs vary a lot by scope, tooling, and who's doing the work. As a general 2026 market reference: one-time automation builds typically run $3,000-$15,000, and retainers roughly $2,500-$8,000/month, according to lets-viz.com. Freelance n8n specialists charge roughly $40-$100/hour, with senior specialists at $125-$250/hour, per Adsnipper. These are ranges that shift with project complexity and location — use them to sanity-check quotes, not to expect an exact match. See our own pricing for how we structure fixed-scope work.
Red flags checklist
- No written scope of work before payment
- Hourly billing only, with no estimate or cap
- No acceptance criteria defined before the build starts
- Vendor refuses to transfer code ownership
- No documentation or handover offered
- Guaranteed results or ROI promises
- Testimonials or client names that can't be verified
- No named person accountable for the project
- Credentials and API keys kept in the vendor's accounts only
- Scope changes get "squeezed in" with no written approval
- No stated response time for post-launch support
- Reluctance to explain what's out of scope
Good sign vs. red flag, by category
| Category | Good sign | Red flag |
|---|---|---|
| Scope | Written SOW with in/out-of-scope lists and assumptions | Verbal agreement or a one-line project description |
| Price | Fixed price tied to a defined scope, with a change-order process | Fixed price quoted before any discovery |
| Ownership | Code, repo, and accounts transfer to you in writing | Vendor keeps the repo or API keys "for maintenance" |
| Support | Named response times and a clear bug-vs-change definition | Vague "we'll take care of it" with no terms |
How our own ladder fits this
We apply the same standards we're describing here. We start with the Ops Teardown — a $490, 60-minute recorded workflow review that ends with a written map of the three highest-ROI automations and a fixed-price quote, delivered in 5 business days. The fee is credited toward a build if you move forward.
From there, most buyers pick one of two paths: an Automation Sprint from $3,500 for a single fixed-scope workflow, or a Custom Software Build from $9,000 for internal tools with logins, roles, and dashboards — you own the code either way. After launch, Run & Improve from $1,500/month covers monitoring, fixes, and one improvement per month, with a report you can actually read.
See full pricing, or contact us if you want a second opinion on a quote you've already received — we're happy to tell you if it looks reasonable, even if that means telling you to stay with your current vendor.