Building a Multi-Tenant SaaS Platform: 0 to $2M ARR in 14 Months
Full-Stack Engineering for a PropTech Startup
The Challenge
A UK PropTech startup had a validated concept and seed funding but no technical co-founder and 18 months of runway. They needed to go from zero to a revenue-generating, scalable SaaS platform within 12 months — without taking on technical debt that would halt growth. Their domain required multi-tenancy with strict data isolation (GDPR), complex search over property listings, document generation, an integrated payment flow, and a mobile-first experience for field agents.
Our Solution
We assembled a four-engineer squad (2 full-stack, 1 infrastructure, 1 QA) and built iteratively over 52 weeks. **Architecture decisions:** - Row-level security (RLS) in PostgreSQL via Supabase for multi-tenant data isolation — no shared schema complexity - Next.js 14 App Router frontend with a dedicated NestJS API service for complex business logic - Elasticsearch (via Elastic Cloud) for property search — full-text, geospatial, and faceted search - Gotenberg for server-side PDF generation (tenancy agreements, offer letters) - Stripe with Stripe Connect for multi-party payments (platform fees + landlord payouts) - Expo React Native app for field agents sharing the same NestJS backend **Engineering practices:** - Feature flags (Unleash) from day one — enabled trunk-based development without release freezes - Playwright E2E tests on all critical user journeys (CI gate) - OpenAPI spec auto-generated from NestJS decorators — frontend type safety via openapi-typescript
Results & Impact
Client
Confidential PropTech Startup (Seed, UK)
Frequently Asked Questions
Why Supabase RLS over a separate database per tenant?+
Separate databases per tenant (database-per-tenant isolation) is operationally expensive at scale — schema migrations become a fleet operation. Row-level security in PostgreSQL gives strong isolation with a single schema, and Supabase's auth integration makes RLS policy management straightforward.
How did you handle the 52-week delivery without scope creep?+
We used Shape Up's 6-week cycles with a betting table at the start of each cycle. Feature requests that arrived mid-cycle were queued for the next bet, not added to the running cycle. This maintained predictable delivery while keeping the backlog managed.
Want similar results for your business?
Let's discuss your project. Free consultation, no obligation.
Start a Conversation