This agreement covers the web app build described in the proposal you accepted, and it sets the ground rules for how I’ll deliver it.
I work in small, visible steps: I confirm scope in writing, build through pull requests, and close with a handover your team can run and maintain. If anything in the proposal and these terms disagree, I’ll flag it early and we’ll sort it out in writing before it turns into a surprise.
What I’m building
The web app build is the specific feature set and handover package described in the accepted proposal. I’ll deliver the items listed below, and I’ll do the work in your repo and follow your branching, review, and PR process as long as you can give me access and a clear point person for decisions.
I can start once I have repo access, a written work list (tickets or similar), one named person who can answer scope questions quickly, and access to the environments I’m expected to touch through your usual secrets process. If any of those are missing, I can’t responsibly commit to dates yet, and I’ll tell you what’s blocking progress.
* Written scope and estimate * Repo baseline report * Feature pull requests * Test and release notes * Handover notes and walkthrough * Access and ownership transfer checklist
Payment
To book the work, you pay 25% of the project price when this agreement is signed. I schedule the work once that booking payment is in. The remaining 75% is due when the finished work is handed over, meaning the agreed code is merged, tests are run as agreed, release notes are written, and you’ve received handover notes with a walkthrough.
I invoice in USD. Each invoice is payable within 14 days of its date. If a payment becomes overdue, I pause work and pause any planned releases or handover until the account is back up to date. If a delay in payment causes me to miss a slot I held for you, we’ll rebook based on my next availability.
Reviews and changes
My default delivery loop is: I open a pull request, you review it, and I address feedback until that pull request is accepted against the written scope. Two rounds of review are included for each scoped feature or PR. A “round” means you give consolidated feedback, I make a pass to address it, and you re-review.
If feedback arrives in large batches, reviews stall, or the scope changes, timelines can move by the same number of waiting days. If you want changes beyond the included review rounds, I’ll write up what changes, what it does to cost and timing, and I’ll get your written OK before I continue. Nothing expands quietly through chat messages or a comment thread.
Who owns what
Once you’ve paid the final invoice in full, you own the code I wrote specifically for your web app build, along with the project documentation I deliver as part of handover. If I’m working in your existing repo, you also keep ownership of your pre-existing code, data, and accounts throughout.
I keep ownership of my general tools, reusable snippets, templates, and know-how, even if I use them while working with you. That means you get the finished result you paid for, and I can still reuse my own building blocks on other projects. If there’s any third-party code or service involved that comes with its own licence or terms, I’ll call it out as I add it.
Portfolio use
Unless you ask me not to in writing, I may show the finished work as part of my portfolio. In practice, that usually means a short case study describing the problem, what I built, and the outcome, plus a few screenshots or a link if it’s public.
If your work needs to stay quiet, I’m fine with that. Tell me what you’re comfortable with: for example, no mention at all, or a private summary without your name, or “launch after” a certain date. I’ll follow your written request and I won’t share private repo links, customer data, credentials, or internal documentation.
Problems and limits
I take responsibility for delivering the web app build as agreed, and for fixing bugs that are in the shipped scope as part of closing the work. I also take reasonable care with your systems and access, and I follow your secrets process rather than copying credentials around.
What I can’t take responsibility for are things I don’t control: outages or changes in third-party services, infrastructure you manage, or issues caused by code changes made by others after I deliver. I also can’t promise that software will be completely error-free. If something goes wrong, you agree to tell me promptly so I can help you diagnose it, and I’ll focus first on restoring service and then on a clean fix.
Ending the work
Either of us can end the project by giving notice in writing. In that notice, I’ll confirm what I’ve done so far, what’s in progress, and what I can reasonably hand over by the end date. We’ll agree the notice period in writing based on where the work sits, because ending mid-sprint is different from ending between milestones.
If the project ends early, you pay for the work completed up to the end date, plus any committed costs you asked me to take on. At wrap-up I’ll hand over what I have that’s useful: the current branch or merged code, notes on what’s done and what’s next, and access and ownership transfer steps that can be completed at that point. If you’ve paid in full for delivered work, you can keep using it.
Signature
