DraxCoders Standard Engagement Terms
Version 1.0, 3 August 2026. These are the standard terms on which DraxCoders works with partners. They apply to every engagement unless a signed statement of work says otherwise.
These are terms between DraxCoders and a Partner: a business that sells software development to its own customers and buys the engineering from us. The Partner's customer is referred to as the Client. The Client is not a party to these terms and, in the ordinary case, never learns they exist.
1. What we are agreeing
1.1 DraxCoders provides software design, development and related engineering services to the Partner. The Partner contracts separately with its Client and remains solely responsible for that relationship.
1.2 These terms apply to every engagement between us unless a signed order or statement of work says otherwise for that engagement. Where they conflict, the signed statement of work wins for that piece of work only.
1.3 We are an independent supplier, not an employee, agent or partner in the legal sense, and neither party may bind the other to a third party.
2. Working under the Partner's name
2.1 No contact with the Client. We will not contact the Partner's Client, or respond to contact from them, except where the Partner asks us to in writing for a specific purpose. Where the Partner invites us into a meeting or a call with their Client, we attend as part of the Partner's team and take our lead from the Partner on how we are introduced. We will not offer the Client our own contact details, our own services, or our own opinion of the Partner.
2.2 Non-solicitation. For the duration of an engagement and for twelve months after its completion or termination, we will not solicit, canvass or accept development work from any Client we became aware of through the Partner, whether directly or through another business. This survives termination and applies however the engagement ends, including where the Partner has not paid us. If a Client approaches us unprompted, we will tell the Partner and will not proceed without the Partner's written agreement.
2.3 Attribution and branding. Deliverables carry the Partner's branding, or no branding, at the Partner's choice. We will not place our name, mark, comment, metadata, link or credit of any kind in delivered code, documents or interfaces. We will not name the Partner or the Client in our marketing, case studies, website or portfolio, and will not describe an engagement publicly in terms specific enough to identify either, without the Partner's written consent.
2.4 Confidentiality, both ways. Each party keeps the other's confidential information confidential, uses it only for the engagement, and returns or destroys it on request. The existence and terms of the arrangement between us are themselves confidential, which is the point of it. This obligation continues for three years after the engagement ends, and indefinitely for anything that is a trade secret or personal data.
2.5 Our people. Anyone we put on an engagement is bound by obligations at least as strict as those in this section. We remain responsible for their compliance.
3. Where the code lives, and who owns it
3.1 Delivered into the Partner's control from the start. Work is committed to a source control repository owned by the Partner, or to one we hold and transfer at the Partner's request at any time and without charge. There is no point in an engagement at which the Partner cannot obtain everything written so far.
3.2 Ownership transfers on payment. On payment in full for a given piece of work, all intellectual property rights in the deliverables for that work pass to the Partner, who is then free to assign them onward to their Client. This includes source code, database schemas, deployment tooling, configuration and documentation.
3.3 Before payment, the Partner holds a licence to use the delivered work for evaluation and internal review, but not to put it into commercial service.
3.4 What does not transfer. General know how, and any pre-existing or generic component we owned before the engagement or developed independently of it. Where a deliverable contains such a component, the Partner receives a perpetual, worldwide, irrevocable, royalty free licence to use, modify and sublicense it as part of that deliverable, including onward to their Client. The practical effect is that nothing we retain can ever prevent the Partner or their Client from using, changing or reselling what was delivered.
3.5 Third party components. We will use open source and third party components where sensible, and will disclose them and their licences on request. We will not knowingly include anything whose licence would restrict the Partner's or the Client's commercial use.
3.6 No lock in. We will not deliver work that requires our continued involvement, our hosting, or a service only we can operate. Documentation will be sufficient for a competent developer who has never spoken to us.
4. Scoping, pricing and quotations
4.1 Scoping before the Partner pitches is free. We will review a brief and give the Partner a fixed price and an indicative timescale at no cost and with no obligation on either side. We do not charge for this and do not make it conditional on winning the work.
4.2 The figure holds for 60 days from the date we issue it, provided the scope we were given does not change. The Partner may put whatever margin they choose on top; our figure is our price to the Partner and we take no interest in what the Partner charges their Client.
4.3 Fixed price means fixed. Where a fixed price is agreed against a defined scope, that price does not move because the work turned out to be harder than we estimated. That risk is ours.
4.4 Change control. Work outside the agreed scope is quoted separately and started only on the Partner's written approval. We will not perform unrequested work and invoice for it. Where the Partner asks for something we think is out of scope, we say so before doing it, not afterwards.
4.5 Estimates are estimates. Timescales given at scoping stage assume the Partner meets the dependencies in section 8. We will tell the Partner as soon as we believe a date is at risk, rather than at the point it is missed.
5. Delivery and acceptance
5.1 We deliver in working increments rather than a single reveal, so the Partner always has something current to show their Client.
5.2 The Partner has 10 working days from delivery of a milestone to accept it or identify, in writing, where it does not meet the agreed scope. Acceptance is not unreasonably withheld, and a milestone put into commercial use is treated as accepted.
5.3 Handover on completion comprises the source, the schema, the deployment tooling, the configuration required to run it, and documentation adequate for a third party developer. The Partner makes this handover to their Client themselves. We are not present for it unless invited.
6. Warranty and support
6.1 We warrant that deliverables will materially conform to the agreed scope for 90 days after acceptance, and we will correct defects reported in that period at no charge.
6.2 The warranty does not cover changes made by anyone other than us, use outside the intended purpose, faults in third party services, or a request for behaviour that was never in scope.
6.3 Support beyond the warranty period is available under a separate retained arrangement. We will not withdraw support at short notice on work we delivered: where a retainer ends, we give 30 days notice and a documented handover.
7. Payment
7.1 Payment terms are set in each statement of work. In the absence of one, invoices are payable within 30 days.
7.2 The Partner's obligation to pay us is not conditional on their Client paying them. We understand the Partner may carry that gap and are willing to discuss staged payments up front, but not to take the Client's credit risk silently.
7.3 We may suspend work on undisputed invoices more than 30 days overdue, having given 7 days written notice. Suspension does not affect section 3.1: the Partner can still obtain everything written to that point.
8. What we need from the Partner
8.1 A single named point of contact with authority to make decisions.
8.2 Timely access to the systems, credentials, environments, data and third party accounts the work requires. We will ask for the least access that does the job.
8.3 Decisions and feedback within a reasonable period, since a fixed timescale cannot survive an open question.
8.4 Accurate information about the Client's requirements. We price what we are told, and we cannot absorb a scope the Partner did not describe.
8.5 Lawful basis for any personal data the Partner asks us to process. Where we process personal data on the Partner's behalf we do so as processor on their instructions, and a data processing agreement will be put in place.
9. What we do not promise
Stated plainly, because a promise that is quietly conditional is worse than one that is not made.
9.1 We do not guarantee that a Client will accept work, or that the Partner will win a pitch we scoped.
9.2 We do not guarantee uninterrupted or error free software, which nobody can.
9.3 We do not provide legal, regulatory, accounting or compliance advice. Where we build to a standard the Partner or their Client names, we build to what they specify. Confirming that the specification is sufficient is theirs.
9.4 We do not take responsibility for third party services we integrate with, their availability, their pricing, or their decisions to change or withdraw an interface.
10. Term, termination and what happens to the code
10.1 Either party may terminate an engagement on 30 days written notice, or immediately if the other commits a material breach that is not remedied within 14 days of being notified.
10.2 On termination, the Partner pays for work completed and accepted to that date, and for work in progress on a proportionate basis.
10.3 On termination for any reason, we hand over everything written to that point in a usable state, including source, schema, tooling and whatever documentation exists, and we transfer the repository if we hold it. This applies whether the Partner terminated, we terminated, or the engagement ended in disagreement.
10.4 Sections 2.2 (non-solicitation), 2.4 (confidentiality), 3 (ownership of what was paid for), 11 (liability) and 12 (governing law) survive termination.
11. Liability
11.1 Neither party excludes liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot lawfully be excluded.
11.2 Neither party is liable for loss of profit, revenue, business, goodwill, anticipated savings, or for indirect or consequential loss.
11.3 Subject to 11.1, each party's total liability arising from an engagement is limited to the total fees paid or payable under that engagement.
11.4 This clause is the one most likely to be negotiated, particularly where a Partner's own contract with their Client carries higher exposure than the fees they are paying us. That is a real and reasonable conversation to have per engagement, and where the Partner needs us to carry more, it is priced.
12. General
12.1 Subcontracting. We may use subcontractors, remain fully responsible for their work, and bind them to section 2 in full.
12.2 Assignment. Neither party may assign these terms without the other's written consent, except that the Partner may assign the benefit of delivered work to their Client.
12.3 Entire agreement. These terms and the applicable statement of work are the whole of what is agreed, and replace anything said beforehand.
12.4 Variation must be in writing and agreed by both parties.
12.5 Governing law. These terms are governed by the law of England and Wales, and the courts of England and Wales have exclusive jurisdiction.
12.6 No third party rights. Nobody other than the Partner and DraxCoders has any right to enforce these terms, and specifically the Client does not.