Business
Nobody Cares What You Built. They Care What Broke.
By Muhammad UmarJuly 9, 20266 min readIssue #19
Every case study on every site describes a project that went well. A signal everyone can send is not a signal.
Read any portfolio page and the story is the same. There was a problem. A solution was designed. It was delivered on time and the client was delighted.
Nobody believes it. Not because anyone thinks you are lying, but because everyone reading has worked on a project, and none of them has ever seen one go like that.
The page is not doing nothing. It is doing something worse than nothing: taking the space where evidence would go and filling it with a description that could have been written before the work started.
The problem: a signal everyone can send is not a signal
Line up ten portfolios in your market. Every one says the work went well. Every one has a happy client and a delivered outcome.
Which means a buyer comparing them learns nothing from the claim, because the claim is present in all of them, including the ones from people who are not good at this.
Anything that costs nothing to say gets said by everyone, and once everyone says it the words stop carrying information. The only claims that separate you are the ones a weaker competitor could not make.
"We delivered successfully" is free. Anyone can write it, including someone who did not. "The first architecture was wrong and we found out in week three" is not free, because it requires having been there and being willing to say so.
What the buyer is actually asking
This is where the mismatch comes from. The page answers a question nobody is asking.
You think you are being assessed on capability. Mostly you are not. By the time someone is reading your work they have already assumed you can probably do it, because most people in your market can probably do it.
What they are actually working out is what happens when it goes wrong. Not whether it will, because they know it will. They are trying to find out how you behave in the part of the project you are not showing them.
| What you wrote | What an experienced buyer reads |
|---|---|
| Delivered on time and on budget | Either the scope was trivial or this is being rounded |
| The client was delighted | You have not spoken to the client since |
| We used a modern, scalable stack | You want to talk about tools instead of outcomes |
| A seamless end-to-end solution | Someone wrote this who was not on the project |
| Week three showed the approach was wrong, so we changed it | This person will tell me when something is wrong |
Look at the last row. It is the only one where the reader learns something they can act on, and it is the only one that describes a failure.
The fix: show the part that went badly
Not as a confession, and not as a lesson-learned paragraph bolted onto the end. As the substance of the account, because it is the part that carries information.
A version that works has four pieces.
What you assumed at the start. Say what you believed going in, including the belief that turned out to be wrong. This is what makes the rest credible: anyone can narrate a plan that worked, and only someone who was there remembers what they thought before they knew.
What that assumption cost. A rewritten component, three weeks, a feature that got cut. Be specific. Vagueness here reads as an attempt to have it both ways.
How you found out. Whether it surfaced in a review, in production, or because a user complained tells the reader far more about how you work than the fix does. Finding your own mistakes and finding them from a customer are different competences.
What you changed, in the work and in yourself. Not a slogan. The specific thing you now do differently, which is also a preview of how you will run the reader's project.
Why this feels dangerous and is not
The objection is obvious: describing a mistake makes you look worse than describing a triumph.
It does not, and the reason is that the alternative is not being seen as flawless. The alternative is being seen as one of ten identical pages. You are not choosing between looking perfect and looking human. You are choosing between looking human and not being distinguished at all.
There is a second effect that matters more. A project with no reported problems reads one of two ways to someone experienced: it was too small to have any, or the problems are being hidden. Neither is what you wanted, and both are worse than the truth.
The unbroken record does not read as competence. It reads as a project too small to teach anyone anything, or as an account that has been tidied.
And the person most likely to notice is the person you most want as a client. Someone who has run projects knows the shape of one. Give them a smooth story and they do not conclude you are exceptional. They conclude you are marketing at them, and they discount the whole page.
The same thing applies to the call
This is not really about case study pages. It shows up anywhere you describe your work, and the highest-value version is live.
When someone asks what could go wrong with their project, the reflexive answer is reassurance. That answer is available to everyone they are talking to.
The answer that separates you is a real one. The integration you are unsure about. The dependency on someone in their team who is difficult to get hold of. The part of the scope that usually turns out to be twice the size. Saying it costs you nothing you had, and it demonstrates the exact behaviour they were trying to detect.
It also does something useful for you. A client who hears the risk before signing and proceeds anyway has agreed to it. The same conversation held in week six is a complaint.
When this is the wrong advice
When you cannot describe it without identifying the client. Confidentiality is a hard constraint and not a preference. The workaround is to keep the shape of the failure and drop everything specific to them, which loses some force and is still better than a page of platitudes.
When the failure has no recovery in it. "We shipped it late and the client left" is honest and it is not a case study. The version that works has you noticing, correcting, and finishing. Without the second half you are publishing an apology, which asks the reader to absorb a risk with nothing in return.
When the reader is a form rather than a person. Procurement processes and tender responses are scored against criteria, and nuance is at best invisible there. Give those what they ask for. This advice is for the situations where a human being is deciding whether to trust you.
The takeaway
You are not competing on whether you can build the thing. Nearly everyone in the running can build the thing.
You are competing on what the buyer thinks will happen in month three, when something is wrong and they need to hear about it from you rather than find it themselves. Nothing on a page full of successes speaks to that, and one honest paragraph about a project that went sideways speaks to nothing else.