Open-source building blocks for the app itself — auth, email, validation, admin, UI
Part two, at the application layer: the permissively-licensed libraries you assemble a product from rather than write — Auth.js and Better Auth, React Email, Zod, shadcn/ui, TanStack Query, Prisma, Refine, Payload, Tremor.
Vishal · today
▲ 0 · Join to upvote
Auth.js (NextAuth)Better AuthReact EmailZod — TypeScript-first schema validationshadcn/ui — components you copy in and ownTanStack Query — server-state and cachingPrisma — typed database access and migrationsRefine — internal tools and admin panelsPayload — Next.js content backendTremor — dashboard and chart components
The frame
A separate library post covers the infrastructure you'd otherwise pay for — databases, analytics, support tooling. This one is the layer above: the code inside your app. The pieces here are things you should almost never write, because a well-maintained open-source version has already handled the edge cases you haven't hit yet.
All of these are permissively licensed — MIT, ISC or Apache-2.0 — so safe to build a commercial product on with no obligations. Still read the LICENSE file yourself before you commit; licences change.
The blocks
· Auth.js (NextAuth) / Better Auth — sessions, OAuth providers, password reset, MFA. Auth is a security surface; do not hand-roll it.
· React Email — write transactional emails as components and preview them locally. Pairs with any sending API.
· Zod — one schema, validated at runtime and typed at compile time. The boundary check for every form and API input.
· shadcn/ui — accessible components you copy into your repo and own, rather than a dependency you fight. Built on Radix and Tailwind.
· TanStack Query — server-state, caching, refetching and loading states done properly. Deletes a lot of hand-written glue.
· Prisma — typed database access and migrations. This platform runs on it.
· Refine / Payload — an internal admin panel or a content backend without building CRUD screens by hand.
· Tremor — charts and dashboard components, so your metrics page isn't a two-week project.
How to choose
Pick the fewest blocks that cover your app, and prefer the ones with the most GitHub activity and the clearest docs — a library is a bet on its maintainers. Read the open issues before you adopt: an active, friendly issue tracker is worth more than a slick landing page.
Contributing back
The easiest real contribution is a good bug report with a minimal reproduction, or a docs fix for the thing that confused you. Both take an afternoon and both genuinely help.
open sourcelibrariesdeveloper toolstypescriptfrontend