A common scene: the owner gets a one-page quote, finds it cheap, and signs. Six months later — redesign, vendor switch, or stalling — they find the contract never spelled out acceptance criteria, who owns the source code, or how data transfers on exit. A preventable dispute becomes he-said-she-said, the launch slips, and it costs extra. Seventy percent of outsourcing success isn''t in the code — it''s whether the contract said the awkward parts up front.
Myths Busted
- "Low price = good deal": a contract silent on maintenance and exit loses the savings to add-ons and migration.
- "The source code is obviously mine": many contracts deliver a website but not the source and deploy access.
- "Acceptance means it opens": without quantified criteria, it becomes endless wrangling.
- "Free fixes during warranty": undefined warranty-vs-change lets every bug be billed as new.
Core Framework: The 8-Clause Checklist
- ☐ 1. Scope (SOW): deliverables, marking what''s excluded.
- ☐ 2. Acceptance criteria: quantified.
- ☐ 3. IP: source, design files, third-party licenses.
- ☐ 4. Payment milestones: tied to deliverables.
- ☐ 5. Warranty vs change request.
- ☐ 6. Maintenance: scope, response SLA.
- ☐ 7. Exit & data handover.
- ☐ 8. Confidentiality & liability cap.
Three Typical Scenarios
- 5-person shop, brand site: focus on clauses 1, 3, 7.
- 30-person e-commerce: focus on clauses 5, 6, 8.
- Manufacturing B2B integration: focus on clauses 2, 4, 7.
Hidden Cost List
- No acceptance criteria → back-and-forth labor (10-20% of project).
- No source code → redo cost when switching, paying for development twice.
- No maintenance SLA → a single firefight often exceeds a year of monthly fees.
- No exit clause → data and domain held hostage, weeks of migration delay.
Vendor KPI Scorecard
- Contract completeness: 25%
- Quote transparency: 15%
- Technical communication: 15%
- Verifiable past work: 15%
- Maintenance & response SLA: 15%
- Exit-friendliness: 15%
ScriptWalker's Approach + Where We're Not a Fit
Our contracts include the 8 clauses by default, with source code and deploy access delivered, in retainer (with SLA) and project models. Not a fit for: very low budget "just works," zero-involvement clients demanding perfection, or weekly major changes outside a change process.
Transition Playbook
- Month 1: document SOW and acceptance criteria; set milestones and payment nodes.
- Months 2-3: sign off each deliverable against criteria, keeping records.
- Day 90: review whether the SLA held; confirm source and docs handed to client accounts.
Decision Checklist
- ☐ Does the contract state what''s excluded?
- ☐ Are acceptance criteria quantified?
- ☐ Are source and deploy access explicitly mine?
- ☐ Are payments tied to milestones?
- ☐ Is the warranty-vs-new line clear?
- ☐ Is maintenance covered by a written SLA?
- ☐ Does a data-handover list exist?
- ☐ Are confidentiality and liability caps stated?
FAQ
Is it normal for a vendor to refuse to put source code in the contract?
It depends on the model. SaaS vendors genuinely don''t hand over source, but it must be stated upfront; for custom development, no source is a red flag.
How do I write acceptance criteria so they don''t cause disputes?
Use objectively judgeable conditions: browser versions, mobile LCP thresholds, severe-bug definitions and fix windows, acceptance days.
Monthly maintenance or per-incident?
For sites with continuous updates or live payments, retainer + SLA is usually cheaper and safer; for static sites, per-incident is fine.
Call to Action
Want someone to read your contract for traps before you sign? We offer a free 30-minute contract check-up mapping it against the 8 clauses.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p