From Overthinking Next.js to Shipping with SvelteKit

A while ago, I had this idea of building my own Next.js boilerplate.

At first, it sounded like a great investment. I wanted a setup that matched the way I worked: the tooling I liked, the architecture I preferred, and all the pieces I thought every future project would need.

But the further I went, the more complicated it became.

What started as a simple boilerplate slowly turned into a collection of configurations, technical decisions, and abstractions that needed constant attention. Every improvement introduced another choice to make. Every new feature raised another question about the “right” way to structure things.

Eventually, maintaining the boilerplate started to feel like its own project.

Around the same time, I kept coming across discussions, videos, and articles from developers who were beginning to move away from Next.js. Some complained about its growing complexity. Others felt that the framework was no longer as straightforward as it used to be.

That pushed me to look at alternatives.

Choosing Svelte and SvelteKit

I decided to learn Svelte and SvelteKit.

I started by taking a few courses to understand the fundamentals. Once I felt comfortable enough, I looked for a project that would force me to apply what I had learned.

I chose to build a POS web application.

It wasn’t meant to become a polished commercial product from day one. It was simply a vehicle for learning.

Building While Learning

In the beginning, I did almost everything manually.

I handled the setup myself, wrote the code myself, and tried to understand how each piece worked before moving on.

As the project progressed, though, I started integrating AI into my workflow more intentionally.

I used AI to help draft PRDs. I explored Google Stitch to generate design ideas. I used OpenCode as an AI coding assistant. I also experimented with several AI skills to support different parts of the development process.

Instead of replacing the work, these tools helped remove friction.

They accelerated tasks that used to slow me down and allowed me to spend more energy on decisions that actually mattered.

Shipping the MVP Faster Than Expected

The result surprised me.

I finished the MVP of the POS web app much faster than I originally expected.

The application is still relatively simple. It currently includes:

Login and registration
A transaction dashboard
Product CRUD functionality
A POS system for recording sales

That’s it.

No groundbreaking features. No revolutionary architecture.

But seeing it reach the finish line—and knowing that it actually works—felt incredibly satisfying.

From Tooling to Product

The biggest shift wasn’t changing frameworks.

It was changing what I focused on.

A few months ago, most of my energy went into thinking about frameworks, tooling, boilerplates, and endless technical decisions. I was optimizing the environment before I had even built the thing I wanted to create.

Now, I spend more time thinking about the product itself.

What problem does it solve? How should people use it? What can make their workflow easier?

Those questions have become far more interesting than deciding which abstraction layer to add next.

What’s Next

The next step is adding AI features to the POS application.

My goal isn’t to add AI just because it’s trending. I want to use it to simplify the sales recording process and help users complete tasks more quickly and with less effort.

If it genuinely improves the experience, then it’s worth building.

Keep Moving

This journey reminded me of something simple.

Sometimes, what we need isn’t the most popular stack or the most sophisticated setup.

Sometimes, we just need something that helps us keep moving.

Something that lets us finish what we started.

Because shipping a simple product that people can actually use teaches far more than endlessly preparing to build one.