Signing a contract with a software developer or development firm is one of the higher-stakes decisions a business owner makes. The cost is significant, the timeline is long, and the thing you're buying is invisible until it's built. Most people who have been through a bad software engagement say the same thing afterwards: the problems were predictable, and they wished they had asked different questions upfront.
This post covers what those questions are. It applies whether you are working with a freelance developer, a small agency, or a larger development firm.
Who owns the code?
In most software contracts, the developer owns the code by default unless the contract explicitly states otherwise. This surprises many business owners, but it is the default position in most jurisdictions under copyright law — code written by a contractor belongs to the contractor unless it is explicitly assigned to you.
Before signing, confirm the contract includes an IP assignment clause that transfers ownership of all work to you upon payment. The language should cover not just the final deliverable, but also any interim code, libraries written specifically for your project, and documentation.
Also ask whether the developer plans to use open-source libraries in your project, and whether any carry licences that create obligations for you. Most open-source licences are permissive, but copyleft licences — such as the GPL — impose conditions on how you can distribute software that incorporates them. You want to understand this before you build.
What exactly is included in the scope?
The scope section is where most software contract disputes begin. A vague scope — "build a customer portal with login and reporting" — leaves enormous room for disagreement about what was promised and what constitutes a billable change request.
Before signing, the scope should specify at minimum:
- The features being built, described in enough detail that both parties would recognise when each one is complete
- The platforms and devices it will support (web browser, iOS, Android, specific operating systems)
- Whether the developer is responsible for design and UX, or whether they are building to designs you provide
- What "done" means — concrete acceptance criteria for each deliverable
If the developer cannot or will not provide this level of specificity before signing, that is a warning sign. Vague scopes generally benefit the developer, not you. Read more about how to structure this upfront: how to scope a custom software project.
How are changes priced?
Requirements change during a software build. This is not a failure — it is normal. What matters is that the process for handling changes is clear before work starts.
Ask specifically: what qualifies as a change request, how is the additional cost estimated, and what authorisation is required before a change can be actioned.
A well-run process involves a written change request document that describes what is changing, the estimated additional cost, and any impact on the timeline. Both parties sign off before work begins. This protects you from invoice surprises and protects the developer from scope creep that erodes their margin.
If the contract does not address change management, or if the developer's answer is vague, request a written addendum before you sign.
What happens after launch?
Most of the lifetime cost of custom software comes after the initial build, not during it. There will be bugs to fix, infrastructure to maintain, and features you want to add. The contract should be clear about who handles each of these and at what cost.
Ask these questions specifically:
- What warranty period is included, and what does it cover? A standard warranty covers functionality that was promised but is not working correctly — not new features or scope changes.
- After the warranty period, what is the ongoing support model? Is there a retainer option, and what does it include?
- Who is responsible for security updates to the underlying infrastructure and third-party libraries the software depends on?
Many development contracts are silent on post-launch support, which means the developer has no ongoing obligation after delivery. This is not unreasonable — maintenance is separate work — but you need to know this upfront so you can budget for it and have a plan in place before you launch.
Can you take the project elsewhere if things go wrong?
The ability to exit and move your project to another developer is an underrated form of risk management. Not all working relationships succeed, and you want to be sure that if the relationship ends — for any reason — you can continue without starting over.
Ask whether the contract includes a termination clause, what triggers it, and what happens to the code and documentation you have paid for up to that point. The answer should be that you receive all work completed to date, in a usable state, with no conditions attached beyond payment of what is owed.
Also ask: is the code being written in a way that another developer could take it over? This means standard languages, standard frameworks, and decisions that are documented rather than held in the original developer's head. Unusual or bespoke tooling creates practical lock-in even when the contract allows you to leave. This is the same problem as vendor lock-in in software generally — worth understanding before you are in the middle of a project.
Who will actually do the work?
This matters most when engaging agencies. The person who sold you the project is often not the person building it. Ask specifically who will be assigned to your project, what their experience level is, and whether that team could change during the engagement.
If you are hiring a freelancer through a referral or marketplace, ask for examples of comparable projects they have completed and whether you can speak with a previous client. A developer confident in their work will not hesitate to provide references.
What does the timeline actually account for?
Software projects are almost universally late. This is not always a reflection of bad faith — estimates made before detailed design work are rough by nature, and software development has genuine uncertainty built in. But some timeline structures produce more reliable delivery than others.
Ask the developer to break the project into phases with separate milestones and payments tied to each phase. This gives you visibility into progress, creates accountability checkpoints, and limits your financial exposure if the project stalls. Paying everything upfront on a fixed-price contract removes the developer's incentive to deliver on schedule.
Also ask what the plan is if the timeline slips significantly. A developer with a clear process for managing delays will have a straightforward answer.
A note on price
A low quote is not the same as good value. The most expensive part of a failed software project is not the money you paid to the original developer — it is the time lost and the cost of starting over with someone else.
The questions above are not about being adversarial. They are about establishing clear expectations on both sides before work starts. A developer who is uncomfortable with any of these questions — or who resists putting specifics in writing — is giving you useful information before you have committed to anything.
If you are preparing to engage a developer and want a second opinion on the contract or the approach, get in touch. At Clear Frame AI, I help businesses scope, evaluate, and oversee custom software projects — including reviewing what a proposed contract is and is not committing you to. You can also read more about when custom software makes more sense than buying an off-the-shelf product or how to validate a software idea before you build it.