Landing page brief template

Updated 6 September 2026 · reading time about 9 minutes

The template is at the bottom of this page and you can jump straight to it. What sits above it is what each field is for, because a brief that gets filled in without knowing that produces a page that is technically what you asked for and useless to you. A build rarely goes wrong on the code. It goes wrong because the brief described a mood instead of a sequence, because the offer changed twice while the work was in progress, and because somebody was handed the store password on the first day.

When to hand the build over

Outsource when the structure is decided: you know what the page is for, which sections it needs, and what each section has to prove. At that point the constraint is craft — restyling to a brand, a section your theme does not offer, a layout that survives a small screen — and craft is what a builder sells.

Do it yourself when the offer is still moving. While the bundle, the guarantee, and the main claim are changing week to week, a paid build buys you the same page three times.

The do-it-yourself case is stronger than it first sounds. A rough page you assembled yourself in the theme editor is a working argument you can rewrite on a Tuesday afternoon, and rewriting it is how you learn which sections carry weight. Once you have moved the reviews above the FAQ twice and deleted a section nobody scrolled to, you have written most of the brief without noticing. Hand that over and you are buying execution. Hand over an undecided page and you are buying guesses, then paying to correct them.

Scope by naming the sections in order

The most valuable line in a page brief is the section list, in sequence.

Compare two versions of the same order. "Hero with one claim and one button, then a three-icon proof row, then reviews, then FAQ, then a sticky add-to-cart on mobile" gets built once. "Modern and clean, something that feels premium" gets rebuilt until the revision rounds run out.

The reason is mechanical rather than moral. Adjectives transfer no decisions. Every decision your brief does not make gets made by the builder instead — reasonably, quickly, and in whichever direction is fastest to build, because they have no way of knowing which direction sells. That is not carelessness on their part. It is what anyone does with an under-specified instruction.

So attach a decision to each section rather than a description. The hero carries the claim. The proof row carries the reason to believe it. The reviews carry the objection you cannot answer in your own voice. The FAQ carries the questions that otherwise become emails. A section that carries nothing should not be on the page, and naming its job is how you find that out before it is built.

Two items belong in the list as explicitly as the sections do: what must appear before the first scroll on a phone, and what must not appear on the page at all.

The words themselves are a separate job. A builder placing copy is not a copywriter writing it, and the difference decides whether your page arrives full of your bullet points or full of the theme's demo text. If the words do not exist yet, write them first: briefing product page copy.

Where to look: website development listings.

Store access is the risk step

Everything else on this page is about quality. This part is about control. When a seller asks for your login the instinct is to send it, because the work cannot start otherwise. It can start without it, and the arrangement below is the one to propose before you are asked.

Never share your account password. Create a staff account with the narrowest set of permissions that lets the work happen, invite the seller through your platform's own invitation flow instead of sending credentials, ask for the work to be done on a duplicated theme rather than the live one, and remove the access the day the job closes. An invitation can be withdrawn in a single action and leaves a record of who changed what. A shared password can only be withdrawn by changing it, along with everything else that password happens to open.

Narrow permissions means exactly that: theme editing yes; orders, customer records, payouts, and account settings no, unless the task genuinely needs them. Ask the seller which permissions they need and why, grant those, and add more only when something is actually blocked. Permission names and groupings differ between platforms and change over time, so read the current list in your own admin rather than copying a list from a guide, including this one. Keep two-factor authentication on the owner account while you are in there.

A seller who will not work inside a staff account on a duplicated theme has told you something useful about how they work, before any money moves. Reading that kind of signal: vetting a seller in any category.

Apps, page builders, and pages you rent

Ask three questions before ordering, not after delivery. Which paid apps, page builders, or plugins will this page depend on? Whose account is each of them billed to? And what does the page degrade into if that subscription lapses?

The third question is the one people skip, and it has very different answers. Some sections fail politely: a slider stops sliding and the images stack. Some fail loudly: the section vanishes and drags the layout with it, or the page renders a block of the builder's raw markup where a testimonial used to be.

