Building Kamiliyon: My Journey From Design to a Live Tool

When I'm designing a website, choosing colors is usually the easy part. Figuring out how those colors will actually look on the website is where things get interesting.

I'd find myself going through different color palette websites, saving combinations that looked promising, then trying to imagine how they would work across the interface I was designing. Would that blue work for the buttons? Would the background feel too dark? Would the text still be readable? Would the whole thing look as good in a real interface as it did in the palette preview?

I was doing a lot of imagining when what I really wanted was to see the colors in action.

That frustration led me to build Kamiliyon — then called Colors by Max — a live website theme switcher that lets you explore color themes directly on a website rather than relying on your imagination.

What started as a small feature inside a website project eventually became its own product. Along the way, it grew into something much more ambitious than the original idea.

Here's how it happened.

It started with a problem I kept running into

The idea behind Kamiliyon didn't begin with a grand plan to build a design tool. It came from a problem I kept encountering while designing websites.

I'd visit different color palette websites, find combinations I liked, and then try to picture how those colors would translate to the actual interface. The palette might look great on its own, but a website has so many different elements that it's difficult to know whether the combination will work everywhere.

A color that looks perfect in a swatch might feel completely different when used on a navigation bar. A background that looks good in isolation might make the text difficult to read. A vibrant accent might work well on a button but become overwhelming when applied across an entire page.

I wanted a faster way to experiment.

Instead of switching between websites, copying color codes, changing styles, and repeating the process every time I found a new palette, I wanted to try different themes directly on the website I was designing.

That was the problem I wanted to solve.

From a small feature to its own product

My first step was to build a small theme switcher inside another website project I was working on.

The idea was simple: let me apply different color palettes to a real interface and see what happened.

It worked well enough that I could experiment with color combinations without having to rely entirely on my imagination. I could see the changes on the actual page and make decisions based on what I was looking at.

That was when I started thinking about the idea beyond the original website.

If this made color exploration easier for me, perhaps it could be useful to other designers and developers too.

On 24 September 2026, I extracted the theme switcher and turned it into a standalone project. I called it Colors by Max.

Looking back, the important step wasn't simply creating another tool. It was recognizing that a solution to a practical design problem could become something other people might find useful.

I wanted to take the idea further and see what it could become.

Making the whole website change with one click

Kamiliyon is built with React and Tailwind CSS. One of the key decisions behind it is how the website's colors are organized.

Instead of treating every color as an unrelated value, the system uses 35 named color roles. These cover different parts of an interface, including brand colors, backgrounds, text, cards, and other elements.

This structure makes it possible to change a theme by swapping the colors assigned to those roles. The page can then update across the interface without requiring each element to be recolored individually.

Think about what happens when you change the background color of a website. That decision can affect cards, navigation, text, borders, and other components. If you're exploring a completely different visual direction, you need a way to coordinate those changes.

The theme system provides that structure.

The first version included a floating color button, a panel of preset themes, and contrast checks. I also added a feature called Scan Site, which reads the colors already being used on a website and suggests themes based on them.

That feature was particularly useful because it gave users another way to approach color exploration. Rather than starting with an unfamiliar palette, they could explore options inspired by colors already present on the page, or by one of the 700+ themes the library carries across 14 categories.

It was a practical starting point, but I could see opportunities to do much more.

Taking it beyond a single website

The day after I separated it into its own project, I published it on npm as colorsbymax. It goes by kamiliyon now, but that renaming came much later.

I also worked on making setup straightforward with a one-line installation approach and expanded the tool so it could work on different websites, including those with hard-coded colors.

That introduced a different challenge from changing colors inside a project I controlled.

Every website is built differently. Some use organized design tokens or CSS variables, while others have colors defined directly in their styles. A theme switcher intended for wider use couldn't assume every website followed the same structure.

I extended Kamiliyon to read the colors actually being used on a page and swap them as part of the theming process. The goal was to make the tool useful beyond a single project or a particular implementation.

This was an important shift in direction. I wasn't just building something for my own workflow anymore. I was working towards a tool that other people could integrate into their websites.

That meant thinking about the variety of websites it might encounter, rather than focusing only on the environment where the idea began.

The challenge of making colors work in the real world

One of the hardest parts of building Kamiliyon was making themes look good across different websites while keeping every piece of text readable.

A palette can look beautiful in a preview and still fall apart when applied to a real page.

