The challenge
Finding, organizing, and sharing high-quality AI prompts is scattered across docs, chats, and spreadsheets, with no dedicated place to discover, publish, or monetize them.
The approach
Built a full-stack Next.js 16 platform with NextAuth authentication, a MongoDB/Mongoose data layer, OCI object storage for media, and an admin dashboard for bulk prompt imports, alongside public explore/trending/categories/blog sections and region-based pricing tiers.
The outcome
A community prompt marketplace with authenticated publishing, comments and usage telemetry, an admin console for bulk content operations, and region-based pricing tiers ready for a payment provider.
How PromptSense is put together
A single Next.js 16 deployment: server-rendered public pages, route handlers for the API and an admin console share one codebase and one session model, backed by MongoDB and OCI Object Storage.
- deployable for site, API and admin
- 1
- rate-limited write endpoints
- 6
- uploads per IP
- 20/min
01 · Clients
client
Visitors & creators
client
Admins
02 · Next.js app
service
Public pages
RSC
explore, prompts, blog, pricing
service
Admin console
bulk imports, users, content
03 · Platform
service
Route handlers
prompts, comments, telemetry, uploads
service
Auth.js
credentials (bcrypt) + Google, JWT
gateway
Rate limiter
sliding window, per instance
04 · Data & services
database
MongoDB
Mongoose
prompts, users, blog
object store
OCI Object Storage
media uploads
third-party
Google OAuth
11 connections
- Visitors & creators→Public pagesHTTPS
- Visitors & creators→Route handlerscomments · telemetry
- Admins→Admin console
- Admin console→Route handlersbulk import
- Public pages→MongoDBserver read
- Route handlers→Rate limitercheck
- Route handlers→Auth.jssession
- Route handlers→MongoDB
- Route handlers→OCI Object Storageput object
- Auth.js→MongoDBadapter
- Auth.js→Google OAuthsign-in
Request flow · Bulk-importing prompts
- 1An admin submits a batch from the console to /api/admin/prompts/bulk.
- 2The handler rate-limits the caller and checks for an admin session before reading the body.
- 3The payload is validated against a Zod schema; a malformed batch is rejected with field-level errors.
- 4Valid prompts are written in one insertMany and appear on the server-rendered explore pages.
Design decisions
- One deployable
- Pages, API and admin share a codebase and session model: one deploy and one set of types for a solo-maintained product.
- Stateless sessions, persistent accounts
- Accounts persist in MongoDB through the Auth.js adapter while sessions are JWTs, so route handlers authorise without a session lookup.
- Validation as a tested module
- Input schemas, admin checks and the rate limiter live in their own modules with unit tests rather than inline in handlers.
Trade-offs & known limits
- The rate limiter is in-memory, so it throttles within a warm serverless instance only; there is no shared store like Redis.
- Pricing tiers are presented by region but no payment provider is connected yet.
Have something similar in mind?
I'm open for freelance and contract work — let's talk about what you're building.