I started from scratch - let's see whether it was worth it
Today, I want to share the story behind DirectoryStack v2.0 - specifically the journey that led to this complete rewrite. I want to walk you through my thought process and the technical decisions that ultimately made v2.0 necessary and, more importantly, better for everyone. It was a significant undertaking that I'm actually quite proud of, and I think understanding the "why" behind it will help you appreciate what we've built.
The Growing Pains of v1
Backstory: DirectoryStack is a Next.js template that can be used by devs to setup a working directory business in literally minutes while owning the full source code.
First, let me be clear - v1 wasn't bad. It was actually a solid codebase that many of my customers have built successful directories with. But as I kept adding features and supporting more customers, some fundamental issues became impossible to ignore.
The biggest issue with v1 was its monolithic structure. All components were in the components folder, all server actions in the server actions folder, and so on. This might sound organized, but it created a maintenance nightmare.
Every time I wanted to add a new feature or fix a bug, I had to touch multiple parts of the codebase. And then I had to create detailed update guides for all past clients explaining exactly what files to change and how. It was time-consuming and error-prone.
The Trigger Moment
The turning point came when a customer wanted a way to capture leads. Instead of integrating it directly into the monolith, I built it as a standalone module and provided instructions for adding it to their codebase.
This worked surprisingly well! The module was self-contained, easy to add, and didn't require massive changes throughout their codebase. This got me thinking about a completely different approach to DirectoryStack.
The Decision
Around the same time, React 19 and Next.js 15 were released with significant improvements. I initially tried to upgrade the existing codebase, but after some painful iterations, I realized it would be easier to start from scratch.
This wasn't an easy decision. It meant losing about 1.5 months of development time - on top of what I put into v1 as a whole. But looking at the long-term benefits, I knew it was the right move.
The outcome
The new v2.0 is built around two key principles:
Feature-driven folder structure: Instead of organizing by technical function (components, server actions, etc.), the code is organized by features or as I call them "modules". Everything related to listings is in the "listings" module, everything for managing users is in the "user management" module, and so on.
Modular architecture: The codebase is now split into 13 core modules and 8 shared modules. The core and the shared modules are always installed. I call this the "Foundation". I believe every directory can use these modules. Next, I am introducing extension modules. These can be added to your project if you need them. Want to capture leads? Just add the "Lead Capture" extension module. Fancy a blog? Just add it. You get the idea.
This approach has huge benefits:
When I release a new feature or module, I can simply provide the module folder to clients
Clients can pick and choose exactly what they need
Updates are isolated to specific modules, not spread throughout the codebase
The core is lighter and more maintainable
Was it worth it?
From a "I can scale this thing to the moon without massive tech debt"-perspective: Yes
From a "I want to build a better product"-perspective: Yes
From a "I want to learn new Tech - esp. Next.js 15"-perspective: Yes
From a "Revenue"-perspective: Let's see.
Best
Till
