Skip to content
T.E.N.E.G.T.A
Language
← All case studies

Financial Technology · Enterprise SaaS Platform — from pilot with 3 clients to production with 40+ institutions

From Pilot to Production: Engineering SaaS Built for Real Scale

How we re-architected an enterprise platform that scaled from 3 to 40+ clients in 6 months — reducing p95 latency by 60% and enabling a 12 deployments/month release cadence.

10 min read

Problem

The platform worked acceptably with 3 pilot clients. But when the team tried to scale it to 40+ institutions, the real problems emerged: - Every new client required manual code changes (hard-coded configurations) - The shared database schema leaked data between tenants in edge cases - Response times rose non-linearly with load increases - The 8-person dev team spent 40% of their time on manual deployment and fixing different environments The code "worked" — but it wasn't designed for growth.

What we built

We started with an honest "Architecture Audit" — not selling the team a solution before understanding the root cause. In the first two weeks, we mapped every dependency and every weakness. First strategic decision: don't rewrite from scratch. Improve what exists incrementally without stopping production. 3-phase plan: 1. **Isolation** — securely separate tenant data (Row-Level Security + schema-per-tenant for sensitive clients) 2. **Performance** — rewrite N+1 queries, Redis caching, connection pooling 3. **Automation** — full CI/CD pipeline, Infrastructure as Code, tenant onboarding in under 10 minutes

Outcome

In 6 months: scaled from 3 to 40+ institutions on one platform, ~60% lower p95 latency, and 12 production deployments per month without downtime — with tenant isolation verified in testing.

Architectural decisions

  • Row-Level Security over Application-Level Filtering

    Application filtering can be bypassed by a single bug. RLS in the database makes data leakage impossible even if there's a code error — because the database itself enforces boundaries.

  • Trunk-Based Development + Feature Flags

    The old way: long branches causing merge hell. The new: the whole team writes to one trunk with feature flags controlling activation — enabling 12 deployments/month without chaos.

  • Observability First — Not Monitoring

    Monitoring tells you there's a problem. Observability tells you why. We deployed OpenTelemetry across the full stack — traces, metrics, logs in one place — because debugging in multi-tenant without observability is digging in the dark.

Technical challenges

  • Migrating 3 existing clients' data to the new schema with zero downtime

    We used the Expand-Contract Migration pattern: added the new schema alongside the old, dual-wrote during transition, then cut over after verification — all without stopping production.

  • Some enterprise clients refusing shared data even with RLS

    We built a hybrid model: schema-per-tenant for those requiring full isolation, shared schema + RLS for others — both running on the same codebase with a single config.

Architecture

Node.jsTypeScriptPostgreSQLPrismaRedisDockerKubernetesGitHub ActionsOpenTelemetryGrafanaTerraformNext.js

Results

−60%

p95 Latency Reduction

12×

Monthly Deployment Cadence

< 10 min

New Tenant Onboarding Time

6 months

Pilot to Production Scale

“I feared 're-architecting' meant 'delayed by a year.' T.E.N.E.G.T.A proved that good re-architecture doesn't slow you down — it liberates you.”
Chief Technology Officer — Enterprise SaaS Platform

Representative quote for discussion — composite scenario aligned with this archetype, not a named client endorsement unless stated otherwise.

These case studies are illustrative summaries for discussion. They are not guarantees of results for your organization unless confirmed in a separate agreement.

Related case studies

Discuss a similar engagementExplore solution pillarTry the interactive demo