1. How it usually happens
Atypical contracts arise when actual work moves faster than formalisation. This happens often in software, SaaS, and AI: it starts with a proposal, requests are added on a call, details are clarified in a chat, drafts are emailed, and then work begins. The contractual document exists, but it's only part of the story.
Over time, the relationship is enriched with "out of contract" elements: new features, adaptations, urgencies, concessions, changes in priorities. Someone says "we'll include it", someone else replies "ok, but we'll bill it separately", and that sentence hangs suspended between Slack and human memory.
A typical anecdote: a supplier agrees to do "a quick little tweak" during a call. A few weeks later, that tweak has become a central part of the project. The client considers it included; the supplier sees it as an extra. No one is entirely wrong, but no one has a document clearly narrating what happened.
A less obvious perspective: in atypical contracts, value lies not only in written clauses but in the concrete behaviour of the parties. Email threads, operational approvals, accepted deliveries, silence after a proposal. All these elements build a factual contractual reality. Documenting them makes this reality visible.
In AI and SaaS contexts, the situation is even more fluid: evolving services, updated models, modified datasets, changing access rights over time. The "service" is not a static object but a changing system. Without a good paper trail, after a few months, it becomes difficult to establish what was originally included and what was added along the way.
2. What you need to prove
The goal is to credibly reconstruct what was agreed, what was actually done, and how the relationship evolved over time.
It can be useful to prove:
- the existence of the initial contract and its versions;
- the content of offers, proposals, and quotes;
- the modifications agreed upon over time;
- the activities actually performed;
- the deliveries made and accepted;
- the additional requests and related responses;
- the promises made in emails, chats, or calls;
- the operational conditions (timings, methods, limits);
- any disagreements or disputes;
- the state of the service at key moments;
- the chronological sequence of events.
In practice, you must be able to tell the story of the relationship linearly: what was decided, what changed, and what was actually done.
3. What to collect
You need an archive that ties together formal documents and operational communications. In atypical contracts, it is often the latter that makes the difference.
Collect:
- initial contract and any subsequent versions;
- quotes, offers, and technical annexes;
- negotiation and clarification emails;
- exported chats (Slack, Teams, WhatsApp, etc.);
- minutes or notes from calls and meetings;
- shared documents (Google Docs, PDFs, presentations);
- screenshots of relevant messages;
- project tasks, tickets, or backlogs;
- activity or progress reports;
- proofs of delivery (files, access credentials, deployment, demos);
- invoices, payments, and accounting notes;
- any complaints or reports;
- call recordings, if available and usable;
- technical files tied to the service (code, datasets, configurations);
- changelogs or modification history.
A good rule of thumb: if a decision was made, look for a trail. If it doesn't exist, try to reconstruct it with what you have.
4. How to proceed
Start by putting existing material in order. Create a main folder dedicated to the relationship, with simple sub-sections: contract, communications, deliveries, payments, modifications.
Then build a timeline. Even a simple document with dates and events helps immensely. Write down what happened, attach references, and link the files. You don't need a novel: you need clarity.
Practical procedure:
- collect all available documents and communications;
- organise the material in logical folders;
- create a timeline of main events;
- identify key moments (agreements, modifications, deliveries);
- link files and evidence to each event;
- highlight what was planned versus what was added;
- prepare a clear summary document;
- create ZIP archives for significant blocks;
- certify key documents and packages;
- keep neat, unaltered copies.
If the relationship is ongoing, start formalising better right away. After every major decision, send a written summary. A few lines are enough: "I confirm we agreed on X, with timings Y and conditions Z". This simple gesture avoids many future arguments.
5. Mistakes to avoid
The main risk is relying on memory or scattered documents.
Common mistakes:
- viewing the initial contract as the sole source;
- not saving relevant emails and chats;
- not documenting modifications and extra requests;
- leaving major decisions entirely verbal;
- failing to distinguish between included and extra activities;
- using unversioned or undated files;
- not tracking deliveries and acceptances;
- losing the chronological sequence of events;
- modifying documents without keeping prior versions.
Besides technical certification, it is useful to adopt simple habits: written summaries, document versioning, orderly archiving, use of shared tools with histories. Free certification is useful because it allows you to quickly lock down documents and key moments without adding complexity to daily work.
6. After the documentation
Once the picture is reconstructed, share it internally with whoever manages the relationship: operational team, sales, management. Everyone must share the same view of the facts.
If critical issues or possible disputes arise, consider structured engagement with the counterparty, based on clear, verifiable documents. If necessary, involve technical or legal consultants experienced in service contracts and digital projects.
For the future, use this experience as a baseline for improvement: clearer contract templates, approval processes, change tracking, communication management. In atypical contracts, the line between chaos and control often lies in how details are saved and organised along the way.