In the last article, I said I keep rebuilding the same app. Before writing any code, I wanted to answer a fair question: don't tools for this already exist?
They do, and they're good. So here's what I found.
Two families of tools
Starting a project today usually means picking from one of two families.
Family 1: Scaffolders.
You run a command, answer questions about your tech, and get a project. create-next-app is the plainest version: it's Vercel's official scaffold, and it has no opinions about auth, payments, databases, or similar concerns. create-t3-app goes further. It's a modular CLI that generates full-stack, type-safe Next.js apps, and the stack covers tRPC, Tailwind, Prisma or Drizzle, and NextAuth. Each technology can be selected independently of the others. There are newer ones too, like Better-T-Stack, that widen the menu of frontends, backends, and databases.
Family 2: Starter kits.
These are clone-and-customize templates, usually built around a product shape like a SaaS app with billing. One comparison I read put the difference this way: T3 is a scaffold where you pick your pieces, while a SaaS starter is a batteries-included kit. The same comparison noted that T3 doesn't include email at all, so you choose and wire up your own provider. The SaaS starter it compared against ships with Resend already integrated.
Where each family stops
Scaffolders are modular but stack-shaped. They're great at "Next.js plus Prisma plus Tailwind." But the question they ask is, “Which technologies do you want?” Nobody starts a project thinking that. I think, “I need a ticketing site for an event." After the stack is chosen, I still write checkouts, tickets, webhooks, and check-ins myself.
Starter kits are product-shaped but fixed. You get the product, but you inherit its decisions. Want Paystack instead of Stripe? Drizzle instead of Prisma? You're now editing someone else's code, and your copy slowly drifts away from the original.
The gap
What I want sits between the two: product-shaped and modular.
- You say what you’re building (--type ticketing).
- You get that product’s features already connected.
- Every piece, like payments, database, auth, and email, is a swappable module, not code buried in a template.
That’s the whole idea behind Scaffoldr:
npx create-scaffoldr@latest my-event --type ticketing --payments paystack
Scaffoldr isn’t built yet, so that last row is a goal, not a claim.
Why this matters more for African developers
Most starters I’ve used treat African payment providers as an afterthought, if they appear at all. But if you’re building for Nigerian users, you’re wiring up Paystack, Flutterwave, or Monnify on every project. You’re handling amounts in kobo, verifying webhook signatures, formatting NGN, and sending SMS through a local provider. It’s the same work every time, and it’s exactly the kind of thing a module should do once.
If there’s a starter that already does this properly, let me know. I’d rather build on it than reinvent it.
What I’m not claiming
- I’m not replacing these tools. I’m borrowing ideas from them, especially the modular choice model that T3 popularized.
- This is a crowded space, and the hard part is maintenance. Templates rot when dependencies move. I plan to handle that with automated tests that generate and build every combination in CI.
- Product-shaped scaffolding could fail. If developers don’t care about product types, this won’t take off. That’s why I’m writing about it before building all of it.
Help me test the idea.
Two questions; answer either one:
- Which product types do you rebuild most? E-commerce, docs, booking, marketplace, and internal tools?
- What do you always end up wiring by hand? Payments, auth, email, SMS, or something else?
Your answers decide which blueprints I build first.
Next up: the architecture, with the full design on one page.
Top comments (0)