What was working
The business had a strong product direction and a team that was trying to do the right things under pressure. Some interfaces and team behaviours were functioning well, particularly around product-to-engineering alignment.
Case Study
A growing business had outpaced the technology it was built on. The issue was not a lack of ambition; it was a mismatch between growth, architecture, and the team’s delivery rhythm.
I was approached by a company that was expanding its fledgling SaaS business. It was hitting operational and technical ceilings that threatened to stall several years of growth. The size of their dataset was outgrowing the platform originally chosen, and the business was increasingly constrained by slow feature delivery and weak access to usable operational insight.
The core concerns were familiar to many growing businesses: engineering efficiency, delivery pace, and whether the company’s data foundations could support the level of growth it was aiming for. In short, the underlying platform was no longer fit for the business it was becoming.
The business had a strong product direction and a team that was trying to do the right things under pressure. Some interfaces and team behaviours were functioning well, particularly around product-to-engineering alignment.
The data platform was not fit for the size of dataset or the future commercial goals of the business. Access to data was inconsistent, which created duplicate engineering work, inconsistency bugs, and unnecessary technical debt.
The combination of poor data foundations and uneven engineering practices was slowing delivery and reducing confidence in the platform’s ability to support scale.
I prioritised two main actions. First, I recommended raising the technical bar through a strong technical lead who could mentor the team, improve standards, and create more consistent delivery practices. Second, I recommended a new approach to the data architecture so it could support current needs and future growth without creating more handbrake.
The proposed direction was an API-first model: a single data gateway to serve existing systems, while allowing third-party integration and a phased migration away from the outdated platform with minimal business disruption.
In the delivery phase, I provided technical leadership to the engineering team for several months to improve standards and process. I also drew on my network to recruit contractors who could hit the ground running while helping the team level up. The goal was not just to fix the immediate platform issues, but to build a more stable base for future product work.
The work included improving engineering quality, strengthening data access patterns, and setting up a path that would support better reporting and more useful customer insight. The result was a clearer, more durable foundation for commercial growth and recurring platform improvements.
Overall, the business achieved a step-change in capability. Engineering efficiency improved, release confidence grew, and the platform became better able to support a larger dataset and more meaningful customer insight. After six months, a follow-up review showed clear improvements across the original scoring areas.
In commercial terms, the company was also able to secure approximately £1m in additional license revenue over the next two to three years. The new API model also made third-party integration easier and helped lock in longer-term partnerships with customers.
If your software or data platform is starting to hold back growth, a short conversation can help identify the next practical steps without the usual sales noise.