Most digital projects do not fail because of bad design or bad code. They fail because nobody wrote down who decided what, or when. A decision made in a Slack thread at 11pm is not a decision. It is a message. The checkpoint model exists to fix that.

What a checkpoint actually is

A checkpoint is a named moment in the project where something specific is reviewed, approved, and recorded. Not a phase, not a vague milestone. A checkpoint has a name (CP-03 Design), a deliverable (wireframes for all five screens), an owner (us), and an approval method (written sign-off in the decisions log). When it is cleared, everyone knows. When it is not cleared, nobody moves forward.

Why phases fail where checkpoints work

Traditional project phases (discovery, design, development, launch) are too wide. A two-week design phase can contain 40 decisions, and most of them happen without anyone noticing. By the time the client sees the output, the decisions are baked in. Checkpoints break the work into smaller units where each decision is visible before it becomes load-bearing. You catch the wrong turn before you have run 200 metres in the wrong direction.

How we run CP-01 Brief

The first checkpoint is the most important one. We read everything the client sends, then we ask the questions that are not in the brief. What does failure look like? Who has veto power over the final design? What has been tried before and why did it not work? The answers go into a four-page route document that both sides sign off before any design work starts. That document is the map for the entire run.

What happens when the route changes

Routes change. A client discovers a new competitor. A technical constraint appears in build. A stakeholder changes their mind. When this happens, we write a short amendment to the route document, note the impact on timeline and cost, and get written approval before we adjust. The route is a living document, not a contract carved in stone. But every change to it is recorded.

The result: fewer surprises at launch

Projects run on the checkpoint model tend to have quieter launches. Not because nothing goes wrong, but because most things that would go wrong have already been caught at an earlier checkpoint. The 30-day post-launch window we include in every build is rarely dramatic. Usually it is a mobile layout fix and a copy change. That is what a clean run looks like.

If your last project drifted, it probably did not need a better agency. It needed a better route. That is what we build first.