Treating a brand as data, so a second client costs a config file

You build a production process for a client. It works well. Then a second client arrives and you start copying files, changing hardcoded values, and maintaining two nearly identical pipelines that drift apart within a month.

The cause is that the brand's specifics were written into the process rather than supplied to it. Palette, tone, product names, forbidden ground — all sitting inline, in the code, in the prompts, in the templates.

The fix is a separation that is obvious in software and rarely applied to creative work: the brand is data, the workflow is code. One changes per client; the other never does.

One file per brand, holding every fact the workflow needs:

name: Example
palette:
  primary: "#1B4332"
  neutral: "#EDE8E0"
tone:
  voice: calm, precise, no exclamation marks
  avoid: [luxury, premium, elevate]
products:
  - id: ex-014
    name: Linen Overshirt
    must_preserve: [button count, collar shape, seam colour]
guardrails:
  never: [visible logos of other brands, minors, alcohol]
  locations: [studio seamless, coastal exterior]
delivery:
  ratios: ["4:5", "9:16"]
  count_per_product: 3

The test for whether something belongs in this file: would it change if you swapped clients? If yes, it is data. If no, it is workflow.

The production process takes a brand identifier and reads everything else from the file. Prompt assembly, output paths, ratio settings, guardrail checks — all parameterised.

agency generate --brand example --product ex-014
agency generate --brand other   --product ot-002

The same command, the same code, different data. Adding a third brand is writing a third file, not extending the pipeline.

A useful discipline while building: grep your own codebase for the first client's name periodically. Every hit is a place where data leaked into code, and each one is a future maintenance problem.

Every brand has things that must not happen — categories they will not be shown near, claims they cannot make, imagery that conflicts with their positioning. These are usually communicated verbally, once, and then held in your memory.

Write them down as a field. Then have the workflow check against them before anything reaches a client.

This is worth more than any efficiency gain. An automated check that refuses to deliver an asset breaking a stated rule is the difference between a system you can run quickly and one you have to review anxiously.

When brand specifics live in your head, they drift. The palette is slightly off in week six, the tone loosens, a product detail gets remembered wrong. Nobody notices until the client does.

When they live in a file that the workflow reads, they cannot drift. Asset one and asset two hundred are generated from the same values.

This also makes the work transferable. Someone else — or an agent — can run the pipeline for a brand they know nothing about, because everything they need to know is written down. That is the point at which a personal process becomes an operation.

Take your existing process and pull every client-specific value out into a file, leaving placeholders behind. It is an afternoon and it does not change the output at all.

What changes is that the second client is now a file rather than a rebuild — and the second client always arrives sooner than you plan for.

The other benefit is immediate: writing the file forces you to state things you had been carrying implicitly, and the act of writing them down usually surfaces two or three you had been getting slightly wrong.