A page that dies with an unpaid app is a page rented, not owned. Renting can be a fair trade — some sections are not worth building from scratch — but it should be a decision you made deliberately, not one you discover in a renewal notice.

If the build happens inside a page builder, ask whether you can still edit those sections yourself afterwards and what remains if you ever move off the builder. If any app is billed to the seller's account, move it to yours before handover; an app on someone else's account is access you cannot revoke and a bill you cannot see.

Then ask for a written list of everything installed, added, or edited: apps, snippets, template files, theme settings. It takes the seller a couple of minutes at the end of the job and it is the only document that makes the page maintainable by whoever touches it next, including you in six months.

Mobile is the target, not the last check

Write the brief as though the phone is the only screen and the desktop layout is the adaptation. If your traffic arrives from a feed, it arrives on a phone, because the ad was served inside an app somebody was holding. Look at your own analytics for the actual split rather than trusting a rule of thumb.

The practical instruction is one line in the brief: the work is reviewed on a real device at a small viewport before it is approved, not in a desktop browser dragged narrow. A resized desktop window shows you reflow. It does not show you the on-screen keyboard covering the field somebody is typing into, a sticky bar parked over the button it hides, tap targets too close together for a thumb, hover states that never fire on touch, a video that quietly refuses to autoplay, or how the page behaves on a mobile connection rather than your office wifi.

Name the device class and browser you expect it checked on, and ask which device the seller tested. "Tested on mobile" is not a claim you can verify. "Tested on this handset, in this browser" is.

Where image and video dimensions matter, confirm the current requirement in your platform's own documentation and write the numbers into the brief. Specifications change; "high resolution" transfers nothing.

Performance is a requirement you state, not a hope

No build gets lighter because the brief said "make it fast". Three moves make performance a scope item instead of a wish.

Name the templates that matter. Usually that is the page traffic lands on and the page where money changes hands. Speed work spread evenly across a whole store is speed work spread thin, and a builder given no priority will optimise whatever they happened to open first.

Ask the builder to disclose what the build adds to page weight: scripts, fonts, sliders, embedded video, app embeds, and anything loaded from a third-party domain. Disclosed before you order, that is a scope decision you can accept or trade away. Discovered after handover, it is an argument.

Then check the result yourself, on the templates you named, before and after, using the same tool both times and a mobile connection setting. Do not accept a screenshot of a score as evidence of anything, and do not chase a number you have not defined — decide what you are measuring and check your platform's current guidance on what it recommends watching, because the recommended measures move.

Weight is sometimes worth carrying. A video hero can earn its place. The point is that you chose it with the weight in front of you.

Where the scope ends, and who owns the page afterwards

Trouble after a page build tends not to be about the quality of the work. It is about a work item both sides assumed the other had. The rows below sit at the edge of a typical order. Go through them with the seller before ordering and put the answers in the order description, not in a chat thread that scrolls away.

Work that sits at the edge of a typical page-build order
Work item	Confirm before ordering	If you assume wrongly
Copy	Whether the seller writes the words or places words you supply.	The page arrives holding the theme's demo text, and the launch waits on a second order.
Images	Who crops, compresses, and exports at the sizes the layout needs, and whether retouching is included at all.	Your files get stretched into slots they do not fit, and the fix consumes the revision rounds.
App configuration	Whether installing and configuring any app the build relies on is in scope, and on whose account.	The page looks finished and one section is inert, because the app behind it was never connected.
Analytics and tracking setup	Whether events, consent handling, and conversion tracking are part of this order or a separate task.	The page runs, nobody can tell whether it worked, and the first optimisation decision is made blind.
Theme updates after handover	Who adjusts the customisation when the theme itself is updated, for how long, and at what point that ends.	An update lands, a section breaks, and neither side believes the repair is theirs.
Publishing to live	Who publishes, and that publishing happens only after your written acceptance.	A half-reviewed page goes live in front of traffic you are already paying to send.
Ongoing maintenance	Whether anything after handover is included. Say it plainly in both directions.	You treat the seller as support they never agreed to be, and the goodwill you will want later is spent.

Done means reviewed on the duplicated theme against the brief, and then published — in that order. Publishing before acceptance gives away the only leverage you have and puts an unreviewed page in front of live visitors.

