Brand Decisions That Must Freeze Before a Website Build Starts, and the Ones That Can Wait

The sequence is real and nobody serious disputes it. What a company claims, and who it claims it to, determines what its website has to do. A build that starts before those are settled gets rebuilt, and the rebuild is rarely the small kind. The trouble is that the advice is quoted most often in the rooms where it is least available. The launch date in those rooms was not set by the strategy work. It was set by a funding round, a contract that starts in September, a conference stand that has already been paid for, or a platform the current site can no longer sit on.

So the question worth answering is not whether sequential is better. It is which specific decisions cannot survive being made late, which ones can arrive whenever they arrive, and what has to be true of the build for the second group to stay as large as it is. Answer those and concurrency stops being a compromise you apologise for and becomes a shape of work with known edges.

Strategy first assumes that strategy terminates. On its own, it rarely does. Positioning work has no natural end point: there is always another customer conversation to have, another competitor to read, another version of the sentence that is slightly better than the last one. Left alone, it stops when something external stops it, and on a project with no build running, the thing that stops it is usually the end of the budget. The sequential model in practice is often not strategy followed by build. It is strategy, followed by a pause, followed by a build that opens with a document nobody has looked at for six weeks.

The second reason is that the deadline is almost always exogenous. It comes from outside both workstreams and it is not negotiable by either of them. Telling a company that it should have started the brand work in March is accurate and useless. The deadline is going to win, and the only choice available is whether it wins tidily or by attrition, with structural decisions being made by whoever happens to be in the room when the developer asks a question.

There is a genuine counter-case, and it should be stated plainly rather than buried. If the company cannot yet say what it sells, or cannot name the buyer, there is nothing for a build to be a build of, and starting one converts an open question into an expensive answer that is then defended because it was expensive. The same holds when the diagnosis itself is unsettled. If the problem might not be a brand problem at all, the first thing to settle is which problem you actually have, because a website is a poor instrument for finding out.

Short of that, concurrency is workable. What makes it workable is not enthusiasm, and it is not good communication in the general sense. It is a small number of decisions being genuinely closed on time, and a much larger number being deliberately left open in a build that can absorb them late without flinching.

The freeze list is short, and keeping it short is the point. Every item on it is a decision that will now be made under time pressure, which is the condition most likely to produce a brand decision somebody regrets. Add to it defensively and you get an entire strategy phase compressed into a fortnight, which is worse than concurrency rather than safer than it. Three things belong on it for most builds.

Proposition and audience

What you claim, and who you claim it to. This freezes first because it determines the page inventory, and the page inventory is what everything else hangs on. A site addressed to one buyer with one claim has a different number of pages, in a different order, making a different argument, than a site addressed to two buyers with a shared claim. Those are not variations on a layout. They are different builds that happen to use the same components.

The freeze here does not need to be eloquent. It needs to be decided. A single unglamorous sentence naming the buyer and the claim is enough to start a build on, and it is considerably more useful than a beautiful sentence that arrives in week five. If the strategy workstream cannot produce that sentence yet, it can usually produce the shortlist it is choosing between, and a shortlist of two is enough to identify which structural questions are genuinely contested and which are common to both options and can therefore be built now.

Primary action and information architecture

The primary action is the single thing you want a reader to do, and it belongs on the freeze list because it is not a button. It is the reason each page has an ending, and the ending is what the copy above it is written towards. Change the primary action late and every page loses its last paragraph, which is usually the paragraph that took longest to write. A site built towards an enquiry reads differently from one built towards a download, and the difference is not confined to the final screen.

Information architecture freezes alongside it, because the URL structure is the part of a website with dependents outside the project. Once a URL is published it can be linked to, cited, printed, indexed and pasted into an email that somebody reads next year. Google Search Central documents the mechanics for changing them: permanent redirects, updated internal links, and a reprocessing period whose length you do not control. All of that is available and none of it is free. The corollary is that a late architecture change is paid for partly by people outside your organisation, which is a different category of cost from the ones a project plan tracks.

Vocabulary and name

The name, if it is changing, and the handful of nouns the company uses for what it sells. The name is the obvious half: it appears in the domain, the URLs, the email addresses, the metadata, the file names, the asset names, and everything already in print. A name arriving in week six is not a brand decision at that point. It is a migration, and it will be scheduled and staffed like one or it will be done badly.

