You're about to sign a development contract. The agency seems great. The price is right. The timeline works. You skim the 12-page agreement, see nothing obviously alarming, and sign.
January 8, 2025 14 min read
You're about to sign a development contract. The agency seems great. The price is right. The timeline works. You skim the 12-page agreement, see nothing obviously alarming, and sign.
Six months later, you're raising a seed round. During due diligence, your lawyer points to section 8.3 of that contract: "Developer retains ownership of all pre-existing IP and reusable components." Investors ask: do you actually own your product's code? The answer isn't clear. Deal gets complicated or dies.
This happens more than founders realize. Here are the contract clauses that kill startups.
Red Flag 1: Ambiguous Intellectual Property Ownership
This is the most critical clause in any development contract. Get it wrong and you might not own what you paid to build.
The Language That Protects You
What you need: "All work product, including but not limited to code, designs, documentation, and related materials created under this agreement, is the exclusive property of Client. Developer assigns all rights, title, and interest to Client effective immediately upon creation. This constitutes a work-made-for-hire agreement under applicable copyright law."
Why it matters: This clearly transfers all IP to you immediately. No ambiguity. No delayed transfer. No retained rights for the developer.
The Language That Exposes You
Dangerous clause 1: "Upon final payment, Developer transfers IP rights to Client."
The problem: What if the project ends mid-stream? What if you stop paying because the work is incomplete? IP ownership is unclear during development. If the developer disappears, you don't own the half-built code until you pay in full—but you shouldn't pay in full for incomplete work. Catch-22.
"Developer grants Client a perpetual, royalty-free license to use the delivered work product."
Stop planning and start building. We turn your idea into a production-ready product in 6-8 weeks.
Dangerous clause 2:
The problem: License is not ownership. You can use the code, but the developer still owns it. They could license the same code to competitors. You can't sell the code as an asset. Investors will see this as a fatal flaw.
Dangerous clause 3: "IP transfers upon project completion and full payment."
The problem: "Project completion" is subjective. If there's a dispute about whether the project is complete, IP ownership is contested. Developer claims it's not done. You claim it is. Meanwhile, neither party clearly owns the code.
Dangerous clause 4: "Developer retains ownership of frameworks, libraries, and reusable components."
The problem: What counts as "reusable components"? If they built your entire product using their internal framework, they might claim ownership of 80% of your codebase. This is common with offshore agencies.
How to Fix It
Insist on immediate IP assignment upon creation, not upon payment or completion. Use work-made-for-hire language explicitly. If the developer wants to retain ownership of their pre-existing frameworks or tools, those must be explicitly listed in an appendix, not covered by a vague clause.
Red Flag 2: Unlimited Liability Caps or No Liability Caps
Contracts need to define what happens when things go wrong. Liability clauses determine financial risk.
The Balanced Approach
What you need: "Developer's total liability under this agreement is capped at the total amount paid by Client under this agreement, except in cases of gross negligence, willful misconduct, IP infringement, or breach of confidentiality."
Why it matters: This protects both parties. The developer isn't risking unlimited liability for good-faith mistakes. You're protected from IP infringement or confidentiality breaches that could have massive damages.
The Dangerous Extremes
Dangerous clause 1: "Developer's liability is limited to $500, regardless of damages."
The problem: If they build something that infringes third-party IP and you get sued, or they expose your user data causing regulatory fines, you're on the hook for potentially millions while they're capped at $500. This is absurdly one-sided.
Dangerous clause 2: "Client agrees to indemnify and hold Developer harmless from any and all claims arising from the project."
The problem: You're agreeing to cover their legal costs and damages if they screw up. They build something that violates patents? You pay. They leak your data? You pay. Never agree to this.
Dangerous clause 3: No liability clause at all.
The problem: Without a defined liability cap, disputes default to whatever a court decides. Unlimited risk for both parties.
What's Fair
Liability capped at contract value is industry standard. Some agencies push for 50% of contract value. Don't accept less than 100%. For enterprise projects, consider requiring errors and omissions (E&O) insurance from the agency.
Red Flag 3: No Clear Scope Change Process
Every project has scope changes. How they're handled determines whether your budget explodes.
The Process You Need
What you need: "Changes to the defined scope require written approval from both parties, including revised timeline and budget. Minor clarifications (under 4 hours of work) do not constitute scope changes. Major additions require a formal change order."
Why it matters: This protects you from surprise bills for work you thought was included. It also protects the developer from unlimited free work.
The Clauses That Enable Abuse
Dangerous clause 1: "Any work outside the initial specification will be billed at $XXX/hour."
The problem: Everything becomes "outside the initial specification." Specifications are never perfect. Developers can interpret narrowly and bill for every small addition. A $40,000 fixed-price project becomes $70,000.
Dangerous clause 2: "Client requests for changes, revisions, or additions will be accommodated at Developer's discretion and billed accordingly."
The problem: "At Developer's discretion" means they decide what's in scope, what's a change, and how much to charge. You have no control.
Dangerous clause 3: No scope change process defined at all.
The problem: Every disagreement about what was "included" becomes a fight. No framework for resolving disputes. Projects stall.
How to Protect Yourself
Define "scope" clearly in an appendix with detailed feature descriptions. Specify that developer must notify client of potential scope changes before doing the work. Require written approval for changes exceeding a small threshold (e.g., 4 hours). Include a mechanism for resolving scope disputes (e.g., refer to original specifications).
You're sharing business strategy, user data, API credentials, and proprietary information. Confidentiality clauses protect this.
The Protection You Need
What you need: "Developer agrees to maintain strict confidentiality of all Client information, including but not limited to business plans, user data, technical specifications, API credentials, and any information marked confidential or that reasonably should be considered confidential. This obligation survives termination of this agreement indefinitely."
Why it matters: Your business secrets stay secret. Credentials don't get leaked. Competitors don't learn your strategy.
The Gaps That Create Risk
Dangerous clause 1: "Developer agrees to keep confidential information confidential for the duration of the project."
The problem: Confidentiality ends when the project ends. Six months later, the developer could share your entire strategy with competitors. Always require confidentiality to survive termination.
Dangerous clause 2: "Developer will not share Client's confidential information except where required for project completion."
The problem: "Required for project completion" is broad. They could justify sharing your data with subcontractors, other team members, or third-party services without your approval. Require explicit approval for any sharing.
Dangerous clause 3: No confidentiality clause at all.
The problem: No legal recourse if they leak information, share credentials, or disclose your strategy. Especially dangerous with offshore agencies where enforcement is harder.
Additional Protections
Require that developer's team members sign confidentiality agreements. Specify how credentials and access should be handled (password managers, not shared docs). Include penalties for breach (liquidated damages).
Red Flag 5: Developer Controls Access to Critical Infrastructure
Who owns the accounts where your product lives? This determines whether you can recover if the relationship ends.
The Structure That Protects You
What you need: "Client creates and maintains ownership of all accounts including but not limited to: hosting (AWS, Vercel, etc.), domain registration, code repositories (GitHub), database services, and third-party APIs. Developer is granted access as needed and access is revoked upon project completion or termination."
Why it matters: If you own the accounts, you can never be locked out of your own product. Developer leaves? You still have access to everything.
The Structure That Creates Dependency
Dangerous pattern 1: Developer creates GitHub repository under their organization. Code lives in their account.
The problem: If the relationship ends badly, they control access to your code. You're dependent on their willingness to transfer it. We've seen developers hold code hostage during payment disputes.
Dangerous pattern 2: Developer deploys to their AWS account and "manages hosting for you."
The problem: You don't control your own infrastructure. Can't make emergency fixes. Can't migrate to a different developer. Monthly hosting costs go through them, often with markup.
Dangerous pattern 3: Developer registers domain in their name "to simplify setup."
The problem: Your brand, your domain, their ownership. Transferring domains is painful. Some developers use this as leverage in disputes.
Dangerous pattern 4: Developer controls access to Stripe, authentication services, or email sending accounts.
The problem: These are critical business functions. If they shut off access, your product stops working immediately.
How to Structure It Correctly
Day one: You create GitHub organization, AWS account, Vercel project, Stripe account, domain registrar account. Everything is under your ownership.
Developer access: You invite developer as admin or contributor. They can work but don't own the accounts.
Credentials: Stored in a password manager you control. Shared securely with developer for duration of project.
Post-project: Revoke developer access. Change critical credentials. You retain full control.
How and when you pay determines your leverage if quality or delivery is poor.
Payment Structures That Protect You
Milestone-based payments tied to deliverables: "Payment schedule: 25% upon contract signing, 25% upon design approval, 25% upon MVP feature completion, 25% upon final delivery and acceptance testing."
Why it works: You only pay for delivered, accepted work. If quality is poor or deadlines slip, you withhold payment until issues are resolved. Developer is incentivized to meet milestones properly.
Acceptance testing window: "Client has 5 business days to test deliverables and request revisions. Payment released upon acceptance or end of testing window if no issues raised."
Why it works: You have time to verify quality before releasing payment. Bugs found during testing get fixed before final payment.
Payment Terms That Expose You
Dangerous structure 1: "50% upfront, 50% upon project start."
The problem: You've paid 100% before receiving anything. Developer has your money and no incentive to prioritize your project or maintain quality. If they disappear, you have no leverage and no recourse.
Dangerous structure 2: "Payment due upon delivery, acceptance testing period after payment."
The problem: You pay before verifying quality. If bugs surface during testing, you've already paid. Developer has little incentive to fix issues quickly.
Dangerous structure 3: "Monthly retainer with no deliverable milestones."
The problem: You're paying for time, not results. Developer can work slowly, bill fully, and deliver little. No accountability to timelines.
Dangerous structure 4: "Payment required before source code delivery."
The problem: Hostage situation. Developer holds the code until you pay, even if the work is incomplete or poor quality. We've seen this with offshore agencies especially.
What's Fair
Fixed-price projects: 25% upfront, 50% across 2-3 milestone payments, 25% final payment after acceptance testing.
Time and materials: Weekly or biweekly invoicing for work completed, never more than 2 weeks payment in advance.
Escrow for large projects: For contracts over $100K, consider escrow services where money is released to developer upon verified milestone completion.
Relationships end. Termination clauses define how and at what cost.
The Terms That Protect Both Parties
What you need: "Either party may terminate this agreement with 14 days written notice. Upon termination, Client receives all work completed to date including source code, designs, and documentation. Client pays for all work completed and accepted prior to termination date. IP for completed work transfers to Client upon payment."
Why it matters: You can exit if the relationship isn't working. You get what you've paid for. Developer gets paid for legitimate work completed. Clean separation.
The Clauses That Trap You
Dangerous clause 1: "Early termination requires payment of 50% of remaining contract value as termination fee."
The problem: If you've paid $20K of a $60K project and it's going badly, terminating costs you an additional $20K (50% of remaining $40K). You're penalized for ending a failed relationship. This traps you in bad partnerships.
Dangerous clause 2: "Developer retains all work product in event of early termination."
The problem: You paid $30K for half the project, but you get nothing if you terminate. Developer keeps the code and IP. You start over from scratch with someone new. Always require delivery of work completed to date.
Dangerous clause 3: "Termination must be for cause, defined as material breach. Convenience termination not permitted."
The problem: "Material breach" is hard to prove. If developer is just slow or difficult but technically meeting contract terms, you can't exit. You're stuck for the duration.
Dangerous clause 4: "Termination requires 90 days notice."
The problem: Three months of paying for work you know is going poorly. Developer has no urgency to improve. 14-30 days is standard and fair.
What's Reasonable
Both parties should have the right to terminate with reasonable notice (14-30 days). Client should receive all completed work upon terminating. Client pays for completed work only, not for unperformed future work. No termination penalties beyond payment for work delivered.
Some agencies require 30-60 day notice for large projects. That's reasonable if they're staffing a dedicated team. But 90+ days or termination fees are red flags.
The Contract Review Checklist
Before signing any development agreement, verify these protections exist.
IP ownership:
[ ] Work-made-for-hire language explicitly transfers IP to client
[ ] Transfer is immediate upon creation, not upon payment
[ ] Pre-existing developer IP is clearly listed in an appendix
[ ] No vague "reusable components" clauses
Liability protection:
[ ] Liability capped at contract value or higher
[ ] Exceptions for gross negligence, IP infringement, confidentiality breach
[ ] No unlimited indemnification clauses favoring developer
Scope and changes:
[ ] Detailed scope in appendix with feature descriptions
[ ] Clear change order process requiring written approval
[ ] Definition of what constitutes in-scope vs. out-of-scope work
[ ] Covers all business information, technical specs, and credentials
[ ] Restricts sharing with third parties without approval
Infrastructure control:
[ ] Client owns all accounts (GitHub, hosting, domains, APIs)
[ ] Developer has temporary access only
[ ] Access revocation process defined
Payment terms:
[ ] Milestone-based payments tied to deliverables
[ ] Acceptance testing window before final payment
[ ] No more than 25-30% upfront payment
Termination rights:
[ ] Either party can terminate with 14-30 days notice
[ ] Client receives all completed work upon termination
[ ] No excessive termination fees (max 10-20% is reasonable)
[ ] IP for completed work transfers upon termination
If your contract fails 2+ of these checks, don't sign it. Request revisions or find a different vendor.
What to Do This Week
If you're about to sign a development contract, take these steps.
Get legal review. Spend $500-1,500 for a startup lawyer to review the contract. This is cheap insurance against expensive mistakes. Lawyers catch clauses you'll miss.
Request revisions to any red flag clauses. Good agencies expect negotiation. Send back a redline with requested changes. If they refuse all changes, that's a red flag about the relationship.
Compare to standard templates. Look at Y Combinator's SAFE templates or Cooley GO startup legal documents. These show what reasonable terms look like.
Talk to other founders who worked with this agency. Ask specifically about IP ownership, payment disputes, and termination. Were contracts honored?
Create your own accounts before starting. Don't wait for the developer to do it. Set up GitHub, hosting, and domains under your ownership day one.
Most marketing automation apps treat AI as a feature to add later. Here's why that approach fails—and how to architect AI-native marketing automation from day one.
