1. How it usually happens
The scene is familiar: end of the project, everyone is tired, someone writes "I sent you everything" on Slack and attaches a link to a shared folder called final_v3_ok_definitive. A few weeks later, questions arise: was a feature missing? Was the API complete? Were the tests included? Was the documentation up to date?
In the SaaS world, delivery is even more nuanced. Sometimes there isn't a file to download: there is an accessible environment, a dashboard, an endpoint, an AI model in production. The client says "it doesn't work as agreed", the supplier replies "it is exactly what we released". Without a precise snapshot of the delivery moment, the discussion becomes a memory game.
A typical anecdote: a team delivers an AI system with well-structured internal prompts and logic. The client modifies some parameters "just to try". Two months later, the results are different, and no one remembers the original configuration. At that point, the question is no longer technical, it's historical: what actually existed on the day of delivery?
A less obvious perspective: what wasn't delivered matters too. Excluded features, stated limitations, parts still under development. Misunderstandings often stem right from there.
2. What you need to prove
The goal is to build credible evidence of the actual delivery content at a precise moment.
It can be useful to prove:
- which files or components were delivered;
- the exact version of the code or software;
- the state of the application or service at the time of release;
- the included and excluded features;
- the content of the attached technical documentation;
- the configurations, parameters, or prompts used (especially in AI systems);
- the access methods provided (accounts, credentials, URLs, environments);
- what was communicated to the client about "what the delivery includes";
- any explicit limitations or conditions.
Essentially, you need to be able to answer concretely: "what was inside the delivery, exactly on that day?"
3. What to collect
You need a complete package that brings together the technical and communicative parts.
Collect:
- source code or repository export (ZIP);
- released build or deployed package;
- technical documentation in PDF or Markdown;
- a README file describing the delivery;
- screenshots of the platform, dashboard, or interface;
- short videos showing main functionalities;
- list of APIs and related documentation;
- configurations, .env files, relevant parameters or prompts;
- test reports or delivery checklists;
- delivery emails sent to the client;
- exported chats (Slack, Teams, etc.) with confirmations or clarifications;
- contracts, offers, and functional specifications;
- any closed tickets or tasks related to the delivery;
- system logs or reports showing the system state upon release.
An often-overlooked detail: also save the folder structure and original file names. Changing names later makes it harder to reconstruct the context.
4. How to proceed
Before delivering, prepare the technical narrative of the delivery yourself. Don't leave it to be reconstructed later when versions have already mixed.
Create a folder dedicated to the delivery, with a clear name and a date. Put everything that represents the "delivered package" inside. Add a README explaining what it contains, how to use it, and what to expect.
Practical procedure:
- identify what is part of the delivery and what is left out;
- export code, builds, and documentation in the exact version released;
- add a descriptive and readable README;
- include visual proof like screenshots or videos;
- collect delivery communications (emails, chats);
- create a complete ZIP archive of the delivery;
- certify the package and main documents;
- send the delivery using trackable channels (email, ticketing systems);
- keep an internal copy identical to the one sent.
If the delivery is a SaaS service or an online AI system, document its state with screenshots, configuration exports, and usage videos. It’s like taking pictures of an apartment before handing over the keys: later on, someone might move the furniture.
5. Mistakes to avoid
Many difficulties arise from informal or fragmented deliveries.
Common mistakes:
- delivering via editable links without saving a static copy;
- sending scattered files across multiple messages without a single package;
- updating files after delivery without distinguishing versions;
- not documenting what is excluded from the delivery;
- relying only on verbal communications or calls;
- forgetting key configurations, dependencies, or parameters;
- using ambiguous names like last_good_version.zip;
- failing to keep delivery communications.
Besides technical certification, take care of the process: clearly define what "delivery completed" means, use internal checklists, and get written confirmation of receipt. Free certification is useful because it allows you to quickly lock down the delivery content without burdening the operational workflow.
6. After the documentation
After documenting the delivery, keep a clear line between the delivered version and subsequent developments. Every modification should generate a new version, with a new package and new documentation.
Share the material internally with the technical team and management, so everyone knows what was actually released. If disputes arise, immediately gather the already prepared documents and consider involving technical or legal consultants at a European level.
If you work with clients or partners, use this practice as a standard: clearer deliveries, fewer arguments, and a technical memory that doesn't rely on "who remembers best". Ultimately, in software projects, human memory is useful, but files saved at the right time are far more reliable.