Name the handover boundary before it matters. Themes get updated, platforms change, and a customisation that works today can break when the theme's own update lands months later. That is the moment relationships sour: you see a broken page you paid for, the seller sees a request to work again for nothing on a job that closed long ago. Neither reading is unreasonable, which is precisely why it has to be settled in writing before the order — who repairs it, within what window, and what counts as a repair rather than a new job.

A page that passes your own review still benefits from a pass by somebody who did not build it, on a store you have stopped changing: commissioning pre-launch store QA.

The template

Copy this, fill it in, and send it. Every blank corresponds to something above; a field left empty is a decision the builder makes for you.

Brief

THE PAGE
Its single job, stated as the one action a visitor should take:
Traffic source it receives (paid social, search, email, QR, other):
What the visitor already believes when they arrive:
What this page replaces, if anything (URL or template):

SECTIONS, IN ORDER (the order is the specification)
1. Section:                    Decision it carries:
2. Section:                    Decision it carries:
3. Section:                    Decision it carries:
4. Section:                    Decision it carries:
5. Section:                    Decision it carries:
Must appear before the first scroll on a phone:
Must not appear on this page at all:

MOBILE
Reviewed on a real phone at a small viewport before approval: yes
Device and browser the seller tested on (name them):
Sticky element required on mobile (add-to-cart, call, none):
Forms usable one-handed, with the keyboard open:
Image and video sizes, in numbers confirmed on my platform:

ASSETS
I am supplying (list the files and where they live):
Expected from the seller (name each, or it will not arrive):
Placeholder or demo text in the delivered page: not acceptable

APPS AND DEPENDENCIES
Paid apps, page builders, or plugins this build may rely on:
Whose account each one is billed to:
What the page degrades into if that subscription lapses:
Sections stay editable by me in the theme editor: yes / no
Written list of everything installed, added, or edited: required

THEME AND ACCESS
Work happens on a duplicated theme, never the live one:
Staff account with the narrowest permissions that allows the work:
Account password is not shared; access is removed when the job closes:
Publishing to live is done by: me / the seller, after acceptance

PERFORMANCE
Templates whose page weight matters (name them):
Seller discloses added scripts, fonts, embeds, third-party requests:
I measure before and after myself, on the templates named above:

ACCEPTANCE AND HANDOVER
Done means: sections in the stated order, reviewed on a real phone,
  no placeholder text, forms and buttons route somewhere, and no
  subscription introduced that I did not agree to
Who repairs the customisation if a later theme update breaks it:
How long that stands, and what counts as a repair versus a new job:

DELIVERABLE
Form: the duplicated theme with the work applied, plus the written
  list of what was installed, added, or edited
Revisions included, and what counts as a revision:
Turnaround, and whether a rush fee applies:

Check on delivery

The sections are in the order you named. Read your own brief beside the page rather than judging the page on its own. A good page in a different order is a different page, and saying so before acceptance is a revision; saying so afterwards is a new order.
It works on a real phone. Not a narrowed desktop window. Open it on a handset over mobile data, scroll the whole page, and put a thumb on every button.
No placeholder text survives. Search the page for lorem, for the theme's demo strings, and for your own bracketed notes. Filler in a footer or an FAQ answer is the one that ships.
Forms and buttons actually go somewhere. Submit the form and confirm the record arrives where you expect and that any confirmation message or email fires. Click every button, including those in sections you skimmed.
Nothing was added that needs a subscription you did not agree to. Compare the installed app list against the list in your brief, and ask which of them the page stops working without.
The written list of changes is there. Apps installed, snippets added, files edited, settings changed. Without it, the next person in the theme is guessing, and that person is usually you.
Access is revoked once the work is accepted. Remove the staff account on the day the job closes, not the day you remember it exists.

Where to look: website development listings. Related: the 7-task launch outsourcing checklist.

One idea worth keeping: the brief is the sequence, and the sequence is a set of decisions made before anyone opens your theme. A good builder will execute better than you can. Nobody else can decide what the page has to prove, and every decision you leave blank will be filled in by whoever is fastest.