Contracts · Hiring Developers
Seventeen points to agree in writing before a developer starts, and the red flags to watch for.
Last updated: October 2026. Written by Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions.
Quick answer
Before hiring a developer or agency, agree in writing: scope and deliverables, milestones and payment, change requests, ownership of the work, accounts and access, confidentiality, data protection, acceptance criteria, warranty and bug fixes, support, timeline, subcontractors, third-party costs, documentation and handover, termination, liability and governing law. Keep the app and services in your own accounts, and have a lawyer review the contract.
Key takeaways
- A written scope, ideally a PRD, prevents most disputes.
- Tie payments to milestones and agree a change process.
- You should own the work, the app account, the domain and the data.
- Require documentation and a handover plan.
- This is general information; have a lawyer review the contract.
In this guide
A handshake and a quote are not enough for a software project. When expectations differ about what was promised, who owns the finished app or what happens if the relationship ends, a clear contract is what stops a disagreement becoming a crisis.
This guide is a checklist of points to settle before you hire a developer or agency. It is general information, not legal advice. Have a qualified lawyer review any contract, particularly for larger projects or regulated data.
The checklist
1. Scope and deliverables
A written description of what will be built, ideally referencing a Product Requirements Document, with what is explicitly excluded. Vague scope is the most common source of disputes.
2. Milestones and payment
Payments tied to clear milestones or deliverables, with amounts and due dates. Avoid paying the whole fee up front for work not yet delivered.
3. Change requests
How changes are requested, estimated, approved and paid for. This protects both sides from informal creep. See how to avoid scope creep.
4. Ownership of the work
Who owns the app, designs, data and documentation. Typically you should own what you pay for, though a developer may retain ownership of pre-existing tools and components they reuse. Make this explicit.
5. Accounts and access
The app should live in an account you own, with the developer added as a collaborator. The same applies to the domain, payment, email and other connected services, so that you can always take control if the relationship ends.
6. Confidentiality
A non-disclosure clause covering your business information, your customers’ data and the project itself.
7. Data protection
If the developer will handle personal data, the contract should set out their role, how they will protect it, who else may access it and what happens at the end. Requirements vary by jurisdiction, and some laws require specific terms.
8. Acceptance criteria and testing
How you will confirm that a deliverable meets the agreement, how long you have to review and what happens if it does not.
9. Warranty and bug fixes
A defined period after launch during which defects in the delivered work are fixed at no extra charge, and a definition of what counts as a defect versus a new request.
10. Support and maintenance
What happens after launch: rates, response times and whether there are retainers or minimums. See what Bubble.io maintenance involves.
11. Timeline and delays
Target dates, what each side must provide on time, such as content and feedback, and the consequences of delays on either side.
12. Subcontractors
Whether the developer may use subcontractors, and whether the same confidentiality, security and ownership terms apply to them.
13. Third-party costs and licences
Who pays for the platform plan, plugins, services and licences, and in whose name they are held.
14. Documentation and handover
What documentation you receive, such as the data model, key workflows and integration list, and how handover works if the relationship ends.
15. Termination
How either party can end the contract, notice periods, what is paid for work done and what must be handed over.
16. Liability and insurance
Limits on liability and any insurance the developer holds. Understand what these mean in practice for your risk.
17. Dispute resolution and governing law
Which law applies and how disagreements are handled, for example negotiation first, then mediation or a court.
Quick reference table
| Area | Checkpoint |
|---|---|
| What you get | Scope, deliverables, acceptance criteria |
| What you pay | Milestones, change process, third-party costs |
| What you own | Work product, accounts, data, documentation |
| How it is protected | Confidentiality, data protection, subcontractors |
| What happens after | Warranty, support, handover, termination |
| What if it goes wrong | Delays, liability, disputes |
Red flags in a contract or proposal
- No written scope, or a scope that says only “web app”.
- The app hosted in the developer’s account with no transfer terms.
- Ownership unclear or retained by the developer.
- Full payment up front.
- No process for changes.
- Reluctance to provide documentation.
- Pressure to sign quickly.
How do you make this easier?
A written scope makes the rest simpler. Our Discovery Sprint produces a PRD you can attach to the contract: $345, delivered in 24 hours and credited toward the build. Builds start at $3,500, with the final quote based on scope. See also how to choose a development partner.
Frequently asked questions
What should be in a software development contract?
Scope and deliverables, milestones and payments, change requests, ownership, accounts and access, confidentiality, data protection, acceptance, warranty, support, timeline, subcontractors, documentation, termination, liability and governing law.
Who should own the app I pay for?
Normally you, including the app account, designs, data and documentation, though developers may retain ownership of reusable tools. Make it explicit in writing.
Should I pay everything up front?
It is safer to tie payments to milestones or deliverables.
Do I need a lawyer to review the contract?
It is strongly advisable, especially for larger projects, regulated data or if the terms are unusual.
What is an acceptance criterion?
A condition that must be met for a deliverable to be considered complete, such as a user being able to upload a document and see its status.
Want a clear scope to attach to your contract?
Email us your idea. We will help you produce a PRD and a quote you can build a contract around.
Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions
About Simple Automation Solutions (SA Solutions)
Simple Automation Solutions is a Bubble.io development studio led by Athar Ahmad, a Certified Bubble.io Developer and Tech Architect. It builds web and mobile apps, client portals and SaaS products for founder-led businesses such as law firms, accounting firms, boutique agencies and consultants. Services include a free 30-minute Idea Audit, a $345 Discovery Sprint (a Product Requirements Document delivered within 24 hours, credited toward the build) and builds starting at $3,500. Website: sasolutionspk.com.
