“What the contract does not say is as important as what it does. Silence on IP, on access, or on change management is where founders get burned.”
Reading between the linesThe contract you sign before a software development project starts determines what you own when it ends, what happens if things go wrong, and what recourse you have if they go very wrong. Most founders read contracts too quickly — looking at the price and the timeline and assuming the rest is standard. Some of the most important clauses are the ones buried in the standard language.
This guide covers the specific red flags to look for in software development contracts, what they typically mean, and what to ask for instead.
Red Flag 1: IP Ownership Is Silent or Ambiguous
In most jurisdictions, the creator of a work owns it unless there is a written agreement assigning ownership elsewhere. If your development contract does not explicitly state that all code, designs, documentation, and related intellectual property is assigned to you upon payment, the default position may favour the agency.
Look for language like: 'Upon receipt of final payment, all intellectual property rights in the deliverables are assigned to the client.' If the contract uses 'licence' instead of 'assign', you are being granted the right to use the work, not ownership of it. These are different things with different implications if the relationship ends badly.
Red Flag 2: Front-Loaded Payment Terms
A payment structure that asks for 50% or more upfront before significant work is delivered transfers significant risk to you. If the agency delivers poor work or fails to deliver at all, recovering money paid upfront is difficult and slow.
Standard protection: no more than 25 to 30% of the total contract value on signing, with the remainder tied to specific, verifiable delivery milestones. The final payment — typically 20 to 25% — should be tied to final acceptance testing, not a calendar date.
Red Flag 3: Deliverables Are Described Vaguely
A contract that describes the deliverable as 'a mobile application with user authentication and core features' is not a contract — it is a statement of intent. When deliverables are vague, disputes about whether they were delivered are inevitable.
Every deliverable should have specific acceptance criteria. Not 'a working payment flow' but 'a payment integration using Stripe, supporting credit card and PayPal, handling success, decline, and network error states, tested on iOS 17 and Android 14, with a test evidence document provided.' That level of specificity takes longer to write. It prevents disputes that take even longer to resolve.
Red Flag 4: No Change Management Process
Projects change. Requirements evolve. Features that seemed essential turn out to be low priority, and features that were not in the original brief turn out to be critical. Every development contract should have a documented process for how changes are raised, scoped, priced, and approved.
Contracts without this process create three bad outcomes: agencies build change requests into their margin and charge premium rates when they arise, disputes about what was and was not in scope become regular occurrences, or the project delivery slows significantly every time a change is required because there is no agreed process for handling it.
Red Flag 5: No Post-Launch Warranty
Software delivered at the end of a project will have bugs. Some of these will appear immediately. Some will appear when users do things the development team did not anticipate. A post-launch warranty period — typically 30 to 90 days — during which the agency fixes bugs in the delivered work at no extra cost is standard practice.
Contracts with no warranty period, or with language that treats every post-launch issue as billable work, are below standard. Some bugs are inevitable. The question is who bears the cost of the ones in the delivered scope.
Red Flag 6: Repository Access Is Not Addressed
You should have access to your own code repository from day one. This is non-negotiable. If the contract does not explicitly state that you will have full access to the repository throughout the project and that ownership will be transferred to your account at completion, add this language before signing.
- Ensure you have owner-level access, not just collaborator access
- Confirm that the repository is in your account or organisation, not the agency's
- Ensure all deployment credentials are stored in your accounts and documented in writing
- Confirm that cloud infrastructure (AWS, Google Cloud, Vercel) is set up under your accounts, not the agency's
