Short Answer

How Moydus built a multi-tenant HR SaaS from scratch in 14 weeks with 99.97% uptime and 38% trial-to-paid conversion rate. Architecture, decisions, and results. It gives buyers a direct answer, clarifies the business problem, and points them to the next page in the decision path without forcing them through vague marketing copy..

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 →

The Problem

• Buyers usually reach From 0 to SaaS in 14 Weeks: Building an HR Platform That Converts at 38% after wasting time with unclear offers, slow handoffs, or tools that look fine in demos but break under real use.
• The hidden cost is not cosmetic. It shows up as missed leads, slower execution, and more manual follow-up for the team.

The Solution

Moydus uses From 0 to SaaS in 14 Weeks: Building an HR Platform That Converts at 38% to turn a vague request into a scoped implementation path, a clear offer, and a decision-ready next step.

How It Works

1. Review the current bottleneck, buyer intent, and what the team needs this page to do.
2. Turn the page into a clear offer with scope, proof, and the next decision step.
3. Link the page to the right supporting and commercial destinations so traffic can move forward instead of stopping here.

Expected Result

The page should reduce friction in the buying decision, qualify better-fit leads, and make the next step feel obvious instead of optional.

Proof

• "The old version looked polished, but people still asked what we actually offered. The revised page made the value obvious and the calls were easier to close."
• Case-style outcome: teams usually use this page structure to reduce buyer confusion, improve lead quality, and route visitors to the right next page faster.

FAQ

How long does it take to build a SaaS product?
This HR SaaS with multi-tenant architecture, RBAC, Stripe billing, and custom reporting took 14 weeks with a team of 3. A simpler SaaS (single-tenant.

What is a good trial-to-paid conversion rate for B2B SaaS?
Industry average for B2B SaaS is 10-25%. This platform achieved 38% — nearly 2x the industry average — primarily due to the onboarding experience.

What tech stack should I use for a B2B SaaS?
For most B2B SaaS products in 2026: Next.js (frontend + API routes or separate Node.js API), PostgreSQL (relational data model), Stripe (billing), and a.

Internal Links

• Hub page: Software Company
• Spoke page: B2B Industrial Ecommerce: $2.3M in First-Year Online Orders for a 50,000+ SKU Distributor
• Spoke page: Restaurant Chain Digital Transformation: +$450K Annual Revenue from Direct Orders, 32% Lower Delivery Commissions
• Commercial page: SaaS Development – Custom SaaS Platform Development Company