Our 12-package starter for every new Next.js engagement at Hanova.

Every new Next.js project we start begins from the same small, deliberate set of dependencies. Not a bloated boilerplate, just a tight list of libraries that have earned their place, plus an equally deliberate list of things we leave out. The goal is a stack that is quick to build on and cheap to maintain a year later.

What goes in

• next, react and react-dom, with the App Router as the foundation and server components by default.
• typescript, which is non-negotiable, because types are the cheapest documentation and the earliest bug catcher.
• prisma and its client, for a typed, migration-driven data layer where the schema is reviewable and the queries are safe.
• next-auth for authentication and sessions, so we are not hand-rolling crypto.
• bcrypt for password hashing where we own the credentials.
• tailwindcss, to keep styling consistent and design tokens explicit.
• zod, for runtime validation at the edges, so untrusted input is parsed rather than trusted.
• framer-motion, for motion that is declarative and respects reduced-motion preferences.
• lucide-react, for a clean icon set that tree-shakes.
• nodemailer, for transactional email through the client's own SMTP, with no third-party lock-in.

That is the spine. Individual projects add a payment SDK, an image host or an analytics script, but the core stays the same, which means anyone who joins a project already knows where things live.

What we deliberately leave out

• Heavy component kits that impose their own look. We would rather build a small set of components that match the brand than fight a library's defaults.
• Date libraries like moment, since the native Intl and Date APIs cover most needs.
• A separate HTTP client on the server, because the built-in fetch is enough and is one less thing to patch.
• A global state library by default. Server components and the framework's own data fetching remove most of the need, so we add client state only where it earns its place.

Why a fixed starter matters

The point is not the exact list. It is having a default at all. A consistent starter makes onboarding faster, keeps security patching predictable, and stops the team relitigating foundational choices on every project. The interesting decisions get spent on the client's actual problem instead of on this week's trendy library. Boring, consistent foundations are what let the work built on top of them be ambitious.