Published 1 September 2026 and updated four days later. Two section headings were shortened so they fit the contents rail. The argument and every example are unchanged.

Somewhere in the middle of a content build, someone notices the terms and conditions don't sound like the same company as the homepage. Now two things need fixing: the T&C, and whoever assumed the order didn't matter. The second fix is the expensive one, because it means going back and re-deciding something that should have been settled before a single sentence got written. Ask the person commissioning that project what a brief is for, and the answer is almost always a list: word count, deadline, who's assigned to what. Those are real inputs, and none of them touch the question that actually decides whether the project holds together, which is what order the pieces get written in. A brief that names five deliverables and a due date for each has told the writer everything except the one thing that decides whether piece four contradicts piece one. That gap doesn't show up early. The first piece has nothing to be consistent with yet, so everything looks fine. It's the third or fourth piece where the cracks appear: a tone that doesn't match, or a claim already made differently somewhere else. By then, fixing it means going back and rewriting, on a deadline that was set assuming this wouldn't happen.

What the brief decides

A brief that works answers a question almost nobody asks before assigning the first piece: for everything in this project, what does it reference, and what has to be true about that reference before it can be written honestly. A homepage that will get quoted somewhere else needs its voice locked before the thing quoting it exists. A terms document that has to sound like the same company as the sales copy needs someone to have decided what that voice sounds like, first. None of this requires a formal process. A shared document with three columns, one for the name of each piece, one for what it depends on, and one for what depends on it, does the job. What matters is that the answer exists somewhere before the first writer opens a blank page, rather than living only in the head of whoever happens to remember it that week, because that person doesn't always stay on the project through the last deliverable. That question produces an order, not a schedule. A schedule ranks pieces by deadline. An order ranks them by what has to exist, even in draft form, before the next one can be written without guessing. Guessing is what a writer does when they're handed a T&C brief with no example of how the rest of the company talks. The default they reach for is usually more formal than everything around it, and the mismatch sits there until someone reads all the pages back to back. Working this out costs almost nothing up front. It's a short conversation before the first assignment goes out, covering what already exists, what doesn't yet, and the order the rest gets built in. What it prevents costs considerably more, because the alternative isn't catching the mismatch in review. It's a reader finding it after launch, on a page that's already live, which is a worse place to learn your company sounds like two different businesses.

Who builds in that order

Fluxion Tech is a Thailand-Myanmar software company that needed its full content presence built from zero: a public website, a Facebook strategy for organic growth, blog articles for topical authority, and terms and conditions, all facing a live audience before any of it was finished. That's the situation where skipping the order question is most tempting, because there's pressure to get everything moving at once. The build went in a specific sequence instead. Website copy came first, because that's where the voice gets established, and a company's voice can't be referenced by anything until it exists somewhere. The blog came second, once there was a voice to write from, so articles could build on that established tone rather than inventing their own. Terms and conditions came last, written in plain language but matched to the register everything else had already set, rather than defaulting to boilerplate legalese that would have sounded like a different company. The same logic carried into the Facebook strategy, which had to serve both the Thai and Myanmar markets without collapsing into one generic voice for both, since what reads as credible authority in one market can read as generic in the other. That decision, too, had to happen before content went out, not after a page had already published something that missed the register for one side of the audience. The reasoning is stated plainly on the project itself: doing it in the wrong sequence means rewriting things twice. That cost is specific, not vague, because a page written against a voice that didn't exist yet has to be redone once the real voice shows up, and by then the page is live, with an audience already reading it.

Your turn

This takes about fifteen minutes and a blank page, before any brief goes out. List every piece of content the project needs, however many there are: pages, posts, one legal document, a set of social captions, whatever the scope actually includes. For each one, write down what it references or has to match: a voice, a claim, a term, a design decision, anything made somewhere else in the project that this piece depends on. Some pieces will reference nothing yet, which makes them safe to write first. Others will reference things that don't exist yet, which tells you they have to wait. That list is the write order. It has nothing to do with which deadline looks most urgent and everything to do with which piece can be written without guessing at something that hasn't been decided yet. Hand that order to whoever's assigning the work before a single brief goes out, not after the first mismatch turns up in review. If two pieces on the list depend on each other in both directions, that's a sign the brief is missing a decision neither piece should be making on its own, and it needs to get made before either one gets written.