Brief from marketer to developer: must-have attachments

You sit between the client and the developer. The client has a date in mind. The design, the campaign, or the "small change" already lives in a chat. Then the first build arrives and the client says this is not what we sold. The developer can usually code. What they received was a thread: a goal in one message, a login in another, a screenshot with no note of which environment it came from. You look unreliable. The developer looks slow. The client looks at the date.

A brief a developer can build from is a short pack, not a longer chat. It names the outcome, the current system, what "done" looks like, and who owns the accounts. It does not try to specify every class name. Attach this pack before work starts, and keep the same shape when you hand the same client to a developer again next month. The point is a release the client can recognize, without a production surprise on the day you promised.

1. Where the surprise actually comes from

The surprise shows up in the review, not in the kickoff. The page exists. The campaign can point at it. The client still rejects it, because a step they care about was never written down: a payment state, a branch that must not see another branch, a form field the sales team swore was required.

You hold the client's intent. The developer holds the repository. Each side assumes the other filled the gap. Chat feels fast, so the gap stays in chat. A week later nobody can point at the message that decided the behaviour. Inherited projects fail in the same place. When a team takes over a product another team left in trouble, the first week is spent finding out what is actually running. A brief that never left one person's memory arrives in that same condition: the next person cannot tell which behaviour is intentional.

Write three lines before you add files:

• The client outcome in one sentence the client would sign: what they can do after this release that they cannot do now.
• The decisions already promised, including dates, and which of them are still negotiable.
• The person on your side who accepts the work, and the person on the client side who can answer a behaviour question the same day.

2. What to attach every time

A folder named "assets" and a sentence that says "make it like the design" is not a brief. The developer can open the folder. They still cannot tell which file is current, which screen is in scope, or what to do when the design and the live site disagree.

Attachments follow the tool you live in. A designer sends a file. A media buyer sends a landing URL. An account manager sends a password in a private message because that unblocked someone last time. None of those is a brief. The developer guesses the missing piece, and the guess becomes the thing the client did not buy.

Attach these, in this order:

• Current system: the live URL, the platform, and where the code lives. Name WordPress, Shopify, Magento, Laravel, or whatever is actually running. Do not write "the site".
• Scope in and scope out. The screens or flows that change, and one line on what this release will not touch.
• Acceptance: three to seven checks a non-developer can run. "A returning customer can pay" is a check. "Clean code" is not.
• The design or copy that is current, with a date. If two files exist, say which one wins.
• Constraints the client already set: languages, a date, a system that must keep working, data that must not move.
• Accounts to be granted, listed by system — repository, hosting, analytics, payments, mail — without the secrets in the document.

If the client runs an online store, name the platform it already uses and name the shopping step that must change. "Improve conversion" does not tell anyone whether the change is the catalog, the cart, or the return from payment. Adapting a store that is already live is a different job from inventing a new shop. The brief should say which one this is.

3. Write the behaviour, not the decoration

A brief that specifies colours and leaves the rule unstated will be tested on the rule. The client will try who can see a record, what happens when a payment fails, and what the report should contain after a call is scored.

Decoration is visible in a file. Behaviour shows up only when someone tries it. If you sell an integration — CRM, telephony, mail, accounting — the client will judge the result in the place they already work, not in the pull request. On one CRM, call scoring connected telephony, messaging and accounting, then showed the outcome in a report. A retry was not allowed to create a second score, and one branch could not read another's records. You do not need that stack in the brief. You need the equivalent sentences: which systems are in scope, what the person should see when processing finishes, and what must remain true if the job runs twice. "Add AI" is not one of those sentences.

For each flow in scope, write this:

• The happy path and one failure: payment declined, file missing, user has no access.
• If several customers share the product, who must not see whose data.
• If the work can run twice — a form submit, an import, a webhook — whether the second run should change anything.
• The screen where the client will look for the result. That screen is the demo.

4. Hand over access without handing over a secret in chat

A production password in a message is one failure. The other is a brief that says "we will send access later", and then later never comes. The developer either cannot start, or they start on the live site because it was the only place they could log in.

Access feels like a footnote to the creative work. It is the footnote that decides whether the first deploy is safe. A project that can be changed only on production will surprise the client, because the first real test is the release. The handover checklist is the longer version of this for an inherited Laravel application. For a marketing brief, the short version is enough: company-owned accounts, a separate environment, no customer dump in an unlocked test copy.

Before you promise a date, confirm:

• Repository, hosting and third-party access go through accounts your client or your agency controls. Production secrets do not travel by email or chat.
• Which environment the developer may use. If there is no second environment, say that as a risk before you promise a date.
• Real customer data stays out of an unsecured test environment. Ask for a reduced or anonymized copy.
• Which branch is deployed, recorded outside the brief's comment thread, once the first release exists.

5. Review against the checks you attached

A review that starts from taste will find the headline and miss the payment return. Taste is allowed. It is a bad way to discover that a step was never in scope. The acceptance lines from the brief are the review. Walk them with the client, on the environment you named, before anyone calls it done.

The date arrives, the client is in a meeting, and someone asks for "a quick look". A quick look finds the hero and misses the failure path. Then a customer finds the failure path. A written check takes the same ten minutes and gives you a list you can send back without a new argument about what was promised.

Use the list you already wrote:

• Run each acceptance line yourself before the client sees the build.
• Send the client that same list, not a new description of the work invented at the end.
• Park visual notes that are outside the list. They are a next brief, not a reason to call this one unfinished if the checks pass.
• If a check fails, name the line. "It feels off" is not a line the next build can satisfy.

A defined project needs a clear scope and an agreed delivery plan. Ongoing work needs the same pack at a smaller size each time you add a request: outcome, acceptance, what is out of scope. Either way, the developer should be able to tell you what they are not doing.

When to bring the developer in early

You can assemble this pack before a developer opens the repository. Bring them in before you promise the date when the change touches payments, a shared customer database, or a system you cannot describe, or when the current site was inherited and nobody has confirmed a second environment. A developer who sees the brief only after the client has been told "it is nearly done" inherits the surprise with you.

I take scoped work from marketers, designers and agencies, and the development that follows a written handover. Services cover a defined project or ongoing collaboration: performance, SaaS and backend systems, and AI integration. Selected work is the kind of system these briefs land on — an inherited product, an online store, a CRM that already has customers — each kept to the scope of that job. If you have a client release that needs a developer who will work from a written pack, message me on LinkedIn. Attach the outcome, the acceptance lines, and the platform name. Leave the passwords out.