Turning delivered work into proof

Ask a software company for three written case studies and you usually get a page of logos, one line under each, and an offer to walk through the rest on a call. Behind those logos there is often real work: a stock system that replaced a spreadsheet four branches were editing at the same time, an integration that held through a peak season without a manual reconciliation. Almost none of it was written down while the details were still fresh. The company has been generating evidence for years and has kept none of it, so every proposal argues from promises, and the buyer has no way to check them.

Proof is the cheapest asset a delivery company owns, because it is a by-product of work that has already been paid for. The cost of collecting it is about an hour at the right moment, and the right moment is narrower than most teams assume.

What a case study has to prove

A buyer reading about a past project is asking one question: has this company solved a problem shaped like mine, and did the result survive contact with real use. Everything else — the design language, the technology list, the adjectives — is decoration on that question. A case study that answers it has five parts, and one missing part is usually enough to make the whole thing read as a brochure.

1. The situation before. What the client was doing on the Sunday before the project started. Who did the work, in what tool, and where it broke. "The finance team closed the month in a shared spreadsheet, and every close occupied two people for three days" is a situation. "The client needed to modernise their processes" is not.
2. The constraint that made it hard. Any competent team can build the easy version. The constraint is the part a reader recognises: an ERP that could not be replaced, a customs workflow that had to stay paper-compatible, a two-week window before the season opened, a team of four who would have to operate the result themselves. State it plainly. It is what makes the rest of the story credible.
3. What was actually built. Modules, integrations, the interfaces people sit in front of, where it runs. Concrete nouns rather than capabilities. Someone working in the same sector should be able to picture the screens.
4. What changed, measured the way the client measures. Hours per close, orders per shift, steps in a return, the reconciliation that no longer happens. If nobody measured the before, say so and give the client's own account of the change instead of inventing a percentage. A modest number that is true is worth more than a large one that cannot be defended, and buyers in this market have learned to discount large ones.
5. The state the system was left in. Who operates it now, what happens when it breaks, whether it is still running. Almost everyone omits this part, and it is the part that separates a delivered system from a demonstration.

A case study with no "before" is a feature list, and a case study with no "after we left" is a launch announcement.

Five hundred words in this shape do more work than three thousand words of narrative. Keep the parts in that order and let the reader stop as soon as they have what they came for.

Screenshots and a live URL beat prose

Description is the weakest form of evidence, because it is the only form the reader has to take on trust. A link to the system, running on its own domain, is the strongest, since it can be opened in the same minute the sentence is read. Where the system is internal and cannot be exposed, screenshots of the real interface, with client data replaced or obscured, do most of the same work. A thirty-second recording of an actual workflow — an order arriving, a return processed, an invoice issued — closes most of the remaining gap.

One form of proof costs nothing at all: a system that has been publicly reachable and running for years. Nobody can fake five years of uptime. A short list of systems with the year each went live and a note that it is still in service is more persuasive than the copy written around it, and it is the only asset that improves on its own while you work on something else. It is also a practical argument for continuing to operate what you build instead of handing it over and losing sight of it, which is the case made in what happens after delivery.

Collect the artefacts as you go. At the end of each project, capture the screens, record the two-minute walkthrough, note the launch date, and file them with the project. Reconstructing all of this two years later means asking a client for access to a system you no longer administer, which is an awkward request and often a refused one.

Anonymise the client, never the problem

Many clients will not allow their name to be used. This is normal, and it is a smaller obstacle than it appears, because the name is rarely the part doing the persuading. The reader is looking for their own situation in the story, not for a logo they recognise. Remove the name and keep everything else.

"A distributor in Cairo with eleven branches and roughly four thousand active items" tells a reader more than a logo would. What must never be blurred is the problem, the constraint, the architecture, the measurements, and the sector. A study that says "a client in the retail space faced various challenges and achieved significant improvements" has anonymised the wrong things, and it reads as though the project may not have happened at all.

Two habits keep this clean. Agree the anonymised description with the client in writing, so there is no argument later about whether "a distributor in Cairo with eleven branches" identifies them. And where even that is refused, ask whether the work may be referenced verbally in sales conversations under a non-disclosure agreement. A surprising number of clients who will not appear on a website will agree to take a reference call.

Permission is a handover task

The most expensive mistake in this subject is asking for permission a year after delivery. By then the person who commissioned the project has moved on or forgotten the details, the system is taken for granted, and the request arrives with no context attached. The honest answer becomes "let me check with legal", which is a no with better manners.

Ask at handover. The system has just gone live, the person who signed for it is being congratulated internally, and the relationship is at the warmest point it will reach. Better still, put it in the contract: a clause granting the right to publish a case study and name the client, subject to the client approving the final text. Clients sign that clause without much thought at the start of a project and resist it at the end.

Reference letters follow the same timing, with one added rule. Do not write the letter for the client. A letter you drafted reads like a letter you drafted, and an experienced buyer notices within two sentences. Send a short factual summary instead — what was built, when, what it replaced — so the client is not reconstructing the project from memory, then ask three specific questions.

• What was the problem before the project started?
• What did the system change in your daily work?
• What would you say to someone considering the same thing?

Offer to arrange the answers into a letter for their approval, and change nothing except the order. The sentences come back in the client's own language, which is the only reason the letter carries any weight, and the better half of them can be quoted directly in a proposal.

A portfolio is breadth; a case study is depth

These are two different objects with two different jobs, and collapsing them into one page weakens both.

A buyer scans the portfolio to decide whether you are plausible, then reads a single case study to decide whether you are right. The portfolio should be scannable and honest about scale, with a two-week integration listed as a two-week integration next to a platform that took a year. The case studies should be few, deep, and concentrated in the sectors you want more of. Case studies that do not match your intended positioning will keep delivering the work you are trying to leave behind. Take the most recent system you put into production, write its five parts while the details are still recoverable, and ask for permission this week rather than next year. If you would rather the system itself did the arguing, talk to us about scoping one.