Case Study - B2B SaaS company Big Bang

Updated: Jun 3

Background


A 26-year-old medium-size B2B SaaS company that is in the expansion stage with a $65M revenue and a potential $800M TAM. The company has 9 development centers (a bit excessive for the revenue) in different countries that are each responsible for their respective geographies for sales and product development. The core product is a B2B connecting buyers and sellers. The initial product was duplicated years ago and handed off to each office to fork and build on top of it for their local markets. Eventually, the products became disparate with similarities, but a distinct codebase. No cross-company planning, configurability, or shared components.


Over the years, a reduced market opportunity, severe technical debt slowing down the ability to innovate, and increasing customer churn due to dissatisfaction prompted an action to explore modernization.


What Happened


The leadership team embarked on a consolidation plan that would allow them to create one consolidated platform with cohesive data and high configurability to work in all countries. The intention is to eventually speed the time to market, reduce maintenance costs and increase the product quality.


The team worked on a new architecture and under the leadership of a new ambitious CTO who has not as experienced in conducting a modernization effort. They used a big bang approach. After one year, they realized that the challenge was too great and the architecture choices they made would not be able to accommodate what they are trying to build. They went back to the drawing board and spend a few months re-planning and then embarked on a second big bang round. With the team losing steam and ramping up to a new architecture and technology stack, the effort lost momentum again and some resources had to be assigned to handle the current platforms and urgent customer requests.


At this point, they had acquired two new platforms on top of the original 9 and both had customers onboarded on them as well further bifurcating the data. The CTO was let go and a new CTO was hired who decided that the engineering muscle in the team is outdated and the best course is to outsource the effort. They outsourced to a dedicated team offshore and after 2 years, a new platform was ready in true big-bang form. The new platform was not tested with clients and was developed in silo offshore. In the end, the quality was a complete surprise with very poor code quality, loads of technical debt, and the performance was extremely slow rendering the platform unusable for the clients that were onboarded on it.

With a decreasing reputation, eroding clients’ trust, and 12 separate platforms that essentially do the same thing to maintain, decreasing revenue, the choices were limited and the hope was nearly lost.


A new management team was hired to salvage what’s possible. The CEO and CTO both had solid experience in transformation. They hired a chief architect and external experts to deep dive and study the various architectures in place, the codebases, and the organization.


Armed with the current state, target state, a new modern architecture plan, and a target future organization, they comprised a new plan and underwent agile and DevOps training. They decided to put together a small team of 6 developers, one architect, 3 QA engineers, and a product manager. The rest of the team was dedicated to maintaining the current platforms. The team spent some time setting up a healthy SDLC and infrastructure in place.

They pursued an incremental approach and recognized that the value of the platform is in the data and configurations which serve different customers, remove the need for customizations, and accommodate regulatory compliance.


They selected one of the existing platforms which have the most promise after conducting sufficient testing to confirm. The initial focus was to tackle some architectural improvements and building a new data architecture.


The next step was assembling a backlog for the existing code base with decisions on various components choosing between (build, refactor, or deprecate). The list of prioritized and added to their roadmap.


The approach helped them produce a functional beta within 5 months. The next step was to pilot 3 customer migrations on the platform. They evaluated the decision to ensure that the choice would provide a healthy segment of customers, smaller in size to minimize the effort, and representing multiple geographies. The effort proved successful and allowed them to incrementally migrate the customers while helping them improve the data mapping and architecture in place.


As the platform matured, they prioritized a list of customers and began the assisted migration process while minimizing any customer impact. As the customers were migrated from older platforms, they were progressively retired.


The effort and cost were ultimately a fraction of the cost and time spent in prior efforts. The company managed to preserve their remaining clients and set themselves with a new team, a modern engineering approach, slashed their R&D spend by 40%, and found a path forward to grow.


Key Takeaways

  1. Staffed leadership with modernization experience

  2. Spent time in planning initially with the help of external experts

  3. Accepted the need for the investment and the time it will take to tackle

  4. Started with a small team and invested in their capabilities

  5. Took an incremental and agile approach

  6. Leveraged pockets of quality in the existing codebase