MMcpeerigan

Note · 20 October 2026

We built the checkout and forgot the paperwork

A complete, working payment system. Card handling, subscriptions, cancellation, the lot. And not one of the four documents the payment provider requires before any of it is allowed to run.

On a site we were setting up, the payment side was finished and tested. Checkout worked, subscriptions renewed, cancellation took access away on the next request, and the whole thing was covered by tests.

Terms of service: not found. Privacy policy: not found. Refund policy: not found. Contact page: not found.

Every payment provider requires all four. Two of them have to be publicly reachable before an account is approved. We had built the machine and skipped the paperwork that makes it legal to switch on.

Why this happens to competent teams

Because the build has momentum and the paperwork does not. Every task in the payment system suggests the next one. Nothing in writing a refund policy suggests anything, and it is not blocked by any of the work, so it waits — right up until it is the only thing standing between the business and revenue.

Done is not defined by the fastest requirement. It is defined by the slowest one.

The general case

Most things that can be sold have a non-technical gate in front of them, and it is almost never on the build plan:

  • Insurance or a licence the contract requires before work can start.
  • A data processing agreement a customer's legal team will ask for during procurement.
  • Tax registration in a place you have begun selling into.
  • Accessibility obligations attaching to a public service.
  • Industry registration that takes weeks and cannot be accelerated by caring about it later.

Every one of these is invisible until the day it is the only thing left, and almost none of them can be done quickly.

What to do

  • Write the launch checklist before the build, including the parts that are not building. Terms, policies, registrations, insurance, approvals.
  • Find out which items have a waiting period. Those start first, not last, because effort cannot shorten them.
  • Treat the provider's own requirements list as a specification. They publish it; most people read it after being declined.
  • Make the policies describe the system you actually built. A privacy policy listing cookies you do not set is a published statement about your own business that is false.

The honest version

This one was avoidable. The four documents took an afternoon, and were better for being written after the system existed — the privacy policy describes the three things actually stored, rather than the usual boilerplate.

But had we been relying on that revenue, the afternoon would have been spent under pressure at the worst possible moment, and we would have reached for a template instead.

Recognize this in your own systems? That is usually where we start.

hello@mcpeerigan.com