From weekly outages to daily deployments: scaling a SaaS platform without stopping delivery

Client Overview

NovaPlatform is a B2B SaaS company based in the Netherlands that provides a customer operations platform for mid-market retail and logistics businesses. The company had grown from 500 to over 5,000 active customer accounts over 18 months. Rapid growth was a success, but it exposed the limits of a codebase that was never designed for this level of scale.

The Challenge

The platform had been built quickly during the early startup phase, as most good MVPs are. The technical decisions made at 500 customers were no longer holding at 5,000. A tightly coupled monolith meant that a fault in any one module could bring down the entire platform. Deployments required taking the system offline. The team was releasing updates only once per week because the deployment process was risky and manual. During peak usage hours, database contention caused slowdowns that frustrated customers and generated a steady stream of support tickets.

The engineering team was spending more time managing incidents than building new features. That had to change.

The Solution

PTM Software recommended a targeted re-architecture, not a full rewrite. A complete rewrite would have taken six to twelve months and frozen feature development during that period. Instead, we identified the two modules generating the most load and the most instability, extracted them as independently deployable services, and introduced the infrastructure needed to support this approach. This delivered measurable improvement within weeks while the rest of the platform continued operating and the product team continued shipping features.

Technical Architecture

The primary bottleneck was the customer data module, which was being hit by every API call across the platform regardless of whether it was relevant. We extracted this into its own service with dedicated database resources. We introduced PostgreSQL read replicas to distribute query load away from the primary write database. Redis caching was added for high-frequency read patterns (data that changed infrequently but was being queried thousands of times per hour). All services were containerised using Docker, enabling consistent deployments across environments. A CI/CD pipeline replaced the manual release process with automated testing, container builds, and zero-downtime deployments.

• Service extraction for the two highest-load platform modules
• PostgreSQL read replicas to offload query pressure from the primary database
• Redis caching layer for high-frequency, low-change data patterns
• Docker containerisation for consistent and reproducible deployments
• CI/CD pipeline with automated testing, staging gates, and zero-downtime releases
• Monitoring and alerting integration for post-deployment performance validation

How We Delivered It

The engagement ran over 12 weeks in three phases. Phase one established the new infrastructure and deployed the first extracted service in shadow mode, running alongside the existing monolith, receiving traffic, but not yet serving responses. This allowed the team to validate performance under real load without customer impact. Phase two switched live traffic to the new service and retired the equivalent module from the monolith. Phase three delivered the CI/CD pipeline and Redis caching layer. Throughout the engagement, zero customer-facing downtime was incurred during any migration step.

Results

Lessons from This Engagement

The instinct to rewrite legacy systems is understandable, but it is rarely the fastest path to reliability. A targeted, phased re-architecture that extracts the highest-impact modules first delivers measurable improvement in weeks rather than months, keeps the product team shipping features throughout, and reduces the organizational risk of a prolonged rebuild. The key is identifying the right bottlenecks to address first, not attempting to fix everything at once.