Home / Work
Selected case studies

Work we've delivered.
In detail, with the numbers.

We publish case studies for work we do under the Okenwa Labs name, with concrete outcomes and no vague superlatives. Each one is reviewed and approved by the client before it goes up. Where confidentiality applies, we still describe the shape of the problem and the shape of the solution, just without the identifying details.

Publishing policy

Case studies are published as engagements complete.

Every case study on this page is an engagement run under the Okenwa Labs name, with the client's written approval and real numbers attached. We don't pad the page with decorated versions of work delivered under other names, and we don't publish anything until the engagement has concluded.

That gives this page a slower cadence than most consultancies offer, and a higher standard of evidence behind every entry. The methodology section below sets out how we source the data, draft the narrative, and get to a published version the client is content to put their name to.

If you want to see indicative work, or talk about a specific problem you're weighing up before any case study lands here, the fastest path is a direct conversation. We'll tell you within a working day whether what you're describing is something we can help with.

In the pipeline
  • 01 An operational platform for a utility-sector client In delivery
  • 02 An internal tooling rebuild for a growing services business Scoping
  • 03 A technical due diligence engagement Under NDA
  • 04 A field-operations dispatch and tracking platform rollout In delivery
  • 05 A legacy-systems integration layer for a mid-market services group In delivery
  • 06 A managed-platform migration onto a fully operated stack Scoping

Each entry goes live only with explicit client approval; some will publish anonymised, some named.

02 / 03 Methodology

How we research, write, and approve case studies.

Every case study on this page is sourced, drafted, and approved against the same four-stage process. The standard of evidence is deliberately higher than the consultancy norm, and the workflow is published openly so prospective clients know exactly what they would be agreeing to before any engagement gets to that stage.

01 · Sourcing

Real numbers, from real systems.

Numbers in a case study come from the system itself or the client's books, not from a sales call. We pull operational metrics from the tools we run (deployment frequency, error rates, latency, support ticket volume, on-call incident counts) and business metrics from the client's reporting layer (invoicing speed, throughput, hours saved, revenue affected). Every figure is traceable to a source the client can verify; if it can't be sourced from a system or a set of records, it doesn't appear with a number attached.

02 · Drafting

Written by us, approved by the client.

Drafting is handled by Okenwa Labs. The client reviews twice: once for factual accuracy and confidentiality, and once for tone and framing. Both rounds happen in writing. Any line the client objects to is either redrafted or removed; the client retains a veto on any specific claim. Nothing goes live without explicit written approval, and the client retains the right to ask for the case study to be amended or withdrawn at any later point, no questions asked.

03 · Anonymisation

When the client prefers to stay unnamed.

Where the client prefers anonymity (most commonly in due-diligence and consultancy work, occasionally in build engagements with sensitive competitive context) we anonymise the company, sector specifics, and any identifying scale figures. The structural shape of the engagement (problem, approach, decisions, outcomes) is preserved. Anonymised case studies are flagged as such on the page, and the client always sees, and signs off on, the anonymised draft before publication.

04 · Format

What a published case study contains.

Each published case study walks through six things in this order: the client and their starting state, the specific problem (including any hidden costs we found that they had not quantified), the approach we proposed and the reasoning behind it, the work we delivered, the engagement model the client chose and why, and the outcomes by the numbers. The sample below shows the full format applied to a composite engagement, used as a template for case studies still in flight.

Sample · Template

How our case studies will look.

A worked example of the format, using a realistic composite rather than a real client. Every section below is what a published case study will contain.

Composite example · illustrative only

An operations platform that stopped costing them weekends.

Infrastructure Field operations Fully managed

The client

A regional services operator with a field team of roughly 45 people across several sites. A decade of growth had left them running their dispatch, job tracking, and reporting out of a combination of spreadsheets, email threads, and a CRM that wasn't designed for the job.

The problem

Three knock-on effects were visible from the outside:

  • The operations lead spent most of every Sunday stitching the week's data together for Monday morning reporting
  • Crews on site regularly finished jobs that had already been cancelled because the update hadn't reached them
  • Invoicing lagged by two to three weeks, tying up working capital the business couldn't spare

What we did

We spent two weeks inside the business understanding how the work got done in practice, then proposed a staged replacement rather than a big-bang rebuild. The first phase, a single operational dashboard unifying dispatch and job status, went live in eight weeks.

Over the following six months, we added the field-crew mobile app, automated invoicing triggers, and a simple reporting layer that replaced the Sunday spreadsheet exercise entirely.

What they chose

The client started on a service-by-service basis (Option B) for the first build, then moved to a fully managed retainer (Option A) once the platform was in production. We run hosting, support, and iterative improvements on an ongoing basis.

Sunday reporting work
Eliminated entirely; reports are now automated
Invoicing lag
Cut from around 17 days to under 48 hours on average
Repeat-visit incidents
Reduced by roughly 70% in the first quarter post-launch
Note on this example

This is a template for the case-study format, not a record of a specific engagement. Published case studies on this page will always be real, named where possible, and approved by the client before going live.

Got a problem you'd like studied honestly?

We'd rather have a straight conversation about your situation than show you marketing versions of someone else's. A thirty-minute call usually tells both of us whether there's a fit.

Start a conversation → See our capabilities