Blog › Build Story · Technical
The shortcut was tempting.
It was also wrong for this job.
Wrapping an LLM around a document rebrand is the fast way to a demo. Here's why it fails a real batch, and why deterministic, rule-based code was the only honest choice for this job.
1
rule, applied identically every run
0
words of your content rewritten
0
documents sent through a third-party model
11 min
to rebrand 550 templates, same result every time
The tempting shortcut: just wrap an LLM around the problem
Every document sits inside an XML structure. Ask an AI model to describe what needs to change, feed it the document text, and let it generate a rebranded version. It's fast to prototype, it demos beautifully on a single tidy file, and it's the obvious first instinct for anyone who's spent the last few years reaching for a language model whenever text is involved.
I considered it seriously, because it would have been the quicker build. It just doesn't survive contact with a real batch of real documents.
Why that shortcut fails this specific job
Two reasons, and neither of them is about being clever with a model.
Consistency
A model can produce a slightly different rewrite on the same input twice. A rebrand needs the same colour, font and logo applied identically on page 1 and page 400 - no drift, no "close enough."
Confidentiality
Policies, contracts and internal templates are exactly the kind of content organisations don't want passed through a third-party model just to change a logo.
A rebrand isn't a creative task. It's a mechanical one: this colour becomes that colour, this logo becomes that logo, on every page, without touching the words in between. An AI wrapper treats that mechanical job as a generation problem, which means it can quietly introduce the two things a rebrand can least afford - inconsistency across a large batch, and content leaving your control that never needed to.
What "deterministic" actually buys you: same input, same output, every time
Deterministic code doesn't guess. It reads a document's actual structure - the XML parts that define headers, footers, tables and body text - and applies a fixed set of rules: replace this colour value, swap this logo, apply this font. Run it once or run it a thousand times on the same file, and you get the identical result every time. That predictability is the entire point of the product, not a side benefit.
If the transformation is deterministic, it doesn't belong behind an AI model.
What this means for you as a buyer, not just as an engineering choice
Because rebranding is a rule-based transformation rather than an AI-generated one, there's no per-page AI fee to pass on to you, and no step where your document's wording is sent to a language model to be rewritten. Your content goes in, your content comes back with a new brand applied, and nothing about the words themselves ever passed through a generative model. That's a buyer-facing consequence of the architecture, not a pricing strategy.
Where AI genuinely earned its place in the build (not the runtime)
None of this makes AI the wrong tool everywhere. It earned a real place in how BrandSwitch got built - speeding up development, catching edge cases, iterating on the rule-based engine itself. The distinction I keep drawing is between the build process and the runtime. AI helped build the tool. It's not what runs when your document gets rebranded.
The rule I now apply before reaching for AI on any feature
Before adding AI to any part of a product, I ask one question: should the same input always produce the same output here? If the answer is yes, it's a deterministic problem, and it belongs in rule-based code, not behind a model. If the answer is genuinely no - if the task needs judgement, interpretation or generation - that's where AI actually fits. Rebranding a document is squarely the first kind of problem, and treating it that way is what makes the result trustworthy at scale.
Quick answers
Why not just use an AI model to rebrand documents?
Because an AI model reads and rewrites content, and that introduces variation. Deterministic, rule-based code reads a document's structure and applies fixed rules, so the same input always produces the same output - no rewritten wording, no drift between runs.
Does BrandSwitch send my documents to a third-party AI model?
No. The document engine is deterministic. It reads structure - colours, fonts, headers, footers, tables, logos - and applies your brand directly. Your document content is never sent through a language model to get rebranded.
Are there per-page AI fees for using BrandSwitch?
No. Because rebranding is a rule-based transformation rather than an AI-generated one, there's nothing metered per page or per document to pass on to you as a fee.
Did AI play any role in building BrandSwitch?
Yes, AI helped build the tool. It's not what runs it. That distinction between the build process and the runtime is the whole point of this post.
Where this plays out in the product
BrandSwitch is the deterministic engine this post argues for, not just describes. Upload your documents, set your brand once, and get a consistent result across the whole batch, with nothing sent through a third-party model to get there.
Read how this plays out in the product
Deterministic rebranding, consistent results, nothing sent through a third-party model.