From 0 to SaaS in 14 Weeks: 38% Trial Conversion

Industry: HR Tech Project Type: Full-Stack SaaS from scratch Duration: 14 weeks Team: 1 architect, 2 full-stack developers, 1 designer, 1 PM Result: 200 paying customers in month 4

The Starting Point

A HR tech founder came with a validated idea: compliance management and onboarding automation for SMBs (10-200 employees). The market existed — enterprise tools like Workday were too complex and expensive, and spreadsheets were the alternative.

The requirements:

• Multi-tenant SaaS (one codebase, each customer isolated)
• Role-based access control (Admin, HR Manager, Employee, Read-only)
• Stripe billing (monthly plans + per-seat pricing)
• Document storage and e-signature (offer letters, NDAs, policies)
• SOC2-ready infrastructure (required for enterprise prospects)
• Launch before a competitor's funding announcement (13-week deadline)

The constraint: 14 weeks. Not 6 months. Not 1 year.

Architecture Decisions

Multi-Tenancy Model

Three common multi-tenancy approaches:

We chose row-level isolation with PostgreSQL Row Level Security (RLS).

Every table has a tenant_id column. PostgreSQL RLS policies enforce that queries only return rows matching the authenticated tenant. This gives strong isolation with a single database and scales well to thousands of tenants before needing to shard.

-- Example RLS policy
CREATE POLICY tenant_isolation ON employees
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

Authentication Architecture

We used NextAuth.js with a custom database adapter:

• Email + password for direct signups
• Google SSO for organizations already on Workspace
• SAML SSO for enterprise customers (Okta, Azure AD) — added in week 12
• Magic link for employee invitations

Session management: JWT tokens with 15-minute access tokens and 7-day refresh tokens. Short access token TTL reduces risk if tokens leak.

Billing Architecture (Stripe)

The billing model: per-seat, monthly. Three tiers (Starter: $12/seat, Professional: $24/seat, Enterprise: custom).

Key implementation decisions:

1. Metered billing: Seat count syncs with Stripe on a daily job. Customers aren't blocked if they add more seats than their plan — they're charged at next billing cycle.

2. Trial enforcement: 14-day trial, enforced via middleware on all dashboard routes. Stripe webhook updates DB on subscription events.

3. Usage-based add-ons: Document storage over 5GB billed at $0.10/GB/month via Stripe Metered billing.

Billing flow:
User adds seat → DB update → nightly job → Stripe quantity sync → invoice
Trial expires → Stripe webhook → DB flag → middleware blocks routes → upgrade prompt

File Storage

HR documents (offer letters, NDAs, policies, identification) are sensitive. Architecture:

• Files stored in S3 with server-side encryption (AES-256)
• Pre-signed URLs for temporary access (15-minute expiry)
• Files never served from Next.js — always direct S3
• Virus scanning on upload (ClamAV via Lambda)
• Audit log for every file access event

E-Signature

We evaluated DocuSign ($30/envelope → too expensive for SMBs), HelloSign ($0.50/envelope — acceptable), and building custom.

Decision: HelloSign API for initial launch. Simple e-signature requirements (offer letters, policy acknowledgments) don't need complex DocuSign features. We built a custom UI layer on top of the HelloSign API to match the product's design system.

The Build: Week by Week

Weeks 1-3: Foundation

• Database schema design + migrations
• Authentication system (NextAuth + custom adapter)
• Multi-tenant middleware
• Basic CRUD for core entities (employees, departments, roles)

Weeks 4-7: Core Features

• Onboarding workflow builder (drag-and-drop task sequences)
• Document management + file upload
• E-signature integration
• Role-based UI (different nav and permissions per role)

Weeks 8-10: Billing + Notifications

• Stripe integration (subscriptions, webhooks, customer portal)
• Email notifications (Resend API — transactional email)
• In-app notification center
• Trial enforcement middleware

Weeks 11-12: Enterprise Features

• SAML SSO (required by 3 enterprise prospects waiting to buy)
• Audit log system
• Data export (GDPR compliance)
• SOC2 compliance documentation

Weeks 13-14: Polish + Launch Prep

• Onboarding flow optimization (we cut time-to-first-value from 12min to 4min)
• Performance optimization (Lighthouse: 94 mobile, 98 desktop)
• Load testing (simulated 500 concurrent users, no degradation)
• Customer support integration (Intercom)
• Staged rollout: 50 beta users in week 13, public launch week 14

Results at Month 4

Product Metrics

Technical Metrics

Business Metrics

What Made the Difference

Onboarding engineering, not onboarding UX.

The original onboarding flow had 7 steps and took 12 minutes to get to the first "aha moment" (seeing your first employee's onboarding checklist). We rebuilt it as 3 steps (company name, upload logo, invite first employee) that take 90 seconds. The aha moment moved from minute 12 to minute 4.

That change moved trial-to-paid conversion from 22% to 38%.

Multi-tenant architecture done right from day one.

Not retrofitted. This matters because RLS policies have to be designed into the schema. Retrofitting multi-tenancy to a single-tenant app is almost as expensive as a rebuild.

SAML SSO at week 12, not week 24.

Three enterprise deals (worth $4,200 MRR combined) were contingent on SAML. Prioritizing it in week 11-12 unlocked those deals at launch instead of 3 months later.

Lessons

What we'd do differently:

• Implement feature flags from week 1 (we added LaunchDarkly at week 10 — should have been day 1)
• More aggressive load testing earlier — we found an N+1 query issue in week 13 that could have been caught in week 7

What was validated:

• PostgreSQL RLS is the right multi-tenancy choice for products under 10,000 tenants
• Stripe's customer portal eliminates 40-60% of billing support tickets
• Time-to-value in onboarding is the single highest-leverage conversion lever

Is This Right for Your SaaS?

This project worked because:

• Requirements were well-defined before week 1
• The founding team was available for weekly reviews
• The market had been validated before building

Related resources:

• SaaS Development Solution — how we approach SaaS builds
• Website Cost Calculator — estimate your SaaS build cost
• Build vs Buy Guide — when custom makes sense

Talk to us about your SaaS →