I moved PeşinTaksit to Cloudflare Workers in about an hour

PeşinTaksit was not broken. The site was live and doing its job. I still changed most of its architecture and deployed the new version to Cloudflare Workers.

The entire job, including the refactor and deployment, took about an hour.

The previous stack ran on Docker Swarm and included MariaDB, Redis, Nuxt, and Fastify. None of those technologies was inherently wrong. The problem was that the system demanded more operational attention than the product's current scale justified.

PeşinTaksit does not receive much traffic. My goal is not aggressive scaling; it is to keep a useful tool alive. Yet every separate service added maintenance and container management. The system worked, but the way I kept it running no longer matched what the product needed.

Working was not enough

An architecture does not need to fail before it becomes too complex. Sometimes the problem is the gap between the value it provides and the operational attention it demands.

I am not judging the original decisions with hindsight. Technology choices depend on context. The question in front of me was simpler: How many separate layers do I really need to operate for this product to continue?

The answer was fewer than I had.

What changed in an hour?

The data used by PeşinTaksit was a good fit for Cloudflare KV. AI removed the Redis and MariaDB layers the product no longer needed and adapted the data access code to work with KV. It also migrated the Fastify routes and services that depended on those layers to Nuxt server routes.

I reviewed the resulting code and did not find any significant issues. I then deployed the new version to Cloudflare Workers.

That speed alone does not prove the architecture is right. For me, its value was completing the change within the time I was willing to spend on a low-traffic product.

More than a refactor

Calling this only a refactor would be incomplete. I changed not just the internal structure of the code, but also the deployment model, storage mechanism, and service boundaries. Re-engineering is a better description of what happened.

I no longer need to operate Docker Swarm, MariaDB, Redis, or a separate Fastify layer for this product. That does not make the same architecture right for every project. PeşinTaksit's low traffic, KV-compatible data, and need for long-term maintainability are what made this decision sensible.

Using AI to remove system, not add code

AI use is often framed around shipping new features faster. In this project, its more valuable role was reducing the implementation burden of simplifying a working system.

The AI performed the code transformation. The decisions about which operational burden no longer made sense, whether the data fit KV, and which architecture the product needed still came from the reality of the product. I reviewed the resulting code to check the outcome.

Producing more code does not, by itself, produce a better system. Sometimes the useful outcome is removing layers that are no longer needed, and doing it quickly enough that the maintenance work actually gets done.

What this change does not prove

I do not yet have measured performance or cost results that I can attribute to this change. For a low-traffic product, winning a benchmark was not the reason for the decision. The goal was to keep the product running without unnecessary operational overhead.

A product with more traffic, different data requirements, or services that must scale independently may make a different choice. The lesson is not to move every small project to one platform. It is to compare the architecture with the product's current reality again.

Next: the user experience

An architecture should not be judged only by whether it works today. The attention required to keep it live tomorrow is part of the decision too.

For PeşinTaksit, the right move was not to grow the system. It was to reduce it to what the product actually needs. Next, I will redesign the UI/UX and make the tool easier to use.