The nouns are the less obvious half and they cost more than people expect. If the strategy workstream settles on programme while the build has spent a month writing course, the fix is not a find-and-replace. Some of those words sit in URLs, some in navigation labels whose width the design has accommodated, some in headings the argument is structured around, and some in the questions on a form. Freezing the vocabulary does not require the positioning to be final. It requires somebody to say which word wins, provisionally, and to write it where both workstreams can see it.

A decision belongs on the freeze list when arriving late does not cost more work, but different work.

Almost everything else can arrive during the build, and the list is longer than most people are comfortable with because the items on it are the visible ones. Visibility is not structural weight. The things a client is most anxious to see settled are usually the things a competent build can absorb latest, which is an uncomfortable pairing and worth naming before it causes an argument.

• Colour, in full: the palette, the balance between neutrals and accent, and the proportion of any accent that appears in a given view.
• Typography: the typefaces, the weights actually used, the scale, and the relationship between heading and body sizes.
• The logo and any mark, provided the space it occupies has been reserved and its accessible name is fixed.
• Photography, illustration, and any figurative language of images, including whether there are photographs at all.
• Motion: what moves, how far it moves, and how long it takes.
• Sentence-level copy everywhere below the headings that carry the argument.
• Tone: how formal, how warm, and how much the writing is willing to concede.

The reason these can wait is mechanical rather than philosophical. Each of them lives in one layer of the build and does not leak into the others. Colour lives in tokens. Type lives in tokens and a small set of styles. Copy lives in strings. A logo lives in one file behind reserved dimensions. Change any of them the week before launch and the difference is confined to the layer that owns it, which means the change can be reviewed on its own terms instead of as a risk to the whole.

That is a claim about your build, though, not a law of nature, and the condition deserves to be stated. If colours are written directly into components, colour is a freeze item. If copy is embedded in markup rather than held as content, sentence-level copy is a freeze item. If the logo has no reserved dimensions, swapping it moves everything beneath it and the swap becomes a layout review. The resolve-later list is exactly as long as the implementation allows, and one of the more valuable things a build can do for a concurrent brand workstream is to lengthen that list deliberately, early, before anyone needs it to be long.

The sorting rule is cost to change after the build exists, and it resolves into two questions asked in order. The first: if this decision arrived the week before launch, what would have to be touched? If the honest answer is a token file, a set of strings, a stylesheet variable or a single asset, the decision resolves later. If the answer includes the route table, the navigation, the page inventory, or the argument a page makes, it freezes.

The second question is about dependents outside the project. Does anything you do not control depend on this decision being what it currently is? Published URLs, printed material, an address on a business card, a listing somebody else maintains, a link in an old newsletter. External dependents turn a moderate internal change into a change with a tail, and a tail is not something a launch week can carry.

Note what the test does not measure. It does not measure effort. Rewriting every paragraph on a site is far more work than moving one page up a level in the hierarchy, and the rewrite is still the safer late change, because its blast radius is one layer while the hierarchy change touches URLs, navigation, internal links, the sitemap, and anything already pointing at the old address. Effort is a scheduling problem. Blast radius is a risk problem, and only the second one belongs in this particular decision.

A third question helps when the first two are ambiguous: how many people would have to agree again? A change that reopens an approval already given is more expensive than its file difference suggests, because the cost is measured in calendar days waiting for people rather than in hours of work. Decisions that took a room a week to settle should be treated as structural even when they look cosmetic, since in practice you cannot revisit them cheaply whatever the code says. This is the point at which the rule stops being about implementation and starts being about the organisation, and it is worth admitting that the second half is the harder one to hold.

Two workstreams running against one deadline will diverge unless something specific holds them together. Good intentions are not that something, and neither is a weekly call in which both sides report progress. What holds them together is a shared vocabulary, a single record of decisions, and a defined moment at which a decision crosses from one workstream to the other in a form the receiving side can act on without interpretation.

A shared vocabulary from day one

Before anything is designed or written, both workstreams agree on what things are called: the nouns for what the company sells, the names of the audience segments, and the names of the site sections. These are provisional and they are allowed to change. What is not allowed is two names for one thing, because a translation layer then forms in somebody's head, and translation layers held in heads fail silently at precisely the moment the two workstreams are furthest apart.

