One of my recent goals has been making my code more reusable instead of solving the same problem in every project.
A good example of that is my Dynamic Theme Kit (DTK).
DTK didn't begin life as a package.
It started as the theming engine inside my One Piece Tracker project.
As that project grew, so did the theme system. It eventually reached the point where I realised I wasn't building a theme engine for one application anymore—I was building something that could be useful everywhere.
Instead of copying pieces of code into future projects, I decided it was time to extract it into its own standalone package.
Step 1 – Extracting it
At first I thought this would mostly be moving files around.
It wasn't.
The real challenge wasn't writing new code—it was separating reusable logic from application-specific logic.
That meant identifying everything that genuinely belonged to the theme engine and leaving behind everything that only existed because One Piece Tracker happened to need it.
After several rounds of refactoring, I ended up with a package whose only responsibility is generating theme variables.
It doesn't try to style an application.
It simply exposes CSS variables that each project can consume however it wants.
That separation of responsibilities immediately made the whole design cleaner.
Step 2 – Making it genuinely reusable
Extracting the code wasn't enough.
The next challenge was proving it wasn't secretly relying on assumptions from the original project.
I wanted integrating DTK to be as lightweight as possible.
Ideally, another project should only need to include the kit, provide a palette configuration, and continue styling itself normally.
That meant improving the documentation, simplifying the configuration, removing unnecessary coupling, and making sure DTK wasn't making decisions that belonged to the application itself.
Step 3 – Libraries expose your assumptions
The biggest surprise came once I started using DTK in other projects.
Every integration uncovered another assumption I'd accidentally baked into the original implementation.
One project still used an older CSS variable.
Another highlighted that gradient backgrounds needed different handling.
Another showed that parts of my documentation only made sense because I already knew how the original project worked.
None of those were bugs.
They were assumptions.
Every time I removed one, DTK became less like "theme code extracted from another project" and more like a toolkit that could genuinely stand on its own.
Those smaller projects became the perfect test environment.
Step 4 – Integrating it into Web Weavers World
Once I was confident DTK was genuinely reusable, I integrated it into my business website, Web Weavers World.
This felt like the real test.
Unlike my smaller experiments, this is the website that represents my work as a developer.
I didn't just want the themes to work—I wanted the integration to feel natural.
Seeing the site switch themes using a completely standalone package was a satisfying moment.
Even better, I realised future themes no longer require changes throughout the application.
Adding another theme is now largely a matter of adding another palette.
That's exactly what I'd hoped to achieve when I first started extracting the code.
Lessons learned
Extracting a feature into a reusable package is much harder than building it for a single application.
The difficult part isn't the code.
It's removing assumptions.
Questions like:
- Is this variable actually generic?
- Does this behaviour belong in the package or the application?
- Am I solving a reusable problem or a project-specific one?
became much more important than writing new functionality.
More importantly, the process has changed how I think about development.
Instead of asking:
"How do I build this feature?"
I increasingly find myself asking:
"Could this become something I can reuse in every future project?"
That small change in mindset has probably been the biggest benefit of building DTK.
Sometimes the best refactor isn't making code shorter.
It's making code useful more than once.
Top comments (2)
How did you handle theme customization across different projects while keeping the package reusable? I'm following your work for more insights on this, would love to hear about your approach.
Thanks for the follow! I really appreciate it. ☻
The main thing I did was separate the responsibilities. DTK is only responsible for generating and applying the theme variables—it doesn't style the application itself.
Each project maps its own
:rootvariables into DTK's variable map, so the application continues using its existing CSS variables while DTK simply provides the values.Testing it across a few smaller projects helped expose assumptions I'd accidentally made in the original implementation, which made the package much more reusable.