How Webskyne Redesigned a Legacy SaaS Platform and Cut Page Load Times by 62%

## Overview In early 2025, a mid-market SaaS company in the operations-management space reached out to Webskyne with a familiar problem: their product had grown faster than its foundation. What began as a lean MVP had evolved into a complex platform serving thousands of business users, but the underlying architecture, frontend bundle, and deployment pipeline had never been systematically revisited. The result was a product that was increasingly difficult to maintain, slow to ship, and frustrating for end users. Over the course of six months, Webskyne partnered with the client's engineering and product teams to modernize the platform end to end. Our work spanned backend service decomposition, frontend performance optimization, database query tuning, and a complete redesign of the CI/CD pipeline. The engagement concluded with a 62 percent reduction in median page load time, a 40 percent drop in infrastructure costs, and a significantly improved developer experience. ## Challenge When we first assessed the platform, three major challenges became immediately clear. First, the frontend was built on a monolithic AngularJS application that had been incrementally patched over several years. Routing was handled by a custom, undocumented system. Third-party dependencies were deeply coupled, and the production bundle exceeded 4.2 MB gzipped. Users on slower networks routinely experienced load times above twelve seconds. Second, the backend consisted of a single Node.js service that handled authentication, billing, project management, and reporting APIs in one process. This monolith made it difficult to allocate resources efficiently, test individual features in isolation, or scale components independently under load. Third, the deployment process was entirely manual. Each release required a maintenance window, and rollbacks often took longer than the issues they were meant to fix. The team lacked proper observability, making it difficult to pinpoint performance regressions until customers reported them. These issues were not merely technical—they were business risks. The client's renewal rate had begun to slip, and the engineering team's morale was declining under the weight of constant firefighting. ## Goals We established clear, measurable goals at the start of the engagement. 1. Reduce median page load time to under two seconds for core user workflows. 2. Refactor the backend into independently deployable services for billing, project management, and reporting. 3. Decrease infrastructure cost by at least 20 percent through right-sizing and improved caching. 4. Automate the deployment pipeline to eliminate manual maintenance windows. 5. Improve developer onboarding time and reduce context switching caused by architectural complexity. These goals were intentionally ambitious, but they were grounded in data gathered from Real User Monitoring (RUM) and application performance monitoring (APM) tools that we integrated during the first week of the engagement. ## Approach Webskyne favors a pragmatic, iterative modernization strategy over big-bang rewrites. We began by establishing a performance baseline that would serve as our north star throughout the project. Our approach centered on four pillars: - **Incremental decomposition.** Rather than rewriting the application from scratch, we identified service boundaries using a combination of domain-driven design (DDD) and dependency analysis. We then extracted one service at a time, ensuring that each extraction was production-safe and fully tested before moving to the next. - **Frontend performance as a first-class requirement.** We treated every performance regression as a bug and integrated Lighthouse CI into the pull request pipeline. This gave the team immediate feedback on bundle size, rendering performance, and accessibility. - **Observability-driven development.** We deployed distributed tracing, structured logging, and custom dashboards early in the process. This allowed us to catch issues in staging before they reached production and to quantify the impact of every change. - **Team enablement.** We embedded Webskyne engineers directly alongside the client's team, pairing on complex migrations and documenting decisions in a shared engineering log. Knowledge transfer was not an afterthought; it was a deliverable. ## Implementation The implementation unfolded in three distinct phases. ### Phase 1: Stabilization and Baseline (Weeks 1–4) During the first month, our priority was to stop the bleeding. We optimized the most painful database queries, introduced Redis caching for frequently accessed reference data, and patched critical security vulnerabilities in the legacy AngularJS frontend. We also deployed lightweight observability tooling—Prometheus for metrics, Grafana for dashboards, and structured JSON logging. These quick wins delivered immediate value. Median API response time dropped from 450 ms to 180 ms, and the operational team gained visibility into system health for the first time. ### Phase 2: Architecture Modernization (Weeks 5–16) With stability established, we began the more complex work of service extraction. We started with the billing domain, which was both high-risk and high-value. By moving billing into its own service with its own database and API, we eliminated a major contention point in the monolith. Simultaneously, we began rewriting the frontend in Next.js. Rather than attempting a full rewrite, we adopted a strangler-fig pattern: new routes were built in Next.js and served alongside the AngularJS application. Over time, traffic migrated to the new frontend, page by page. Database optimization was another critical focus. We introduced read replicas to handle reporting workloads, added proper indexing on high-traffic tables, and replaced raw SQL queries in several hotspots with parameterized queries and stored procedures where appropriate. ### Phase 3: Pipeline and Culture (Weeks 17–24) The final phase focused on the deployment pipeline and team practices. We replaced the manual release process with GitHub Actions workflows that included automated testing, security scanning, and progressive rollouts using feature flags. We also introduced blameless postmortems and a shared on-call rotation. These cultural changes reduced mean time to recovery (MTTR) by 35 percent and gave the client's team greater ownership of the system. ## Results The results of the engagement exceeded our initial targets. Within three months of launch, median page load time had fallen from 4.8 seconds to 1.8 seconds—a 62 percent improvement. The new Next.js frontend delivered a production bundle that was 71 percent smaller than the legacy AngularJS application, contributing directly to faster first-contentful paint and time-to-interactive metrics. Backend decomposition allowed the team to scale the billing service independently during peak subscription periods, while the read replicas reduced reporting query times from an average of 3.2 seconds to 420 milliseconds. Infrastructure costs declined by 40 percent, driven by better resource utilization, the elimination of unused servers, and the replacement of expensive third-party monitoring tools with open-source alternatives. The automated deployment pipeline reduced release cycle time from an average of fourteen days to less than two days. Rollbacks that previously took hours could now be completed in under fifteen minutes. Most importantly, the client's engineering team reported a significant improvement in job satisfaction, citing reduced firefighting, clearer ownership boundaries, and faster feedback loops. ## Metrics | Metric | Before | After | Change | |---|---|---|---| | Median page load time | 4.8 s | 1.8 s | –62% | | Frontend bundle size | 4.2 MB | 1.2 MB | –71% | | Median API response time | 450 ms | 180 ms | –60% | | Reporting query time | 3,200 ms | 420 ms | –87% | | Deployment cycle time | 14 days | 2 days | –86% | | Infrastructure cost | ,500/mo | ,100/mo | –40% | | MTTR | 4.2 h | 2.7 h | –35% | These metrics were gathered over a six-week observation period following the production launch and reflect steady-state performance under normal traffic conditions. ## Lessons Learned Every modernization effort carries lessons that apply well beyond a single client engagement. Here are the takeaways that shaped our thinking during this project. **Start with observability.** You cannot improve what you cannot measure. The dashboards and alerts we deployed in the first week became the foundation for every subsequent decision. They gave the team confidence to make changes and provided objective evidence of success. **Prefer incremental extraction over rewrites.** A full rewrite would have required a dedicated team, taken at least twice as long, and introduced significant business risk. By strangling the monolith gradually, we delivered value continuously and maintained a working system throughout the transition. **Frontend performance is a product feature.** Users do not distinguish between a slow backend and a slow interface. An optimized API means nothing if the browser cannot render the result quickly. Treating frontend performance as a first-class requirement—complete with CI enforcement—changed the team's culture as much as it improved the numbers. **Invest in the team, not just the system.** The best architecture will fail without a team that understands it. By embedding with the client's engineers, documenting decisions, and establishing sustainable practices, we ensured that the improvements would outlast the engagement. This case study illustrates why Webskyne takes a full-stack, human-centered approach to platform modernization. Technology is the medium, but people and processes are the message.