Case Studies

Scaling product performance

Situation

A startup going into a growth phase was starting to get complaints from existing customers about the speed of the product. To keep performance up, their hosting costs were soaring. The system was about to reach its limit with the next big customer.

Approach

We assessed the solution design to understand where load and latency problems occurred. We showed that there was no-one place that was the problem. Rather each small problem added up because fixes had been incrementally added throughout the system. The solution was to have a simple cohesive solution. We added monitoring and tests, shifted hosting with automated deployments, and most importantly showed how a single generic, rather than customised, approach to retrieving data is actually robust, faster and less intensive.

Outcome

We did not have to rewrite the system to get the desired performance at scale. Rather we made sure that by doing less, the performance goals were able to be met and that developers were also better able understand what the system does and evolve it to meet new customer demands.


Enabling digital business & building capability

Situation

The company was struggling to release software and each release seemed to be slower and more expensive with the increase of customers. We assessed that the startup could not build software to meet customer demand without a build and deploy pipeline that the team uses and is in control of.

Approach

We reviewed the current technology stack and found that it was cumbersome and expensive and didn’t enable everyone to have a shared view. We then added new servers and virtualisation platform that would scale in performance and cost to meet development demands. We then added the best of breed tools to create a deployment pipeline appropriate to the team size that facilitated communication.

Outcome

By introducing the platform, it is possible to see what is being built, its rate and quality. The team also built the capability to tune cloud systems and deploy to them automatically and securely. The cost of the new platform was paid back in six months and they now have access to fast and cheap virtual machines.


Onboarding new customers via an API

Situation

The startup’s new growth plan required the ability to onboard new customers in hours/days. The current capability took weeks and required developers. The goal is to build a scalable onboarding process balanced against all the other work that needed to be completed to meet the new customer demand.

Approach

We used a derivation of an approach called a “strangler application”—rather than try and replace the current approach we wrapped the existing system such that both systems are operating at the same time. The new system “API” allowed us to rapidly model the current system and provide new functionality without breaking the existing system.

Outcome

We delivered an approach which in the first instance was faster and cheaper, and in no way perfect but very workable. It was, importantly, more reliable and did not introduce unseen errors. We saw an 8-times speed improvement to onboard new customers dropping from 50 hours down to 6 hours per customer.


Generic hosting approach to reduce costs and vendor lock-in

Situation

The startup’s hosting costs were steadily increasing and often unpredictable—particularly as the solution was requiring more 'grunt' to scale to larger customers. They were also finding that because they were using technologies and approaches specific to the vendor they were increasingly getting vendor lock-in thereby reducing their options.

Approach

We took an approach that found that it was best to have a mix of public and private hosting. We removed all vendor specific technologies such that we could deploy to both public and private cloud. We then installed on-site private cloud infrastructure and also changed one of the public cloud providers that had the correct pricing structure for the performance we required.

Outcome

The hosting costs have reduced by 50% month-on-month and the new in-house infrastructure had a payback period of three months. The private hosting allows zero-cost, immediate creation of new development capacity as required. The public hosting increases only at a cost-effective proportion of the rate of customer increases.