From Project Feature to Reusable Package – Building My Dynamic Theme Kit

One of my recent goals has been making my code more reusable instead of rewriting the same solutions for every project.

A good example of that is my Dynamic Theme Kit (DTK).

Originally, the theming system lived inside another project. It worked well there, but it was tightly coupled to that application. Every time I wanted dynamic themes elsewhere, I'd have to copy chunks of code and untangle the project-specific parts.

I decided it deserved to become its own standalone package.

Step 1 – Extracting it

The first challenge wasn't writing new code—it was separating reusable logic from application logic.

That meant identifying everything that was genuinely part of the theme engine and leaving behind anything that only made sense for the original project.

After several rounds of refactoring, I ended up with a kit that simply generates theme variables.

It doesn't try to style an application.

Instead, it exposes CSS variables that any project can consume however it likes.

That separation of responsibilities made the whole thing much cleaner.

Step 2 – Making it reusable

Once extracted, the next job was making sure it wasn't secretly relying on assumptions from the original project.

I wanted the setup to be as lightweight as possible.

The aim was that integrating DTK should only require importing its CSS and JavaScript, with projects remaining responsible for their own styling.

That also meant documenting edge cases, improving the configuration format, and making the package flexible enough to support completely different visual identities.

Step 3 – Trialling it

Before putting it into my main business website, I wanted proof that it actually worked outside its original environment.

So I integrated it into a few smaller personal projects first.

Each project exposed little assumptions I'd accidentally left behind.

Sometimes a CSS variable needed to be more generic.

Sometimes a default value made sense in one project but not another.

Sometimes I realised the documentation needed improving because I forgot how something worked after a few days.

Those small projects ended up becoming excellent test beds.

Step 4 – Integrating it into Web Weavers World

Once I was confident the kit was genuinely reusable, I integrated it into my business website, Web Weavers World.

This was the real test.

Unlike the trial projects, this site represents my business, so I wanted the integration to be clean rather than just "working."

Seeing the entire site switch themes from the standalone kit was a really satisfying moment.

Even better, adding future themes has become incredibly straightforward.

Instead of modifying application code, I simply add another palette to the configuration and DTK handles the rest.

Lessons learned

Extracting a feature into a reusable package is much harder than writing it for a single project.

The code usually isn't the difficult part.

The difficult part is removing assumptions.

Questions like:

• Is this variable really generic?


• Does this belong in the package or in the application?


• Am I solving a reusable problem or a project-specific one?

Answering those forced me to simplify the design considerably.

The result is a package that's cleaner, easier to maintain, and far more reusable than the original implementation.

I'm also finding myself thinking differently now.

Rather than asking:

"How do I build this feature?"

I'm increasingly asking:

"Could this become something I can reuse in every future project?"

That mindset shift has probably been the biggest win from the whole exercise.

Sometimes the best refactor isn't making code shorter—it's making it useful more than once.