← Back to blog

Why I built Stacktura

I’m the kind of developer who rewrites things three times before shipping.

Not because I like wasting time. Because I look at my code a week later and think: this could be cleaner. This structure doesn’t scale. This was a bad call.

So I built Stacktura. A starter kit that survives my own standards.

The pattern I kept repeating

Every client project starts the same way. Set up auth. Wire up Stripe. Build an admin panel. Configure Docker. Add CI/CD. Two weeks pass and I haven’t written a single line of business logic.

I told myself I’d build a reusable base. I tried. Three times.

The first attempt was too rigid. Everything was coupled. Removing billing meant touching twelve files and hoping nothing broke.

The second attempt was too abstract. Interfaces everywhere, service containers for everything. Clean architecture on paper, impossible to read in practice.

The third time, I stopped trying to be clever. I wrote the code the way I actually want to read it: short functions, clear structure, one pattern for everything. And I added a CLI to remove what you don’t need, instead of designing an architecture that anticipates every possible combination.

What I kept from 42

I went through École 42. The coding school with no teachers, no courses, and a linter that rejected your code if a function was over 25 lines.

Most of those rules are overkill. But some stuck with me:

These aren’t rules I enforce because someone told me to. They’re the habits that survived years of real projects. Every file in Stacktura follows them.

Why I’m always indecisive

Here’s something I don’t see other developers admit: I change my mind constantly.

I’ll pick a folder structure, commit to it, build three features on top of it. Then realize there’s a better way. So I restructure. Again.

Modules in app/Services/? No, better split by domain: app/Core/Services/ and app/Modules/Admin/Services/. Interface for everything? No, that’s over-engineering, just use the class directly. Put billing actions in the module folder? No, there’s only one file, keep it in core/actions/.

Every decision in Stacktura has been made, unmade, and remade. What you get is the version that survived. The structure I stopped wanting to rewrite.

What I actually wanted

My goal was never to sell a starter kit. It was simpler than that: I wanted a base I could trust.

Something where I run one command, pick what I need, and start building. No leftover code from features I don’t use. No patterns that look smart but slow me down. No any types hiding behind a clean API.

I wanted to open any file and think: yes, this is how I’d write it today.

That’s what Stacktura is. The kit I built for myself, that I use for my own clients, and that I’m now sharing because other developers have the same problem.

The module system changed everything

The breakthrough wasn’t the code. It was the CLI.

Instead of designing an architecture flexible enough to handle every combination of features, I wrote a tool that removes what you don’t need. Cleanly. Files, routes, migrations, packages. Gone.

Nine features are removable: auth modules like OAuth and email verification, billing, admin, dark mode, Storybook, CI/CD, even the landing page. You pick what stays, the CLI removes the rest, and the app still works.

This solved my biggest problem: I stopped compromising on defaults. I could include billing with full Stripe integration, knowing that developers who don’t need it can remove it completely. No dead code. No feature flags. Just deletion.

The code is the product

I don’t have a marketing team. I don’t have a landing page video (yet). What I have is code that I use every day, structured the way I wish every project was structured.

If you’ve ever started a SaaS project and spent two weeks on auth and billing before writing a single feature, that’s the problem Stacktura solves. Not with magic. With code you can read, understand, and modify.

That’s it. That’s why I built it.