This is the working agreement we use to keep scope, decisions, and handover tidy so the build you see in reviews is the same build that holds up in production. If anything in the proposal and this agreement conflict, we will talk it through and put the final version in writing before we act on it.
What you get
Software development means we build what is written in the scope and assumptions and the deliverables list below, and we build it to the level needed for real users, not just a demo. Anything that is not written down is out of scope by default, even if it felt implied in a call or a message.
Your proposal lists the deliverables for this project. That list is what we will deliver, along with reasonable testing, release hardening, and the handover pack needed to run and maintain what we ship.
* Written scope and assumptions * Clickable prototype * Working web or mobile build * API and database source code * Integration setup * Deployment and handover pack
Payment
To book the work, we invoice 40% of the project price when you sign. We start scheduling and committing team time once that booking invoice is in place. We invoice the remaining 60% when the finished work is handed over, which is when we provide the repository, deployment notes, and the handover pack promised in the proposal.
Each invoice is payable within 14 days of its invoice date. If a payment runs late, we will tell you what is overdue and what it blocks. We may pause work, delay release, or hold back handover until the account is back up to date, because unpaid work quickly turns into rushed work and risk.
Changes
We plan the work in small review points so you can steer without surprises. A revision round means we show you what we have, collect feedback in one place, and then we make a pass to address that feedback. The proposal sets how many revision rounds are included and what each round covers, and we stick to that.
If you want something that goes beyond the included rounds, or a request changes cost, timeline, or risk, we log it as a change before we start on it. You can approve the change as quoted, or we can trade it against something already in scope so the project stays on track.
Who owns what
Once the final invoice is paid, you own the code we write for you for this project, including the project repository and its commit history. Until then, you can use what we deliver for internal testing and review, but you cannot resell it or transfer it to another party.
We keep ownership of our pre-existing tools, templates, libraries, and know-how, even if we use them while delivering your project. We also keep our working notes and internal checklists. If we include any third-party components, they stay under their own licences, and we will flag them so you know what you are relying on.
Portfolio use
Unless you ask us not to in writing, we may show the finished work as a portfolio example. In practice this usually means a short case study and screenshots, and sometimes a link to the live product once it is public.
If your product is not public yet, or if there are confidentiality or competitive reasons to keep things quiet, tell us. We can delay portfolio use, keep it anonymous, or avoid showing sensitive screens. We will not share private data, credentials, or anything that would put your users or systems at risk.
Problems and limits
We take responsibility for the work we ship, and we do not disappear after launch. After go-live we triage issues by severity and fix blockers first. If a bug is in our code, we fix it. If the issue is a new request, a changed requirement, or something caused by changes made outside our control, we will quote it as new work.
We are not responsible for outages or losses caused by third-party services, hosting providers, app stores, payment processors, or tools you control, even if we helped with the integration. We also cannot promise that software will be defect-free, but we can promise to be organised about finding, prioritising, and fixing defects.
Ending the project
Either of us can end the project by giving notice in writing. Because the right notice period depends on where we are in the build, we will agree the notice period with you in writing at the time, with the goal of keeping a clean stop rather than a messy one.
If the project ends early, you pay for the work completed up to the end date, including any booked time we could not reasonably reallocate. We will then hand over what is done so far: the repository access you already have, the latest build, and any deployment notes we have created. If you want us to help the next team take over, we can quote that handover support separately.
Signature
