It applies to the project described in the accepted proposal, and it is meant to keep scope, decisions, and handover unambiguous while the work is in motion.
If something is unclear, I would rather write it down and confirm it than guess. These terms explain how I define the baseline scope, how changes are handled, how I ship safely, and what you receive at handover.
What I will build
The project covers custom software development for the deliverables listed below. I start by writing the scope and acceptance criteria in plain language, and that document becomes the baseline for what I build and what you accept at handover.
Anything not covered by the written scope is out of scope by default. If you want to add or change something, I treat it as a change to that same scope document, and I will confirm the impact on timeline and price before I build it. The deliverables for this project are:
* Written scope and acceptance criteria * System design and data model notes * Working web app and API integrations * Automated tests and test harness * Release plan, rollback plan, and runbooks * Repository, credentials, and handover session
Payment
To book the work, I invoice 50% of the total price when you sign the proposal. I invoice the remaining 50% when the finished work is handed over, meaning I have delivered what is in scope and I am ready to transfer the repository, credentials I created, runbooks, and the handover session.
Each invoice is payable within 14 days of its date. If a payment is late, I pause work and I pause any planned release or cutover until the account is up to date. Timelines move by the length of the pause, and I will confirm the updated schedule with you in writing.
Changes and revisions
A revision round means: you review what I delivered against the written acceptance criteria, then you send one consolidated list of changes, and I apply those changes to bring the work in line with the agreed baseline. The number of revision rounds included is the number stated in the accepted proposal.
If you ask for changes beyond the included rounds, or you change requirements mid-way, I will write the change into the scope document and price it before I do the work. I only proceed after your written approval. If an integration behaves differently than the vendor promised, I will show the mismatch and offer a workaround or a scoped change.
Who owns what
Once you have paid in full, you own the code I wrote specifically for this project and the project deliverables I hand over to you. You also get the repository and the credentials I created for this work, so your team can run, maintain, and change the system without needing me.
What I keep are my pre-existing tools, libraries, templates, and general know-how that I use to work efficiently across projects. If I include any third-party components, your use of those stays under their own licenses. I will point out any such dependencies that matter for running or deploying the system.
Portfolio use
Unless you ask me not to, I may show the finished work as a portfolio piece. In practice that usually means a short written case note about the problem and what was delivered, and if it makes sense, a few screenshots or a short screen recording.
If you would rather keep the project private, tell me in writing any time before or after handover and I will not publish it. If you are fine with me mentioning the work but want specific details removed, I can do that too. I will not share your credentials, non-public operational data, or anything that would let someone access your systems.
Limits and risks
I take care with releases, and I plan cutovers with a rollback path, but software work still carries risk, especially around production systems and third-party integrations. I am not responsible for outages or data issues caused by systems I do not control, such as vendor APIs, hosting providers you choose, or changes made by others after handover.
If you request production incident triage and a hotfix release, my first job is to restore service and reduce immediate risk. Deeper root-cause cleanup, refactors, and long-running fixes are handled as a separate scoped change or sprint so you can choose the cost and timing rather than inheriting an open-ended bill.
Ending the project
Either of us can end the project by giving notice in writing. In that notice, I will propose a practical end date based on what is currently in flight, and I will not start new work that would be wasted. If you have a hard deadline driving the stop, tell me and I will aim to align the end date with it.
You pay for the work completed up to the end date. After payment for that completed work, I will hand over what is done so far, including the repository, any credentials I created, and notes needed to continue. If the project ends before completion, unfinished items remain out of scope unless we agree a new project.
Signature
