OptiWHoobii packs a SaaS foundation into a Next.js 15 starter

A starter for the connective work around a SaaS product

Many SaaS projects begin with the same non-product work: establish sign-in, store users and application data, connect billing, protect paid features, upload files, and make enough of the interface observable to learn how it is used. Each service is individually familiar. Joining them into a coherent application is the more demanding task.

OptiWHoobii is positioned as a production-ready Next.js SaaS starter kit intended to bring those pieces together. The README describes authentication and account linking, subscription handling through Polar.sh, an OpenAI-powered chat interface, Cloudflare R2 uploads, PostHog tracking, and a responsive component-based UI. It should be most relevant to builders creating a subscription product who prefer to begin with a broad application foundation rather than wire up every integration independently.

The project is written in TypeScript, and its manifest confirms Next.js 15.3.1, React 19, Better Auth, Drizzle ORM, Polar packages, OpenAI AI SDK packages, AWS S3 tooling, and PostHog dependencies. That combination makes the repository a useful map of one opinionated stack for a web product, not simply a visual template.

A dashboard-centered application layout

The documented project structure centers the application in Next.js App Router directories. Authentication pages live under app/(auth), while the protected product area is organized under app/dashboard. The dashboard includes documented areas for chat, uploads, payments, and settings, alongside dashboard-specific components. Public pricing pages and API routes sit separately in the app directory.

That layout reflects a practical boundary: visitors can discover pricing, but signed-in users work from the dashboard. The README also states that subscriptions can gate premium features with overlays and that subscription status can be tracked as active, canceled, or expired. Polar.sh webhooks are described as the mechanism for real-time subscription updates, while the customer portal gives users a self-service billing path.

On the persistence side, the documented db/schema.ts and db/drizzle.ts files suggest a small, explicit database layer. The README names Neon PostgreSQL as the database service and Drizzle ORM as the type-safe toolkit used with it. “Type-safe” here means TypeScript can help check that code interacting with the database matches the expected shape of the data before it runs.

The starter also includes files in lib/auth, a subscription utility, and image-upload utilities. This separation is a useful convention for a starter: page and component code can focus on presenting an interaction, while the integration details are kept in focused library modules.

The integrations behind the product surface

Authentication is built around Better Auth 1.2.8, according to both the README and manifest. The documented capabilities include Google OAuth, database-persisted sessions, profile management with image uploads, and linking several sign-in providers to one account. OAuth is a standard delegated sign-in flow, such as allowing a user to sign in with Google without the application handling the user’s Google password.

For monetization, the project pairs Better Auth with Polar.sh packages. The README documents two example pricing tiers, Starter at $99 per month and Professional at $499 per month, though adopters would need to create and configure their own Polar products and IDs. The included environment variable list makes that operational dependency visible: a Polar access token, webhook secret, product identifiers, and slugs are all required to enable this part of the application.

The AI feature is described as a built-in OpenAI chatbot with multi-step conversations and Markdown rendering. The manifest supports that description with ai and @ai-sdk/openai, while react-markdown and remark-gfm are present for rendering formatted responses. For builders, the important distinction is that this is an integration point rather than a model in the repository: using it requires an OpenAI API key and the associated external service configuration.

File handling follows a similarly service-backed approach. The README describes Cloudflare R2 storage through its S3-compatible API, with drag-and-drop uploads, validation, progress feedback, an image gallery, metadata, and copyable URLs. The presence of @aws-sdk/client-s3 confirms the S3 client layer. R2 credentials, an account ID, and a bucket name must be supplied through environment variables, and the setup notes call out configuring browser cross-origin resource sharing, or CORS, for the application domain.

The UI stack combines Tailwind CSS v4 with Radix UI dependencies and the README’s stated use of shadcn/ui components. Tailwind supplies utility classes for styling, while Radix provides accessible, unstyled interface primitives that can be composed into a product-specific design. The project also lists next-themes and documents dark and light themes, as well as loading skeletons and optimistic UI updates. Optimistic updates are interface changes shown immediately while a request is still being completed, which can make an application feel more responsive but requires careful handling when an operation fails.

Configuration is part of the starter’s real cost

A useful lesson from OptiWHoobii is that a feature-rich starter also has a feature-rich configuration surface. The README’s prerequisites span Node.js, PostgreSQL, R2, Polar, OpenAI, and optional Google OAuth. Database migrations must be generated and applied with Drizzle Kit. Each provider brings credentials, setup steps, and deployment-time environment variables.

That is not necessarily a flaw. It is an honest expression of the capabilities being assembled. Teams that need billing, storage, and AI from the outset may value having those seams already identified. Teams validating a smaller idea may want to disable or defer some integrations, so local development and operations do not begin with every external account at once.

There is also a practical repository-reading lesson here. The README describes the project as a Next.js SaaS starter, while the supplied package manifest uses the package name apple-pass and lists additional dependencies beyond the README’s core stack. Builders evaluating the code should inspect the active routes, configuration, and dependency usage before assuming every listed package belongs to the documented starter workflow.

For developers looking for a TypeScript and Next.js starting point that foregrounds the common SaaS building blocks, inspect MuLIAICHI/OptiWHoobii and compare its documented integrations with the services you are prepared to operate.