White text might end up on a light background. A red delete button might lose its distinctive color and become the same as the brand color. An icon might disappear against the bar it's supposed to sit on.

These aren't just aesthetic issues. They can affect whether people understand what they're looking at and whether they can use the interface properly.

I experienced this firsthand while developing the Colorful style. At one point, it was changing my own website's design so aggressively that some headings and icons became invisible.

That was a clear sign that simply applying a set of colors wasn't enough.

I had to step back and address the problem at its root instead of patching individual screens whenever something went wrong.

Kamiliyon now includes a contrast guard that checks text and icons against the backgrounds they actually sit on. It helps correct combinations that are difficult to read while preserving their intended colors as much as possible.

The distinction matters. The aim isn't to make every website look the same or remove all personality from a theme. It's to allow color experimentation without making the interface harder to use.

A theme should change the way a website looks, not make its content disappear.

That became one of the most important considerations in the product's development.

Letting the product grow through real use

Once the core theme switcher was working, I continued expanding it.

I added light and dark modes for every theme, along with an audit feature that identifies elements that may not look right after a theme is applied. I also introduced a way for AI coding tools to use Kamiliyon.

Then came Studio, which lets users color a website part by part rather than treating the entire page as one uniform surface.

I introduced three color styles: Subtle, Balanced, and Colorful. These give users different ways to approach a theme depending on how restrained or expressive they want the result to be.

Other additions included a color picker that builds themes from a color already on the website and a notification bell that tells users when an update is available.

I built Kamiliyon with Claude Code as my coding partner, and feedback from people using the tool played a significant role in its development.

Some improvements came directly from the issues people reported and the suggestions they sent. That feedback helped me see problems I might not have encountered while testing the tool on my own.

There is a difference between building something that works on your screen and building something that works well for other people.

When other people start using a product, they bring different websites, expectations, and ways of working. They encounter problems you might never have noticed yourself.

That is valuable information, and it has helped shape how Kamiliyon has evolved.

The feedback that reminded me why I built it

One of the most satisfying moments came when someone using Kamiliyon sent me a detailed bug report.

Alongside the report, they mentioned that the contrast check had caught two real problems in their own color choices that they had missed. One of those issues involved the main button used across nearly every screen of their product.

That feedback meant a lot to me because it connected the tool back to the original reason I started building it.

I wanted an easier way to explore colors on a real website. But the product had also grown into something that could help people identify problems in their interfaces that weren't immediately obvious.

The contrast check wasn't just a feature sitting in a panel. It had helped someone catch actual readability issues in their work.

That is the kind of outcome I want to see from the tools I build.

It's easy to get caught up in the technical side of development, adding features, improving the interface, and fixing bugs. But hearing that something you've made has helped another person solve a problem gives those efforts a more tangible purpose.

It reminded me that the value of a design tool isn't measured only by how clever its implementation is. It's also measured by what people can do with it.

What Kamiliyon represents for Mr Max Designs

For me, Kamiliyon is an example of how a problem encountered during design can become the starting point for a useful digital product.

It began with a personal frustration, became a small feature inside a website project, and grew into an independent tool with theme switching, accessibility checks, multiple color styles, and support for different websites.

The project also reflects the kind of work I want to continue doing through Mr Max Designs: bringing together visual design, user experience, and development to create things that people can actually use.

I enjoy taking an idea beyond a static design and working through what it takes to make that idea functional. That includes the visual decisions, but also the technical challenges, the edge cases, and the improvements that come from seeing how a product behaves in practice.

Kamiliyon has given me a place to explore all of those things in one project.

It has also reinforced something important about product development: you don't always need to begin with a complete vision of the final product. Sometimes, solving one real problem is enough to get started. The next steps become clearer as you build, test, and listen to the people using what you've made.

Try Kamiliyon

Kamiliyon is live and available to explore.

If you're a designer who wants to experiment with website themes, a developer looking for a way to preview different color directions, or someone interested in making an existing interface easier to work with, you can see the tool in action here:

Explore Kamiliyon →

For businesses looking to build or improve a digital product, this project is also a glimpse into how I approach design: starting with a practical problem, exploring possible solutions, and working towards an experience that balances visual quality with usability.

I'm continuing to develop Kamiliyon, and feedback from people using it remains an important part of that process.

What began as a way to stop imagining how colors might look has become a tool for trying them on real websites.

And that, ultimately, was the idea.