Every time I start a new project, the first few days look the same.
I’ll set up the repo. Configure TypeScript. Add auth. Wire up a database. Sort out payments. Add a landing page, SEO basics, environment variables, and a folder structure I’ll probably need to refactor in a month.
Then a different project comes along, and I do it all again.
An e-commerce store. A documentation site. A small web app for a party or event. Different products, but the first 20% of the work is almost identical. I’m not learning anything in that 20%. I’m just copying from my last project and fixing what broke.
So I started asking a simple question: why am I still doing this by hand?
The tools I already use don’t quite solve it
Tools like create-next-app and create-t3-app are great. But they mostly ask the same question: which technologies do you want? Next or Vite? Prisma or Drizzle? Tailwind or not?
That’s useful, but it’s not how I think when I start a project. I think, "I need a ticketing site for an event.” Or “I need a docs site.” The tech choices come after that, and most of the real setup work, like checkout, tickets, webhooks, and check-in, has nothing to do with which framework I picked.
And if you build for Nigerian or wider African users, there’s another gap. Paystack, Flutterwave, and Monnify, Naira (NGN) formatting, and Termii for SMS: these aren’t first-class citizens in most starters. We wire them up manually every single time.
What I’m building
It’s called Scaffoldr. The idea is one command:
npx create-scaffoldr@latest my-event --type ticketing
You pick what you’re building with a flag, and Scaffoldr generates a working project with the right pieces already connected. Under the hood, it works like this:
- Blueprints are product types: docs, ticketing, and e-commerce.
- Modules are features: auth, database, payments, email, and SMS.
- A project is a base layer plus modules. So Paystack is a module you can swap for Flutterwave or Monnify, not code buried inside a template.
-
scaffoldr addlets you add a feature to a project later, because projects don’t stop changing after day one. - It’s all TypeScript and fully open source, and modules are designed so other people can contribute them. The generated code is plain code you own. There’s no runtime library and no lock-in.
How I’m building it
I’m going to do this in public, and I’m going to do it a little differently.
I’ve planned the whole project as 170 tiny tasks, each with a clear start, a clear end, and a test I can run. I’ll work on them one at a time and test between every step.
I’ll write about what works and what doesn’t, including the parts where it goes wrong.
The build has milestones:
- The engine, which scaffolds a docs site end to end.
- Ticketing and launch with Paystack, auth, database, and a v0.1 release.
- Community, with
scaffoldr add, contributor tooling and good first issues.
What I’ll be writing about
Each milestone gets articles on real decisions: the architecture, how files from different modules merge without breaking each other, how to test a code generator, how to wire up Paystack webhooks properly, and how to make an open-source project people actually want to contribute to.
Where I need your help
Nothing is published yet, so this is the best moment to shape it.
- What would you want to scaffold? Tell me which product types you rebuild most often.
- Which providers matter to you? I’m starting with Paystack, Flutterwave, and Monnify, but I want to hear what else is missing.
- Want to contribute? Once v0.1 ships, I’ll open a set of beginner-friendly issues. Follow the repo here
If you’ve ever copied an old project just to start a new one, you already know why I’m building this.
Top comments (0)