Six weeks after a site goes live, someone asks why there is no client portal. The honest answer is usually that it was discussed, priced, and set aside for good reasons in week one. But if nobody wrote that down, the answer sounds like an excuse invented on the spot.

That is what a deferral list prevents. It is a plain record of what a build deliberately did not include, and why.

What is a deferral list?

A short document, kept with the project, listing each thing considered and set aside. One entry has four parts: what it was, why it was deferred, what it would cost to add later, and what would have to be true for it to be worth adding.

That is all. No formatting exercise. A page or two of ordinary sentences, written while the reasoning is fresh.

The name matters a little. It is a deferral list, not a limitations list. Almost nothing on it is impossible. It is work that was weighed against everything else in scope and lost, this time.

Why write down what you did not build?

Three reasons, and the third is the one people underestimate.

The first is memory. Six months on, nobody recalls why the booking flow skipped the intake questionnaire. Without a record, the team relitigates a settled decision, usually badly, because half the context is gone.

The second is trust. A vendor who hands over a list of trade-offs alongside the finished work is telling you they made choices on purpose. A vendor who presents a build as complete is either not being straight with you or was not paying attention. In my experience, firms find the first far easier to keep working with.

The third is that it makes the next decision cheap. When budget appears next year, you are not starting a discovery process. You have a list, already reasoned through, with a rough cost against each line. You pick one.

What belongs on it?

Anything real that was considered and set aside. Features that did not fit the budget. Integrations that were possible but not yet justified. Content that needs input the firm did not have time to produce. Automation that would have needed governance nobody had written yet.

What does not belong: anything vague. "Improve SEO" is not a deferral, it is a wish. "We did not build individual service pages for the four niches, because the positioning for two of them is still unsettled" is a deferral, and someone can act on it.

Leave the hard ones in. A deferral list that only contains comfortable items is decoration. If a decision was close and might turn out to be wrong, that is exactly the entry worth having in writing.

Who reads it, and when?

The firm that owns the system, at three moments. When the project closes, so the decisions are understood rather than assumed. When something in the market changes and last year's reasoning no longer holds. And when new budget appears and someone asks what to do with it.

It also serves whoever inherits the system. The next person to work on it, whether inside your firm or not, learns more from the reasoning behind what is absent than from a tour of what is there.

We keep one on every engagement, which is part of what Considered Build means in practice. It costs about an hour at the end of a project. It saves the awkward conversation eighteen months later where nobody can remember whether something was overlooked or decided.

Honest work leaves things out. The difference is whether you can say which things, and why.

If you want an outside read on what your current system does and does not do, The Second Look is free and takes about four minutes.