# Engagement Agreement Axdale. Software engineering by Michael Lip, Warsaw, Poland (CET). Website [https://www.axdale.com](https://www.axdale.com). Code portfolio on GitHub at [https://github.com/theluckystrike](https://github.com/theluckystrike). Version 1.0. 23 October 2026. This agreement uses plain English. It isn't legal advice, so each party should ask its own lawyer to check it before signing. ## How this agreement works in short This box is a summary. The numbered clauses below are the agreement. - The first week (40 hours) is free of charge. It starts after both parties sign this agreement and the first Statement of Work. - All work is async and in writing, with no calls, no meetings and no video. It follows a written brief and a signed Statement of Work with fixed acceptance criteria. - After week 1 the client can continue on paid weeks, or stop. A client that stops can keep the week 1 work under clause 8. - Paid weeks are invoiced one week at a time, in advance. Either party can end the agreement at any time with written notice. - Michael gets the least access he needs. He makes no production change without written approval. AI model providers see client code only with the client's written consent. ## Parties | Field | Details | |---|---| | Contractor | Michael Lip, trading as Axdale, independent engineer, Warsaw, Poland ("Michael") | | Contractor address | ____ | | Contractor tax ID | ____ | | Contractor email | michael@axdale.com | | Client legal name | ____ ("the Client") | | Client registered address | ____ | | Client company number or tax ID | ____ | The Client's Decision Maker, notice addresses, fees and other details are in the Schedule at the end of this agreement. ## 1. Definitions 1.1 "Agreement" means these clauses, the Schedule and every signed Statement of Work. 1.2 "Brief" means the Client's written description of the job. The Brief comes before any work starts. 1.3 "Statement of Work" or "SOW" means a signed document for one week of work. It sets the goal, scope, acceptance criteria, access and dates for that week. 1.4 "Week" means a block of up to 40 hours of Michael's work over 5 consecutive Working Days. 1.5 "Free Week" means the first Week under this Agreement. "Paid Week" means any later Week. 1.6 "Working Day" means Monday to Friday, except public holidays in Poland. Times are Warsaw local time (CET, or CEST in summer). 1.7 "In writing" means an email between the addresses in the Schedule, or a comment in the Client's repository or issue tracker by Michael or the Decision Maker. Chat messages count as in writing only for day to day questions, not for approvals, notices or changes to this Agreement. 1.8 "Decision Maker" means the person named in the Schedule. That person can approve SOWs, Paid Weeks, production actions and sign-off for the Client. 1.9 "Deliverables" means the code, tests, evaluation sets, prompts, configuration and documents that Michael creates for the Client under an SOW. 1.10 "Week 1 Work" means the Deliverables of the Free Week. 1.11 "Approved AI Providers" means the AI model providers that the Client allows in writing in the Schedule or in an SOW. 1.12 If an SOW conflicts with these clauses, these clauses apply. The only exception is an SOW that names the clause it changes and is signed by both parties. ## 2. Scope of work 2.1 Michael works only to a written Brief and a signed SOW. He does no work on a Week until both exist. 2.2 Each SOW sets one goal, 3 to 5 acceptance criteria, what is out of scope, the access Michael needs and the dates of the Week. 2.3 The acceptance criteria are fixed when the SOW is signed. A new request during a Week goes into the plan for a later Week. A change inside the current Week needs written agreement from the Decision Maker and Michael, and it must fit the hours left. 2.4 Michael decides how and when he does the work on the Working Days of each Week. 2.5 Michael commits to the acceptance criteria. He doesn't promise a business result, such as revenue, traffic or a funding outcome. ## 3. Async way of working 3.1 All work and all communication happen in writing. The channels are email, pull request comments and the Client's issue tracker. 3.2 There are no calls, meetings, video sessions or screen shares. Neither party may make one a condition of this Agreement. 3.3 Michael sends a written update by 18:00 CET on each Working Day of a Week. The update says what shipped, what is next, what is blocked and the hours used. 3.4 Michael replies to Client messages within 4 working hours, between 09:00 and 17:00 CET on Working Days. The document "How I work, async" gives the full response times. 3.5 The Client answers Michael's questions within 1 Working Day where it can. 3.6 In a Paid Week, if Client silence blocks the work, Michael says so in writing and works on items in the plan that aren't blocked. Time lost to a block counts as used. 3.7 The daily updates, the pull requests and the weekly report are the record of the work. ## 4. The free first week 4.1 The Free Week is free of charge. It covers up to 40 hours of Michael's work over 5 Working Days. The Client pays no fee and no expenses for it. 4.2 The Free Week starts on the start date in the first SOW, after both parties sign this Agreement and that SOW. The start date must be within 10 Working Days after the last signature. If the Free Week doesn't start in that time, the offer of a Free Week lapses, unless both parties agree a new date in writing. 4.3 The Free Week starts only when all of these conditions are met. (a) One per company. The Client hasn't had a Free Week before. "Company" includes the Client's email domains, its GitHub or GitLab organizations, its parent company, its subsidiaries and companies under common control. A company that has bought work from Michael before doesn't qualify. (b) Written Brief first. Michael has the Client's written Brief before the SOW is signed. (c) Named Decision Maker. The Schedule names one Decision Maker. That person can approve Paid Weeks and sign off in writing. (d) Qualified scope. The Brief describes a job that needs at least 2 Paid Weeks after the Free Week. The Free Week is the first slice of that job. If the whole job fits in one Week, Michael offers it as a Paid Week instead. (e) Fixed criteria. The Decision Maker approves the acceptance criteria in writing before day 1. (f) Safe access. The Client gives access to a branch or a fork and to a test environment or test keys. 4.4 In the Free Week, work stops at 40 hours or at the end of day 5, whichever comes first. The work happens only on a branch or a fork, with no production deploy, no production data and no production secrets. 4.5 If the Client is silent for 2 Working Days during the Free Week, the Free Week pauses. If the Client is silent for 5 Working Days, the Free Week ends. It then counts as the Client's one Free Week. 4.6 Michael runs a limited number of Free Weeks at the same time. He may put a start date on a dated waiting list. He may decline a Free Week before it starts, and he says why in writing. 4.7 The Free Week can't be split, moved to another company, exchanged for money or credited against Paid Weeks. 4.8 At the end of the Free Week, Michael delivers a pull request with tests, a handover note and a written plan for the paid follow-on. The plan states the number of Paid Weeks and the hours he estimates. 4.9 The Client has no duty to buy Paid Weeks. Michael has no duty to work Paid Weeks that aren't in a signed SOW. ### Why these rules exist This note explains clause 4. It isn't a separate clause. | Rule | What it prevents | |---|---| | One Free Week per company, including related companies and domains | A company taking free weeks again under a new email or a sister company | | Written Brief before the start | Free time spent on finding out what the job is | | Named Decision Maker | Free work that nobody with budget authority will review | | Qualified scope of at least 2 Paid Weeks after week 1 | A small job done in full for free, with no real paid follow-on to decide on | | Criteria fixed before day 1 | A free week that keeps growing during the week | | 40 hours and 5 Working Days, hard stop | Free work that runs past the box | | Branch or fork only, no production | Free work being used in production before anyone has reviewed it | | Silence pause and end | A free week held open with no review | | Start within 10 Working Days of signing | A reserved slot that never starts | | Ownership rule in clause 8 | Code kept with no payment and no feedback | ## 5. Paid weeks 5.1 After the Free Week, the Client can continue on Paid Weeks. Each Paid Week needs an SOW accepted in writing by the Decision Maker. 5.2 Paid Weeks are billed at the hourly rate in the Order Form and the Schedule. The rate is between USD 175 and USD 275 per hour, set by the scope, and it is agreed in writing before any paid hour. A Paid Week covers up to 40 hours. 5.3 Michael doesn't work more than 40 hours in a Week without written approval. Approved extra hours are billed at the hourly rate in the Schedule. 5.4 Michael holds the start date for the first Paid Week for 5 Working Days after the Free Week handover. After that, the start date depends on his schedule. 5.5 Paid Weeks can run back to back. Gaps between them are allowed. 5.6 Michael may change the hourly rate for future Weeks with 20 Working Days' written notice. A change never applies to a Week that is already invoiced. ## 6. Payment terms 6.1 Michael invoices each Paid Week in advance, when the SOW for that Week is accepted. The invoice covers the hours estimated in the SOW at the hourly rate. 6.2 Each invoice is due within 5 Working Days after the invoice date. Michael starts a Paid Week when the payment arrives, or earlier if he agrees in writing. 6.3 Fees are in the currency in the Schedule. Payment is by bank transfer to the account on the invoice, or by another method on the invoice. Each party pays its own bank charges. 6.4 Fees don't include VAT or other taxes. Where VAT applies, the invoice shows it, or it states that the reverse charge applies. If the law requires the Client to withhold tax from a payment, the parties agree in writing how to handle it before the first Paid Week. 6.5 If an invoice isn't paid when due, Michael sends a written reminder. If it is still not paid after 3 more Working Days, Michael may pause the work until payment arrives. Late payments carry interest at the statutory rate under the governing law. 6.6 If a Paid Week ends early under clause 12, the Client pays for the hours used at the hourly rate. Michael refunds the rest within 10 Working Days. 6.7 The hourly rate includes Michael's own tools, devices and AI subscriptions. The Client pays for its own cloud, API usage and third-party licenses on its own accounts. Any other expense needs written approval before Michael incurs it. 6.8 If the Client disputes part of an invoice, it says so in writing within 5 Working Days and pays the part that isn't disputed. ## 7. Acceptance and fixes 7.1 Michael delivers each Week's work as pull requests, measured against the acceptance criteria in the SOW. 7.2 The Client reviews the work within 5 Working Days after the handover. It tells Michael in writing which criteria fail and why. If the Client sends no list of failed criteria in that time, the Week's work counts as accepted. 7.3 For Paid Weeks, Michael fixes at no charge any failure against an acceptance criterion that the Client reports within 10 Working Days after the handover. This doesn't cover new requirements or changes in the Client's systems after the handover. 7.4 The Week 1 Work is delivered as is, for review and testing. If the Client continues, Michael fixes Week 1 failures in the first Paid Week. 7.5 The Client decides what to merge and what to deploy. Production deploys are the Client's job, unless an SOW says otherwise and the Decision Maker approves each deploy in writing. ## 8. Ownership of the work 8.1 During the Free Week, and for 10 Working Days after its handover, the Week 1 Work stays on a branch or fork. Michael keeps the rights to it during that time. The Client may run and test it for internal evaluation. It may not use it in production during that time. 8.2 All rights in the Week 1 Work pass to the Client on the day of the first of these 2 events. (a) The Client pays the invoice for the first Paid Week. (b) The Decision Maker sends a written close-out within 10 Working Days after the Free Week handover. The close-out says the Client won't continue now, and it gives 2 to 4 sentences of honest feedback on the work. 8.3 If neither event happens within 10 Working Days after the Free Week handover, Michael closes the pull request and deletes the branch and his copies. The Client deletes its copies of the Week 1 Work within 5 Working Days and confirms this in writing. The Brief, the plan, the daily updates and the handover note stay with the Client in every case. 8.4 Michael may quote the Client's feedback in public only with separate written permission. The Client can refuse that permission and still keep the Week 1 Work under clause 8.2(b). 8.5 All rights in the Deliverables of a Paid Week pass to the Client when the invoice for that Week is paid in full. 8.6 The rights that pass are all economic rights in the Deliverables, in all fields of use known at the time of transfer. These include recording, copying, changing, translating, combining with other works, distributing, publishing, selling, licensing, and storing in computer memory and on networks. To the extent the law allows, Michael won't use his moral rights to object to normal use or change of the Deliverables. 8.7 Michael keeps his background materials. These are the tools, libraries, templates, prompts and know-how he had before this Agreement or creates outside it. Where background materials are part of the Deliverables, the Client gets a non-exclusive, worldwide, perpetual, royalty-free license to use, copy and change them as part of the Deliverables. The license can pass with the Client's business. 8.8 Open source components keep their own licenses. Michael lists each new third-party dependency in the pull request. He adds no strong copyleft dependency (for example GPL or AGPL) without written approval. 8.9 Michael reviews every change that an AI tool helps to write. The ownership rules in this clause apply to AI-assisted work to the extent the law gives rights in it. Michael doesn't knowingly add code that infringes the rights of others. 8.10 The Client keeps all rights in its own code, data, brand and materials. It gives Michael a license to use them only to do the work. ## 9. Confidentiality 9.1 Each party keeps the other party's confidential information secret. It uses that information only for this Agreement. 9.2 Confidential information includes code, data, the Brief, plans, roadmaps, security details, credentials, prices and the terms of this Agreement. 9.3 Information isn't confidential if it is public through no fault of the receiving party, was already known to it, was received lawfully from someone else without a duty of secrecy, or was developed on its own without the other party's information. 9.4 A party may share confidential information only with people who need it for this Agreement and who are bound by duties of secrecy at least as strict as this clause. Michael uses no subcontractors without the Client's written consent. 9.5 If the law or a court requires a party to disclose confidential information, that party tells the other party first where the law allows, and discloses only what is required. 9.6 Only Approved AI Providers may process the Client's code or data. If the Schedule names none, no AI model provider sees the Client's code or data. Clause 10 and the Security and Access Policy give the details. 9.7 Michael doesn't name the Client, show its logo or show its code in public without written permission. He may describe the work in a form that doesn't identify the Client only with written permission. 9.8 These duties last for the term of this Agreement and for 3 years after it ends. For trade secrets and personal data, they last as long as the information stays protected by law. 9.9 If the parties also sign the Axdale Mutual NDA, both documents apply. If they conflict, the term that gives more protection to the information applies. 9.10 Michael avoids access to personal data. If the work needs it, the parties sign a data processing agreement before Michael gets that access. ## 10. Access and security 10.1 The Client gives Michael the least access he needs for each SOW. The SOW lists that access. Access uses named personal accounts with multi-factor authentication where the system supports it. 10.2 Michael makes no write to production without written approval from the Decision Maker for that specific action. A production write includes a deploy, a database migration, a data change and a configuration change. In the Free Week, there are no production writes at all. 10.3 The Client shares test keys and other secrets only through its secret manager or a one-time encrypted link. Secrets never go in email, chat, issues, code or AI prompts. 10.4 Michael follows the Axdale Security and Access Policy, version 1.0 or a later version that the Client accepts in writing. 10.5 Each party tells the other in writing within 24 hours after it becomes aware of a security incident that affects the work or the other party's information. 10.6 The Client can remove any of Michael's access at any time. 10.7 When this Agreement ends, Michael removes or hands back his access. Within 5 Working Days he deletes the Client's code and data from his devices and accounts, and he confirms the deletion in writing. ## 11. What the Client does 11.1 The Client gives a written Brief, a Decision Maker, the access in each SOW and answers to questions. 11.2 The Client reviews pull requests and reports under clause 7. 11.3 The Client keeps backups of its own systems and data. 11.4 The Client is responsible for its product, its production decisions and its own legal compliance. ## 12. Term and termination 12.1 This Agreement starts on the date of the last signature. It continues until one party ends it. 12.2 Either party may end this Agreement at any time by written notice. The notice takes effect at the end of the Working Day (CET) on which it arrives, or on a later date that the notice states. 12.3 When the Agreement ends, Michael stops work and pushes all work in progress to the branch. Within 2 Working Days he sends a handover note that says what is done and what isn't. 12.4 Payment for a Paid Week that ends early follows clause 6.6. Ownership follows clause 8. If the Agreement ends during the Free Week, clauses 8.2 and 8.3 apply from the date of the handover note. 12.5 Access removal and deletion follow clause 10.7. 12.6 Clauses 6, 8, 9, 10.7, 13, 14 and 15 continue after the Agreement ends. ## 13. Warranties 13.1 Michael does the work with reasonable skill and care. He has the right to grant the rights in clause 8. He doesn't knowingly add malicious code. 13.2 The Client has the right to give Michael the materials and access it gives him. 13.3 Apart from this clause, the work is provided without other warranties, to the extent the law allows. ## 14. Liability 14.1 Neither party is liable for indirect or consequential loss, lost profit, lost revenue or lost goodwill. 14.2 Each party's total liability under this Agreement is limited to the fees paid by the Client in the 3 months before the event that caused the claim. If no fees were paid in that period, the limit is USD 1,000. 14.3 For a breach of clause 9 or clause 10, the limit is 3 times the amount in clause 14.2. 14.4 The limits in this clause don't apply to unpaid fees, to fraud, to wilful misconduct, or to any liability that the law doesn't allow to be limited. 14.5 Each party takes reasonable steps to reduce any loss. 14.6 A party must make a claim in writing within 12 months after it becomes aware of the event that caused it. ## 15. General 15.1 Michael is an independent contractor. He isn't an employee of the Client. Each party pays its own taxes and social security. 15.2 This Agreement isn't exclusive. Michael may work for others, but he never uses the Client's confidential information for them. 15.3 Neither party may transfer this Agreement without the other party's written consent. A party may transfer it with written notice to a buyer of all or most of its business. 15.4 Neither party is liable for a delay caused by events outside its reasonable control. The affected party tells the other party in writing without delay. 15.5 Notices under this Agreement go by email to the addresses in the Schedule. A notice arrives when it is received during working hours (CET), or at 09:00 CET on the next Working Day if it is received outside them. 15.6 This Agreement is the whole agreement between the parties about the work. It replaces earlier proposals and messages. A change to these clauses is valid only if it is in a document signed by both parties. 15.7 If a court finds part of this Agreement invalid, the rest stays in force. A delay in using a right isn't a waiver of it. 15.8 The parties may sign this Agreement electronically and in separate copies. If the governing law requires a special form for a transfer of copyright, the parties sign in that form. 15.9 This Agreement is governed by the law of ____. The courts of ____ have jurisdiction. Before either party goes to court, the parties try for 20 Working Days to settle the dispute in writing. 15.10 This Agreement is in English. If it is translated, the English version applies. ## Schedule | Field | Details | |---|---| | Decision Maker name | ____ | | Decision Maker title | ____ | | Decision Maker email for notices | ____ | | Client technical contact (optional) | ____ | | Michael's email for notices | michael@axdale.com | | Free Week start date | ____ | | Free Week end date | ____ | | Hourly rate for Paid Weeks | USD ____ per hour (between 175 and 275, set by scope) | | Hourly rate for approved extra hours | The same hourly rate | | Invoice currency | USD / EUR / PLN (circle one) | | Repositories in scope | ____ | | Test environment or test keys | ____ | | Governing law | ____ | | Courts | ____ | ### Approved AI Providers Tick each provider the Client allows to process its code and data. If no box is ticked, no AI model provider sees the Client's code or data. - [ ] Anthropic (Claude and Claude Code) - [ ] OpenAI (Codex and the OpenAI API) - [ ] Other provider, named here ____ - [ ] None. Michael works without AI model access to the Client's code. ## Signatures Signed for the Client Name ____ Title ____ Signature ____ Date ____ Signed by the Contractor Name Michael Lip, trading as Axdale Signature ____ Date ____ --- Axdale. Michael Lip, independent engineer, Warsaw, Poland (CET). michael@axdale.com. This document is plain English and isn't legal advice.