← The Boring Department

Part two

While we are building

What each of the three weeks looks like, who tests and how, how to report a problem, and what we still do slowly.

Engraved illustration of a workbench with a half-assembled machine, calipers and notes

§ 07 What the three weeks look like

What the three weeks look like

Three weeks, and you are in the software from the first one. Nobody waits for a reveal.

Fig. 4 — Three weeks, drawn

What happens in each of the three build weeksWeek 1We build and deployYou: 2 hrs, kickoff + first lookWeek 2You use it, we change itYou: daily use, notes as you goWeek 3Hardening and handoverYou: sign-off, route decision■ our hours□ yours
  • Week 1: We build and deploy. You: 2 hrs, kickoff + first look.
  • Week 2: You use it, we change it. You: daily use, notes as you go.
  • Week 3: Hardening and handover. You: sign-off, route decision.
Your involvement is small in hours and large in consequence. The build bends around what you report in weeks two and three.
  1. Week 1

    Something deployed

    You log in

    We build the thinnest version that lets one person complete one real case, and we put it somewhere you can reach. It will be ugly and incomplete. That is the point: you react to a real screen instead of a document.

  2. Week 2

    Real cases, real data

    Two or three testers

    Your people run actual work through it. We fix what breaks, add the fields that turn out to matter, and remove the ones nobody used. Most of the shape of the final thing gets decided here.

  3. Week 3

    Edges and handover prep

    Wider group

    The awkward exceptions, permissions, the , backups, and the documentation. We also measure against the number you named in phase 01.

What stalls a build

  • No test data, or data so sanitised the awkward cases vanish.
  • Access requests that sit in a queue. Start those in week zero.
  • One reviewer with no delegate, on leave in week two.
  • Feedback saved up for a formal review meeting at the end.

What counts as delivered, and what happens if you go quiet: Engagement Terms § 04 — Delivery and acceptance.

§ 08 How testing works

How testing works

Who tests

  • The people who do the work, not their managers, and not us.
  • Two or three of them. Ten testers produce noise and no owner.
  • At least one person who is fast at the current process and one who is new to it. They find different problems.

How to test

  • Run one real case from start to finish. Clicking around finds cosmetic issues; finishing a case finds the real ones.
  • Bring the cases you dread. The duplicate, the one with a missing field, the one that had to be escalated last month.
  • When something is wrong, stop and tell us. Working around it silently teaches us the wrong thing.
  • Use real timings. If a step took four minutes, say four minutes.

On data

Test on real data where your policy allows it, or a copy that keeps the messy cases. Clean sample data makes everything look finished.

§ 09 How to give feedback

How to give feedback

Feedback is the whole mechanism. Nothing else in the process replaces it, so it is worth doing well. Six habits cover almost everything.

Screenshot first
A screenshot of the whole window beats three sentences of description. Include the address bar and any error text. Crops hide the context we need.
What you did, what happened, what you expected
Three short lines. This one format removes most of the back and forth.
One issue per note
Five things in one message means four of them get lost.
Say whether it blocks you
Blocking, annoying or cosmetic. We sequence by that, and you decide the sequence.
Send it the day you hit it
A note on Tuesday can be fixed Tuesday. The same note in Friday's summary costs a week.
Say when something is fine
Silence reads as approval. It usually is not. A one-line 'this part works now' is genuinely useful.

Note

You will not offend us. We would rather hear that a screen is confusing in week two than discover it after handover.

§ 10 What we need from you

What we need from you

Off-the-shelf software makes you adapt to it. Bespoke software adapts to you, but only if you are in the room while it is being cut. The most valuable thing you have is what your experienced people do when the formal process breaks down, and none of that is written anywhere.

What we need from you

  • One named owner who can make decisions without convening a committee.
  • An honest description of how the work actually happens, including what your experienced people do when the formal process breaks down.
  • Real data, or a realistic stand-in. Fake data hides the awkward cases.
  • A reaction every week. Twenty minutes is enough.

What you get back

  • Software shaped around your workflow, instead of your workflow bent around a generic tool.
  • The vocabulary your team already uses, in the interface.
  • The awkward exceptions handled, because we saw them while building.
  • The repository, the deployment and the documentation.

§ 11 What speed does not excuse

What speed does not excuse

The fair objection to quick delivery is that it hides risk. It can.

Google's 2025 DORA research found that most technology professionals now use AI at work and believe it improves their productivity, while delivery stability gets worse unless the underlying engineering practice is strong. Speed amplifies whatever practice you already have. So the boring parts stay boring.

Access and identity
Roles, permissions and secrets handled properly, not bolted on before launch.
Data handling
Classification, retention, deletion, and a clear answer to who can see what.
Backups and recovery
Backups that have been restored at least once, and a rollback that works.
Tests and monitoring
Tests around the parts that would hurt, plus logging and alerts so failures surface before your users report them.
Documentation
Enough that a competent stranger, or your future in-house hire, can take it over.
One accountable human
Someone answerable for how the software behaves in production. No tooling replaces that.

All of it sits in the Engagement Terms § 07 — Data protection and security, not in a sales conversation.