The cost of getting the vocabulary wrong early is small; the cost of running without one is not. If the provisional noun turns out to be the wrong noun, you change a word in a limited number of places and nobody argues, because it was never presented as final. If there was never a provisional noun at all, you discover in week five that the strategy work and the build have been describing two different products, and the discovery arrives in a review, in front of people who do not know that and should not have to.

One decision record, two workstreams

One record, not one per workstream. Two records diverge on the day one of them is updated in a meeting the other side was not in, which is usually the second week. Each entry carries the decision phrased as a question, its current state, the provisional value if there is one, the person who owns it, the date it has to be frozen by, and what depends on it. State is one of open, provisional or frozen, and provisional is a legitimate state that has to be visible rather than implied by silence.

The rule that makes the record work is that a decision not in the record is not a decision. Said in a call, agreed in a corridor, implied by a design everybody nodded at: none of those count. This sounds bureaucratic and does the opposite of what bureaucracy does. It is what allows the build to proceed on provisional values without anxiety, because every provisional value is marked as one and carries a date, so nobody has to guess whether the current state of the site represents a settled position or a placeholder waiting to be replaced.

Zealsync operates Intense Path, its brand, growth and technology agency, so the argument above is made from inside the problem rather than about it. That is worth disclosing here, because holding both workstreams inside one organisation changes what the handover is contractually and changes nothing at all about whether the record has to exist. If anything, internal handovers are easier to leave unwritten, since everybody assumes somebody else was in the room when it was decided.

The weekly handover point, and the form a decision has to arrive in

A fixed point in the week at which resolved decisions cross from the brand workstream into the build. Fixed matters more than frequent. A decision that can arrive at any moment arrives at the worst one, and a build that expects decisions continuously never reaches the state where a week of work can be planned. Weekly is usually right; the interval matters far less than its being known in advance by both sides.

A decision arrives in a form, or it has not arrived. The form is short and it is not a document: which record entry this resolves, the final wording where wording is involved, what it replaces, whether it touches anything on the freeze list, and who signed it off. A decision that arrives as a comment on a design, a preference expressed on a call, or a sentence buried in a longer email has not arrived, and the correct response is to log it as open with a note rather than to act on it. Acting on it is how a preference becomes a commitment nobody remembers making.

Silence at the handover is also an answer and should be treated as one explicitly. An entry that reaches its freeze date without a resolution defaults to its provisional value, and that default is announced at the handover rather than assumed. Announcing it is what converts a drift into a decision somebody can object to while objecting is still cheap, which is the entire mechanism by which a provisional stops being a trap.

It will happen. A protocol that assumes otherwise will be abandoned the first time it does. When a decision on the freeze list arrives late, there are three available responses, and they should be named as such and chosen between openly rather than negotiated by whoever is most tired.

Absorb it, which means rebuilding the structural work the decision invalidates and moving the date. This is right when the decision changes what the company claims, because shipping a site that argues something the company has stopped believing is not a saving. It is the most expensive option and the one most likely to be refused for reasons unconnected to its merits, usually because the date has an audience and the rebuild does not.

Defer it, which means launching on the provisional value and making the change afterwards. This is frequently correct and it is not free. If the change touches URLs, the post-launch version costs permanent redirects, updated internal links, and a period in which two versions of the truth exist in other people's caches and bookmarks. If it touches vocabulary, the cost is a stretch of visible inconsistency between the site and everything printed around it. Deferring is a reasonable trade as long as the second half is actually scheduled, with an owner and a date, before launch. A deferred change without a date is not deferred. It is dropped, with a nicer name.

Refuse it, which means the build wins and the decision does not land. This is legitimate for a genuinely late preference and corrosive for a genuinely late insight. The distinction is whether the decision changes what is true about the business or changes what somebody would prefer the site to look like. Refuse enough of the first kind and the strategy work becomes decorative, which is worse than never having done it, because now there is a document everyone can point at and nobody follows.

The reliable tell that you are in this situation and mislabelling it is the phrase just a wording change. Structural decisions almost always present as wording, because the visible surface of an architecture is the words in the navigation. When somebody describes a change as small and the change touches a navigation label, check the record before agreeing.

Concurrency rarely fails loudly. It fails by mechanism, quietly, and each mechanism has a tell that becomes visible weeks before the consequence does. These are worth learning as signatures rather than as a checklist, because the point is to recognise one in progress, not to tick it off after.

