Plan the second year, not the launch

What a website plan usually contains

A founder sends me a website plan and asks whether the budget looks right. It is a good plan. Sitemap, templates, content inventory, timeline, launch date, and a number at the bottom that somebody has already half approved.

I ask what the plan says about the year after the launch date. There is usually a pause, and then some version of we will figure that out with whoever we work with. That sentence is where most of the money in the plan is quietly decided, and nobody in the meeting knows it yet.

A sitemap, a set of page templates, a content inventory, a timeline, and a launch date. It is a plan for producing a website, and as a production plan it is usually good.

What it almost never contains is any statement about what happens after the launch date. Who is responsible for the site being correct. What they are permitted to change. How something that goes wrong gets noticed. When anybody looks at it again.

That absence is not an oversight. It is a consequence of how the work gets funded, because a project has a scope and an end and a recurring practice does not. But the site does not stop existing at the end of the scope, and everything expensive about a website happens after it.

So this is the set of decisions I now argue for before a build starts. None of them is about design and all of them determine whether the design survives.

The seven decisions, and what deferring each one costs

Before going through them individually, here is the whole set with the thing that actually matters attached: what it costs to make the decision later instead of now.

The pattern is consistent. Every one of these is minutes in a planning meeting and somewhere between a day and a rewrite once content exists. That asymmetry is the entire argument for putting them in the plan.

Decide who owns each page

Ownership is the first decision and the one that predicts the most. Not who owns the website, which everybody agrees on and which means nothing. Who owns each page, or each group of pages, by name.

The unit that works is a person against a set of pages. Pricing and plans are owned by one named person. Product pages by another. The resource library by another. Each of those people can answer the question is this currently correct, and each of them is the person to ask when it is not.

The test to run in the planning meeting is uncomfortable and fast: go through the sitemap and put a name against every page. Where you cannot, you have found the pages that will decay first, and you have found them for free before anybody built anything.

A team name is not an answer. A rota is not an answer. In my experience the pages owned by everybody are the pages owned by nobody, and they are reliably the ones that are wrong eighteen months later.

One practical note on how to run it. Do the naming pass with the sitemap on a screen and the names typed directly onto it, rather than collecting them afterwards. Ownership stated out loud in a room where the person is present is a commitment. Ownership collected by email afterwards is an assignment, and assignments get declined quietly by being ignored.

Decide where each fact lives

The second decision is where facts are authoritative, and it has to happen before anybody writes a page, because after that it is a cleanup rather than a decision.

Take the facts that appear in more than one place: prices, plan names and limits, product names, integration names, team member titles, compliance claims. For each one, name the single page or field that states it. Everywhere else references it rather than restating it.

This is the decision that prevents the most common and most expensive failure, which is two pages disagreeing about pricing in front of a buyer. It costs an hour in planning and it is nearly impossible to retrofit onto a site where forty pages have typed the same number.

It also determines your CMS model, which is why it belongs in the plan rather than in the build. A fact with an owner becomes a reference field. A fact without one becomes text typed into a page, and text typed into a page is a future disagreement.

Decide the vocabulary before the copy

The third is a shared vocabulary, and it is the one people find hardest to take seriously in a planning meeting because it looks like a style exercise.

Every company has terms that are used inconsistently. Two names for the same feature, one of which is internal. A word the founders use that customers do not. A capitalisation that half the team observes. On a small site this is invisible. On a hundred pages written by five people over two years it becomes a site that appears to describe several different products.

The artifact is short: the canonical term, the things people wrongly call it, and one sentence on what it means. Twenty to forty entries covers most companies.

The reason it belongs in the plan rather than in a later cleanup is that it is nearly free to write down before the copy exists and expensive to enforce after. It also gives you the beginning of a public glossary, which is worth having for its own reasons, and it is what makes internal linking possible rather than arbitrary.

A vocabulary decided after the copy is written is not a vocabulary. It is an argument scheduled for later.

Decide the internal link structure, not just the navigation

Navigation is what people see. Internal linking is what holds the site together, and it is usually left to whoever writes each page, which produces a site where the links reflect what the author happened to remember.

The version that works comes out of the vocabulary decision. For each canonical term, there is a page that is authoritative for it, and any page using that term links to that page the first time it appears. That is a rule somebody can follow without judgement, and it produces a link structure that reflects the actual shape of the subject matter.

It also means that when a page changes, you can find everything that points at it, because the linking was systematic rather than incidental. That is the difference between a rename being a query and a rename being a search.

