Configurable document templates without custom code

Ask any software vendor serving manufacturers and they will tell you: the most common customization request is about documents. "Can the spec sheet have our layout?" "Can we add a section here?" "Can it use our wording?" The tempting but wrong answer is to build a custom document for each client — a path to unmaintainable per-client code. The right answer is one configurable template engine that each tenant shapes themselves. Here is why that approach wins.

Most 'custom' is really configuration

When you look closely at document customization requests, the vast majority are about presentation, not logic: the layout, which sections appear, the wording of fixed text, the branding, the language. They are not asking the document to calculate something new — they are asking it to be arranged and styled their way. That is configuration, not custom development.

Recognising this is the key insight. If most requests are configuration, then a configurable engine — where the tenant adjusts layout, sections, text, and branding — answers them without any code being written per client.

The danger of per-client documents

Building a bespoke document for each client who asks seems responsive, but it is a trap. Every custom document is code to maintain, test, and update forever. As clients accumulate, you drown in per-client variants, each a maintenance burden, each a place for bugs. The product fragments into a hundred special cases, and changes that should be simple become a nightmare of updating every variant.

This is why disciplined software resists per-client code. The cost is not the first custom document — it is the hundredth, and the tangle they create together.

One engine, tenant-configured content

The sustainable approach is a single document engine whose content the tenant configures. The engine knows how to generate documents from the formula; the tenant sets their layout, chooses which sections to include, provides their text and branding, and selects languages. The same engine serves every tenant, each producing documents shaped their way — because the variation is configuration the tenant controls, not code the vendor writes.

This gives tenants the customization they actually want while keeping one maintainable engine behind it. A change or fix to the engine benefits everyone; no per-client variants to update.

When something truly is custom

Occasionally a request genuinely needs new behaviour, not just configuration. The disciplined response there is also clear: if one client asks, configure around it; if several ask, it becomes a product feature for everyone; only a unique, paid enterprise need is isolated behind a flag. Custom code is the rare exception, gated deliberately — not the default response to every document request.

This discipline keeps the product coherent: customization via configuration and flags, never a sprawl of per-client code.

Why tenants still get what they want

The worry with "no custom code" is that tenants won't get their customization. But because most requests are configuration, a well-built configurable engine delivers what they actually want — their layout, sections, text, branding, languages — without code. Tenants get documents that look and read like theirs; the vendor keeps one maintainable system. Both sides win, which is exactly why this approach is the right one.

Because document requirements differ by market and use, confirm the requirements for your specific situation rather than relying on a general summary.

Where Lemoniq fits

Lemoniq uses one configurable document engine: each tenant shapes their documents — layout, sections, text, branding, language — through configuration, not per-client code. The engine generates from the formula; the tenant controls the presentation. Genuine new behaviour is handled by the discipline of configure-first, productize-if-common, flag-if-uniquely-enterprise. Tenants get documents that look like theirs, on one maintainable engine — the customization they want without the per-client code trap.

The takeaway

Most document customization requests are configuration — layout, sections, text, branding — not new logic, so a configurable template engine answers them without per-client code. Building bespoke documents per client is a maintenance trap; one engine the tenant configures gives them what they want while staying maintainable. Customization via configuration, with custom code a rare, gated exception, is what keeps a document system both flexible and sane.

Lemoniq lets each tenant configure their documents — layout, sections, text, branding — on one engine, without per-client code. We solve this exact problem. See how it works