Why I’m Building My Own NestJS StarterKit
Graduated from Telkom University with a degree in Computer Science, specializing in software development and systems design. Recently contributed to Supernova Palapa Nusantara as a Software Engineer, where efforts focused on developing and implementing software solutions, improving project reliability, and collaborating with multidisciplinary teams. Key competencies include software architecture, quality assurance, and backend programming.
At Supernova Palapa Nusantara, contributed to software architecture enhancements with a focus on system reliability and project goals. Previous roles involved optimizing and developing web platforms, such as university systems, in collaboration with cross-functional teams. Brings a collaborative approach and a commitment to delivering impactful digital solutions that align with organizational objectives.
Intro
Over the years, I’ve built and maintained quite a few backend projects. Some started from scratch, others from templates, and a few evolved from messy prototypes that somehow made it to production. One thing kept repeating: every new project meant doing the same setup again and again.
Setting up configs.
Setting up authentication.
Integrating Prisma.
Structuring modules.
Defining error handling, logging, and response formats.
At my last job, I actually built something similar, an internal SkeletonKit for the company’s software house projects. It was designed to standardize backend development across multiple client applications and help the team move faster when starting new services. But that project was strictly for internal use, customized for the company’s stack and business needs.
This time, I wanted to build something that goes beyond work. Something open, flexible, and accessible to anyone who loves building scalable backends.
That’s when I decided to create the NestJS MVP StarterKit, my own open-source foundation for real-world applications.
The Problem with Existing Starter Kits
There are many NestJS starter projects out there, and some of them are great. But most of them live at one of two extremes.
Too minimal, basically a fresh NestJS install with a few renamed folders.
Too opinionated, forcing you to follow someone else’s architecture or tools.
They often look nice on GitHub, but once you try to use them for a real project, things start falling apart.
Common issues I’ve seen:
Folder structures that don’t scale well.
Missing modular design and clear domain boundaries.
Reliance on third-party auth like Auth0 or Clerk that creates vendor lock.
Outdated dependencies and inconsistent patterns.
A focus on “getting started fast” instead of “staying maintainable”.
So yes, they’re great for demos, but not for long-term projects.
Why I’m Doing This Myself
After years of working on backend systems, I realized I didn’t want a “template” anymore. I wanted a foundation.
When you’ve built enough APIs, you start to see what keeps breaking and what’s always needed. You get tired of rebuilding the same structure for every new idea.
I needed something clean, extensible, and trustworthy. A base I could spin up quickly for any MVP, but that could also scale without a full rewrite later.
That’s why I decided to build my own starter kit.
Not because I think I can do it better than others, but because I want one that fits the way I think about architecture.
The Principles Behind My StarterKit
This project is more than just a collection of files. It’s a reflection of certain ideas I really believe in.
DIY Auth and Core Logic
No vendor lock. Full control over the stack and the data.Scalable Modular Structure
Each domain, like Auth or User, is its own module that can grow independently.Modern and Predictable
Follows clean architecture patterns without going overboard.Production-Ready from Day One
Includes configs, Prisma, logging, Docker setup, and Swagger.Readable and Educational
Every decision should make sense when you read the code. Not just “it works”, but “here’s why it’s written this way”.
Basically, this isn’t just a starter kit. It’s a learning base for real-world backend development with NestJS.
Tech Stack and Design Choices
Every tool was chosen with long-term maintenance in mind.
NestJS for its structured, modular architecture.
Prisma ORM for type-safe and elegant database management.
Passport and JWT for solid authentication and authorization flows.
Docker and Environment Configs for consistent local and production environments.
Jest for testing key modules.
Swagger (OpenAPI) for easy API documentation and collaboration.
It’s intentionally simple on the surface, but powerful once you start building on it.
What I’m Trying to Achieve
I’m not doing this to reinvent the wheel. I just want to simplify my own workflow and reduce setup fatigue.
My goals are simple:
Create a codebase that matches how I think and work.
Make it fast to start new projects without rebuilding boilerplate.
Share it so others who value clean architecture can use it too.
In a way, this project is also my documentation of thought, a living reference I can return to, refine, and grow with.
The Journey Ahead
This isn’t a one-time release. I’ll document it piece by piece, like an engineering journal.
Each core module (Auth, User, Config, Logging, etc.) will have its own breakdown.
I’ll explain:
Why the design choices were made.
What trade-offs were considered.
What alternative patterns might also work.
Because the goal isn’t just to share code. It’s to share thinking.
Closing Thought
The best starter kit isn’t the one you download. It’s the one you understand deeply because you built it yourself.
That’s why I’m building my own NestJS StarterKit.
Not because others don’t exist,
but because this one will fit me and hopefully help others too.