• Drift by omission. A provisional value is set, the build proceeds on it, and nobody revisits it, so it hardens into the answer by default. The tell is that nobody can say when the decision was made or who made it. Ask that question about one entry a week and the mechanism cannot run for long.
• Retro-fit. The strategy is quietly rewritten to describe what has already been built, because the build is visible and persuasive and the strategy is a document. The tell is a position that arrives with no rejected alternative attached. A real decision has something it beat, and can say what.
• Divergent vocabulary. Two names for one thing, maintained in parallel because neither side wants to be the one who raises it. The tell is somebody translating fluently between the two in a meeting, which means the translation has quietly become a skill instead of a problem.
• Approval inflation. Because decisions are arriving late they arrive as opinions rather than conclusions, and opinions attract participants. The tell is the review getting larger week by week. The same five people twice running is healthy; five, then seven, then nine is a decision that is not being made where it should be.

None of these needs a formal audit to catch. They need somebody reading the decision record once a week and asking two things: has anything changed state without a note, and has any entry been provisional for longer than the workstream that owns it has been running. The check takes minutes, and it is the only part of the protocol that has to be actively defended, because it has no immediate output and will therefore be the first thing skipped in a busy week.

Rather than close on a checklist, one decision traced end to end. Everything below is hypothetical and describes no particular company, engagement or timeline. It is the most ordinary decision on a site of this kind, which is exactly why it is a useful one to follow.

A company sells a single service to two recognisably different kinds of buyer. The decision is whether the site addresses them as one audience or two. At the brief, the entry is opened and immediately classified as structural, because it determines whether there is one service page or two, whether the navigation splits, and whether the URLs carry an audience segment. Its freeze date is set to the day route work begins, which is week five.

A provisional value is recorded at the same time: one audience, one page. The provisional is chosen on which option is cheaper to leave, not on which currently seems more likely to be right, and the distinction matters. Splitting one page into two later adds a URL and can leave the original in place as a parent. Merging two pages into one later means a permanent redirect and a reprocessing period on somebody else's schedule. The asymmetry is modest, it is real, and it is the sort of consideration that should decide a provisional while the evidence is genuinely open.

Week two. The brand workstream reports that the two buyers differ in what they object to rather than in what they want from the service. That does not change the structure, so the entry is logged as unchanged with the reason attached. Logging the non-change matters more than it looks: an entry that has been reviewed and held is in a different condition from one nobody has looked at since the brief, and only the record can tell those two apart.

Week four. New evidence arrives: the two buyers use different words for the same service. This looks as though it might reopen the structural entry, and it does not. It touches vocabulary, and the specific vocabulary in question sits in body copy and in one heading rather than in a URL or a navigation label. Vocabulary that lives in strings is on the resolve-later list, so the build absorbs it at the next handover and the route work is unaffected. Had the same evidence touched the noun used in the navigation, the structural entry would have been reopened. The difference between those two cases is a difference of one location, not of importance, and the record is what makes that visible rather than arguable.

Week five, the freeze date. The decision is taken: one page, one primary action, the two objections addressed in sequence within it. The entry moves to frozen and the rejected alternative is written down with its reason, so the question cannot be reopened later as though it had never been asked. Route work begins that week against a structure unchanged since the brief.

Weeks six to ten. The copy on that page is rewritten twice, the order of the two objections is swapped once, the palette arrives, and the photography is replaced entirely four days before launch. None of it costs anything structural, because none of it was ever structural. That is the whole return on keeping two lists: the one decision with dependents was closed on schedule, and everything downstream of it stayed open for as long as staying open was useful.

The honest limit deserves stating. Had the week-four evidence said the two buyers want different outcomes rather than different words, the entry would have breached its freeze date, and the earlier section applies without softening: absorb, defer or refuse, chosen deliberately and recorded. The protocol does not prevent that situation and does not claim to. It makes it visible on the day it happens rather than in the launch week, which is the difference between a decision and an incident.

If a date is already fixed and the strategy work has not finished, the argument about sequence is not the one worth having. The one worth having is which few things freeze, by when, and what happens to everything else in the meantime. That is a conversation Intense Path is set up to have, and if the prior question is still open, what gets sold when a brand stops working answers which piece of work is being bought before any of this applies.