Rebranding a Template From One Config File

One file, not one rebuild

The whole point of banking a template is wasted if rebranding it still means opening every page and swapping colors and copy by hand. Rippr does not work that way. A branded site comes from one file, brand.md, and everything downstream reads from it.

That is the actual design goal I set for the tool: rip a beautiful site once, bank it as a named template, then spin up N branded sites from one brand file across Next.js, static HTML, and WordPress. Not N rebuilds. N outputs from one input.

What "brand.json-driven" means in practice

The proof template, aurora-ai-saas, is built exactly this way. Every visual decision in that Next.js build, the dark theme, the framer-motion animation choices, the layout, pulls from a brand.json file instead of being hardcoded into the components. Change the file, and the same template produces a different brand without anyone touching the underlying design code.

That separation is what makes the faithful-and-rebrandable rule actually possible at scale. If the brand data lived inside the components, every rebrand would mean editing code, which means every rebrand risks breaking the design that made the template worth banking in the first place. Keeping the brand data outside the design means the design stays untouched no matter how many times it gets reused.

The engine behind the one file

A single config file does not do anything on its own. It needs a pipeline that reads it and produces real output, and that pipeline is a real, dated, registered build: rippr-engine, a site generation engine whose entire job is outputting client websites from templates.

The engine is not a black box. It is a set of real scripts sitting in the project's own engine folder: compile-brand.mjs turns the brand file into a structured object the renderers can use, fetch-gbp.mjs pulls in real Google Business Profile data where it applies, enrich-brand.mjs fills out the brand object further, and batch-build.mjs is what lets a single run produce more than one branded site at once instead of one at a time. Sitting alongside those is a renderers/ folder, one renderer per output stack, and a registry.json that tracks what has been built.

Rebranding is not the same job as starting a site

There is a second, separate layer to this system worth being precise about: project starters. templates/project-starters/_base and templates/project-starters/seo-project are not banked design clones, they are generic scaffolds for starting a new project from nothing. Rebranding a banked template and scaffolding a brand-new project from a starter solve two different problems. A starter gives you a blank, correctly wired foundation. A rebrand gives you a proven, premium design wearing a new brand's colors and copy. Confusing the two means either rebuilding design work that already exists, or trying to force a generic starter to look premium without the clone work behind it.

Why one config file is the whole strategy

Every extra place a rebrand touches is a place it can go wrong or get expensive. A brand color hardcoded into three different component files means three edits, three chances to miss one, and three places that can drift out of sync the next time someone updates the design. A brand color that lives once, in one file, means one edit, checked once, applied everywhere the engine renders from it.

That is why the config file is not a convenience feature bolted onto Rippr, it is the actual mechanism that makes the tool a factory instead of a folder of one-off client builds. Bank the design once under the faithful-and-rebrandable rule. Drive every future brand off one file. Let the engine do the repetitive work of turning that one file into a Next.js site, a static HTML site, and a WordPress theme, all wearing the same premium design and none of them touching the code that makes it premium.