How to present completed projects on your website and make them useful for sales

A photo gallery proves you've done work. It doesn't prove you can solve the problem of the person looking at it, which is why almost no one scrolls through it to the end. Someone evaluating a vendor isn't looking for examples of good work in general: they're looking for a case similar enough to their own that they can picture themselves in your customer's place. The difference between the two isn't in the photos, it's in the context around them.

The move from gallery to case collection doesn't require new photos or a new website. It requires showing fewer projects and saying, for each one, where things started, what constrained the choices, what you did, and how it turned out. It's editorial work, not design work.

Choosing the projects: similarity before beauty

The most common selection criterion is aesthetic success: publish the projects that came out best. That's a criterion that speaks to you, not to the reader. The useful one is similarity to the customer you want to attract.

• Same problem, not necessarily the same industry. Someone who needs to replace a system while production keeps running recognizes that constraint even in a job done for a different sector.
• Comparable size. A project for a large company reassures someone with twelve employees very little: it makes them think you're not for them.
• A recognizable constraint: a historic building, a system that could only go down for a few hours, a budget fixed from the start, an existing system that had to stay running.
• The work you want to sell more of. The case collection steers the requests you'll receive: if you only show exceptional projects, you'll get questions about exceptional projects.

Six well-chosen cases are better than forty photos. A long list forces the reader to search for what applies to them, and usually they don't: they look at the first few rows and leave.

What to say about each project

The minimum account has four parts, and fits in ten to fifteen lines. You don't need a technical report: you need an outside reader to understand the situation without knowing your trade.

1. The starting situation. What wasn't working, or what needed to be achieved. Write it from the customer's point of view, in the words they would use.
2. The constraints. Timelines, space, regulations, systems that couldn't be touched, work that couldn't be stopped. This is the part that makes the rest credible: without constraints, any job looks easy.
3. The choices, including the ones ruled out. Why that solution and not another. Saying what you excluded and why shows that an evaluation actually took place.
4. The work carried out. What you physically did, in what order, with which people or which phases. Here, concreteness matters more than brevity.

Measured results and observations: say so openly

The mistake that ruins even well-written cases is mixing things that carry different weight. A measured figure, a customer's remark, and your own impression aren't equal, and presenting them the same way lowers the value of all three. It's worth keeping them separate and stating what each one is.

Permissions: what you can actually publish

Before writing, it's worth knowing what can actually be published, because this is the part that leaves cases stuck halfway and sitting in draft for months.

• Customer name and brand: ask in writing, even an email is fine, and keep the reply.
• Photos of locations, systems, and people: you need permission from whoever owns the location and consent from anyone recognizable.
• Operational data: volumes, timelines, amounts belong to the customer. Some contracts cover them explicitly.
• Documents and screenshots: names, contact details, and third-party data need to be removed before they go online.

When permission doesn't come through, there's still the anonymous-case route, stated as such: a company in a certain industry, of a certain size, in a certain area. It loses force but stays useful, and above all stays true. The route that doesn't exist is inventing a customer or attributing numbers to a real case that aren't actually theirs.

One template for every case

If every case has a different structure, the reader has to relearn how to read it each time, and you have to start from scratch every time you write one. It's worth fixing the fields once.

• A title naming the problem, not the customer: that's what lets readers recognize themselves.
• Industry, size, and area, even in general terms.
• Starting situation, constraints, choices, work carried out.
• Outcome, with a distinction between measured figure, remark, and verifiable fact.
• Duration of the project and, if relevant, how it was organized over time.
• The service the case corresponds to, with a link to the relevant page.
• Optional fields: photos with captions, an authorized quote, a public document, a drawing or diagram.
• An internal field, not published: who authorized what, and on what date.

Fields you don't have shouldn't be filled with stock phrases. An empty field is useful information for whoever manages the collection: it says that case is incomplete and needs to be filled in or left out.

When it's better not to publish a case

Not every successful project makes a good case, and insisting on it produces pages that weaken the others.

• The work isn't representative of what you sell today, and it will attract requests you don't want.
• The relationship with that customer is strained, or there's an open dispute, even about something else.
• The customer is in direct competition with another important customer of yours.
• There's nothing to say beyond the photo: if removing the image leaves nothing, the case isn't ready.
• The only outcome available is your own opinion.

In all these cases, the right choice is to leave it out. A collection of six solid cases works better than one of twenty where the reader finds four weak ones and starts doubting the rest too.

Bringing the reader to the next step

A case that ends without saying where to continue leaves the reader convinced and stuck. The end of the write-up is the point where interest is highest, and the only moment worth asking for something.

• A link to the corresponding service, because someone who recognized themselves wants to know how you work in general.
• Two or three similar cases, chosen for similarity and not listed by date.
• What happens if they write in: who responds, what's needed for a first assessment, in what form the reply arrives.

The reverse is also true: service pages should link back to the cases that prove them. A case collection reachable only from the main menu is seen by very few people, almost all of them already interested.

What this guide doesn't cover

This guide covers how to present your own work for sales purposes: which projects to choose, what to write about them, what can be published. The value of outside sources and third-party citations — what makes content verifiable from the outside, and which references actually carry weight — is covered in the dedicated guide on proof that makes business content credible. The overall structure of a website meant to help evaluate a vendor also has a guide of its own.