This is the decision that most obviously pays off later rather than at launch, which is why it needs to be in the plan. Nobody will retrofit it.

Decide what you will measure, and accept how little that is

The fourth decision is measurement, and the useful version of it is much smaller than what usually appears in a plan.

Most website plans include a measurement section listing everything that could be tracked. That produces a lot of events, most of which are never read, and the ten that matter are harder to find among them.

The version worth planning is: which three questions do we want to be able to answer about this site in a year. Usually they are something like whether people find the pricing information they need, whether the integrations page is doing its job, and whether the resources are read by the audience they were written for.

Then instrument for those three and nothing else at launch. It is a smaller job, the events are correct because there are few enough to verify, and adding more later is easy while removing unused events never happens.

The other half of this decision is accepting what measurement cannot do. Most single page changes on a normal site will not produce a resolvable effect, so the plan should not promise one. Plan to observe behaviour and ask people, and reserve statistical claims for the two or three surfaces with the volume to support them.

Decide the CMS model against the second year

The fifth decision is the data model, and the framing that produces a good one is to model against changes rather than against pages.

The question to ask for each collection is not what does this page need. It is what happens when the thing this describes changes its name, its price, its availability, or its status. If the answer is that somebody edits every instance by hand, the model is wrong regardless of how well the page renders.

Three things belong in every collection and are almost always missing: a reference rather than typed text for anything another entity owns, an enum rather than free text for anything with a fixed set of values, and a last reviewed date with an owner.

The last one is worth arguing for specifically, because it is the cheapest and the most often cut. Without it, finding content nobody has looked at is reading everything. With it, it is a query, and the review becomes a schedule rather than an initiative.

Decide the update rhythm, and put it in a calendar

The seventh decision is when anybody looks at the site again, and the only version that survives is one that exists as a recurring event in a named person's calendar.

A cadence in a document is a good intention. A recurring meeting with an owner and an agenda is a practice. The difference in outcome between those two is larger than the difference between any two design directions.

What the rhythm contains matters less than that it exists. A workable version is monthly: read the pages whose review date has passed, check the facts that changed this month against everywhere they appear, look at the questions sales answered repeatedly, and pick one thing to fix.

One thing per month is not ambitious and it compounds. Twelve deliberate improvements a year, each with a reason and an owner, is more than most sites get in three years of good intentions.

The planning pass

All seven decisions, in a form you can run in one session before a build. It takes about two hours with the right people in the room, and the right people include somebody from sales.

The output is not a document. It is seven answers, and the ones you cannot answer are the finding.

Where this goes wrong in practice

Treating it as a document rather than a set of decisions. A planning document that records the questions without answering them is worse than nothing, because it creates the impression the work was done.

Doing it after the design is approved. By then the sitemap is emotionally settled and the ownership conversation reads as an obstruction rather than as planning.

Leaving sales out of the room. The three measurement questions and the vocabulary both come out better when somebody who talks to buyers is present, and both come out theoretical when they are not.

Making the rhythm too ambitious. A weekly review will not happen. A monthly review with one action might, and one that happens is worth more than one that is correct.

Assuming the agency will hold it. If the ownership names are all agency people, the practice ends when the contract does, and that is a fragile arrangement to build a site on.

What this looks like a year later

A site planned this way does not look different at launch. That is the difficult part of arguing for it, because the entire return arrives later.

At a year: pricing has changed twice and the site was correct both times, because there was one place to change it. The product was renamed once and it took an afternoon. There is a list of pages nobody has reviewed and somebody is working through it. Three questions can be answered about how the site is performing, and the answers are trusted because only three things were instrumented. And when somebody asks who owns the integrations pages, there is a name.

None of that is impressive to look at. All of it is the difference between a site that improves and one that is quietly getting worse while looking the same.

Where our tooling fits, and where it does not

Creogen is aimed at the operational half of this: which pages state the same fact, which disagree, what changed and whether it helped, and which content nobody has reviewed. Creobot supplies the input the measurement section is weakest on, the questions people ask that no page answers. Both are in private development, and I would rather say that than imply otherwise in an article about planning honestly.

The seven decisions above need none of it. They are a two hour conversation and a page of answers, and if you make them well the tooling question becomes about convenience rather than about whether the site is manageable.

The reason we are building any of it is that we spent six years making these decisions for clients in planning meetings and then watching the practice fade about four months after launch, because nothing carried it. A calendar invitation is a weak mechanism. That gap is the product, and it does not exist yet.