Expand Next.js MVP For Enterprise Pilots
Budget: $25 – $50 USD
We have a clean, working Next.js MVP deployed on AWS EC2 that performs fast resume analysis and ranking using an LLM (Anthropic/Claude).
The core engine works.
What we need now is foundational infrastructure so we can run paid enterprise pilots without creating rework later when we add Stripe, dashboards, and full multi-tenant UX.
This is backend architecture and correctness, not UI polish.
What You Will Build (Exact Scope)
1. Database Layer (Postgres)
Provision Postgres (AWS RDS preferred) and implement schema using Prisma or Drizzle.
Required tables:
orgs
id
name
created_at
users
id
org_id (FK)
email
auth_subject (Cognito sub or auth provider ID)
created_at
org_entitlements (CRITICAL — must exist even before Stripe)
org_id
status (trial, active, inactive)
plan (free, pilot, pro) — string only
created_at
updated_at
jobs
id
org_id
title
jd_text
created_at
resumes
id
org_id
job_id
filename
resume_text (or S3 key)
created_at
analyses
id
org_id
job_id
result_json
created_at
llm_usage_events
id
org_id
user_id
model
input_tokens
output_tokens
created_at
2. Authentication (Minimal but Enterprise-Credible)
Implement one of the following (you may recommend):
AWS Cognito User Pools (preferred, AWS-native)
OR passwordless email auth (NextAuth/Auth.js)
Requirements:
Server-side session validation
Map authenticated user → users table → org_id
Manual org/user provisioning is acceptable (no admin UI required)
3. Org-Based Data Isolation (Non-Negotiable)
All reads/writes must be scoped by org_id
Enforced server-side in API routes
No client-side trust
No shared data between orgs
4. LLM Service Layer (Very Important)
You must not call Claude directly from route handlers or UI logic.
Implement a centralized service/module, e.g.:
runAnalysis({
orgId,
userId,
jobId,
resumes
})
This service is responsible for:
Calling Anthropic/Claude
Logging token usage to llm_usage_events
Returning structured results
Acting as the future hook point for:
Stripe entitlements
Usage caps
Plan enforcement
This design is mandatory to avoid rework later.
5. Usage Monitoring (No Caps Yet)
Log input/output tokens per request
Add a basic internal endpoint or script:
Usage by org (last 7 / 30 days)
No UI required
What You Will NOT Build
No Stripe integration for now but in the future we will
No Billing UI yet
No Usage caps or enforcement yet
No Multi-tenant admin dashboard (in the future maybe)
No need for UI redesign (but open to recommendations)
We do not want Supabase
No to Per-client repos or EC2 instances
Technical Environment
Next.js (already deployed on EC2)
AWS EC2
AWS RDS (Postgres)
Anthropic / Claude API
AWS IAM / Secrets Manager optional
Single codebase, single deployment
Acceptance Criteria
Multiple orgs can exist safely in the same deployment
Each org’s data is fully isolated
LLM usage is attributable per org/user
Entitlements table exists and is checked in service layer
Stripe can later update entitlements without touching core logic
Timeline
5–7 focused days
Clean handoff documentation required
Who Should Apply
Senior Next.js backend engineers
AWS-native mindset
Has built multi-tenant SaaS foundations before
Understands early-stage tradeoffs (pilot ≠ full SaaS)
Comfortable designing for future extensibility
To Apply
Please include:
Relevant Next.js + AWS projects
Auth experience (Cognito / NextAuth / similar)
Confirmation you understand this is a pilot-ready SaaS foundation, not a full product rebuild
The core engine works.
What we need now is foundational infrastructure so we can run paid enterprise pilots without creating rework later when we add Stripe, dashboards, and full multi-tenant UX.
This is backend architecture and correctness, not UI polish.
What You Will Build (Exact Scope)
1. Database Layer (Postgres)
Provision Postgres (AWS RDS preferred) and implement schema using Prisma or Drizzle.
Required tables:
orgs
id
name
created_at
users
id
org_id (FK)
auth_subject (Cognito sub or auth provider ID)
created_at
org_entitlements (CRITICAL — must exist even before Stripe)
org_id
status (trial, active, inactive)
plan (free, pilot, pro) — string only
created_at
updated_at
jobs
id
org_id
title
jd_text
created_at
resumes
id
org_id
job_id
filename
resume_text (or S3 key)
created_at
analyses
id
org_id
job_id
result_json
created_at
llm_usage_events
id
org_id
user_id
model
input_tokens
output_tokens
created_at
2. Authentication (Minimal but Enterprise-Credible)
Implement one of the following (you may recommend):
AWS Cognito User Pools (preferred, AWS-native)
OR passwordless email auth (NextAuth/Auth.js)
Requirements:
Server-side session validation
Map authenticated user → users table → org_id
Manual org/user provisioning is acceptable (no admin UI required)
3. Org-Based Data Isolation (Non-Negotiable)
All reads/writes must be scoped by org_id
Enforced server-side in API routes
No client-side trust
No shared data between orgs
4. LLM Service Layer (Very Important)
You must not call Claude directly from route handlers or UI logic.
Implement a centralized service/module, e.g.:
runAnalysis({
orgId,
userId,
jobId,
resumes
})
This service is responsible for:
Calling Anthropic/Claude
Logging token usage to llm_usage_events
Returning structured results
Acting as the future hook point for:
Stripe entitlements
Usage caps
Plan enforcement
This design is mandatory to avoid rework later.
5. Usage Monitoring (No Caps Yet)
Log input/output tokens per request
Add a basic internal endpoint or script:
Usage by org (last 7 / 30 days)
No UI required
What You Will NOT Build
No Stripe integration for now but in the future we will
No Billing UI yet
No Usage caps or enforcement yet
No Multi-tenant admin dashboard (in the future maybe)
No need for UI redesign (but open to recommendations)
We do not want Supabase
No to Per-client repos or EC2 instances
Technical Environment
Next.js (already deployed on EC2)
AWS EC2
AWS RDS (Postgres)
Anthropic / Claude API
AWS IAM / Secrets Manager optional
Single codebase, single deployment
Acceptance Criteria
Multiple orgs can exist safely in the same deployment
Each org’s data is fully isolated
LLM usage is attributable per org/user
Entitlements table exists and is checked in service layer
Stripe can later update entitlements without touching core logic
Timeline
5–7 focused days
Clean handoff documentation required
Who Should Apply
Senior Next.js backend engineers
AWS-native mindset
Has built multi-tenant SaaS foundations before
Understands early-stage tradeoffs (pilot ≠ full SaaS)
Comfortable designing for future extensibility
To Apply
Please include:
Relevant Next.js + AWS projects
Auth experience (Cognito / NextAuth / similar)
Confirmation you understand this is a pilot-ready SaaS foundation, not a full product rebuild