Writing case studies when you do not have revenue metrics

You can write a useful case study without revenue metrics. Explain the problem, the work actually delivered, the decisions made, and the evidence a buyer can inspect. When business impact was not measured or is not available for publication, say so. Missing data is a limit, not a blank to fill with a plausible percentage.

The reader still has a practical question: does this project help me judge whether the team can handle work like mine? Delivery evidence can answer part of that question.

Start with claims you can support

Gather an approved scope, publishable screenshots, and any decision records that explain the work. Check permission before using a client’s name, quotation, or internal interface. A public website does not make every internal discussion publishable.

Match each proposed sentence to its evidence:

Proposed claim	Evidence needed
Built a bilingual publishing workflow	Demonstrable language states and approved scope
Replaced a manual content task	Documented previous and delivered workflows
Made the site faster	Comparable measurements with conditions recorded
Increased revenue	Authorized commercial data and a defensible attribution method

If the evidence only establishes implementation, write an implementation claim. Do not promote it into an outcome.

Explain what scope facts do and do not show

For IrmaWP, the confirmed 2026 work scope includes branding, UX/UI, a WordPress website, and a Laravel web application with AI. Those facts describe the breadth of the engagement and its technology. They do not establish revenue growth, hours saved, or adoption.

A case study can use those exact facts as its foundation, then add only material cleared for publication. Naming a stack is not an explanation of architecture. Without a verified decision record, do not invent why WordPress or Laravel was chosen.

Google’s helpful-content guidance asks whether content provides original information and clear sourcing. An honest project account has something more useful to offer than a generic success narrative: specific work and explicit limits.

A hypothetical evidence review

Imagine a hypothetical bilingual catalog project with an approved scope, an editor walkthrough, and launch screenshots, but no sales reporting access. This is an illustration, not a 5e Labs result.

The draft says “The new catalog transformed sales.” Delete that sentence. The available evidence supports a narrower statement: the delivered CMS lets an editor update product specifications in both languages through the agreed workflow.

To make the account useful, explain which fields are shared and which require translation approval, provided those details are documented. Add a screenshot with a caption describing the state shown. A screenshot of a published product proves that state existed; it does not prove editors found the workflow easy.

If usability was not evaluated, leave that claim out too.

End with an evidence gap worth closing

Give the case study a clear boundary between delivered work and unresolved impact. If ongoing measurement is planned, name the intended measure without predicting its result. Keep the delivery date distinct from the date the article was written or updated.

For your next case study, collect one approved artifact and one documented project decision before writing the introduction. When commissioning web development with 5e Labs, include publishable evidence requirements in the project scope so the eventual account does not depend on memory or invented numbers.