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 moves uncertainty into the build phase, where it can create delays and scope disputes. Start by documenting the workflow and reviewing representative examples. Our free consultation is a chance to discuss scope before deciding whether any paid work is useful.
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 can turn into disputes when a workflow fails. If you need ongoing coverage, compare support scope, available hours, and escalation arrangements. Our optional AI Build Team provides allocated monthly build capacity with support boundaries agreed in writing.
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 start with a free consultation to discuss one real workflow and whether existing software can solve it. Any paid work needs an agreed scope, acceptance criteria, and written quote first.
The available build options are an AI Sprint at $5,000 for a focused workflow, or a Custom Build from $15,000 for a larger application. You own the custom code. An optional AI Build Team starts at $3,500/month for 20 hours of build capacity; monitoring, fixes, and new work share the agreed scope and capacity.
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.