April 2, 2026

Why We Document Everything (And How It Prevents Disputes)

by Stuart Deadman

People hear “documentation” and think it’s corporate admin. In reality, it’s one of the most practical ways to keep a project calm.

When a build gets stressful, it’s rarely because somebody woke up wanting an argument. It’s usually because two people remember the same moment differently. A decision was made verbally. A detail was “assumed”. A change was agreed, then forgotten. And suddenly you’ve got a classic he-said-she-said situation, and nobody wins.

I’m Stuart Deadman, and I’ve learned that good documentation doesn’t slow work down. It speeds it up, because it removes uncertainty.

What “document everything” actually means (in plain English)

It doesn’t mean endless paperwork. It means capturing a few key things consistently:

  • A photo log (progress + hidden work + key stages)
  • A decision log (what was decided, by who, and when)
  • A variation log (what changed, what it costs, what it does to the programme)
  • Sign-offs (small confirmations at the right moments)

That’s it. If you do those four things well, you prevent 90% of the arguments that drain time and energy.

Why photos matter more than most people think

Photos aren’t for social media. They’re for clarity.

They help with:

  • showing progress without long explanations
  • capturing hidden work (before it’s covered up)
  • confirming details (positions, routes, finishes)
  • reducing misunderstandings (“I thought it was going there”)

A simple rule we use: if it’s going to be hidden later, photograph it now.

The decision log is where projects stay calm

Projects don’t slip because people are lazy. They slip because decisions drift.

A decision log can be as simple as a running note:

  • what’s the decision
  • who needs to approve it
  • by when
  • what happens if it’s late

It keeps everyone honest and stops the “we were waiting on you” vs “nobody told me” loop.

Variations are inevitable, confusion isn’t

Most builds change. That’s normal.

What isn’t normal (but is common) is changing things without writing it down. That’s how budgets drift and relationships sour.

A clean variation process is simple:

  • description of change (plain English)
  • cost impact
  • time impact
  • written approval before it becomes work

Not because we’re being awkward, but because it protects both sides.

A documentation rhythm that works in the real world

You don’t need fancy software. You need consistency:

  • Weekly update (what happened, what’s next, decisions needed)
  • Photos attached (3–10, not 50)
  • Decision/variation log updated as you go
  • Small sign-offs when key moments happen

The goal isn’t to create admin. The goal is to remove grey areas.

If you’re a client, here’s what to ask

You don’t need to be technical. Ask:

  • How do you record decisions?
  • How do you handle variations?
  • Will you send weekly updates with photos?
  • What happens if something changes?

If a builder gets defensive about those questions, that’s useful information.

If you want the simple templates we use (weekly update + decision log + variation log), request them via the contact form.

Useful next pages:

More News