How We'd Approach It
Three detailed walkthroughs showing how we think through real problems. The companies are fictional. The patterns are real.
The SaaS Company With 47 Tools
The Company
A 280-person B2B SaaS company. Series B funded, growing 40% year-on-year. Engineering team of 45, operations team of 20.
The Problem
The CEO asks "what’s our customer lifetime value?" and gets three different numbers from three different teams. The CRM says one thing, the billing system says another, the finance team’s spreadsheet says a third. Nobody trusts any of them. The company has 47 software tools - many overlapping, some unused, a few that nobody remembers purchasing. Two full-time people spend most of their week manually moving data between systems. The VP of Engineering wants to build an AI-powered customer health dashboard, but the data it would need lives in six different places.
What most firms would do
- × A CRM consultant would recommend migrating to a better CRM
- × A data consultancy would propose a data warehouse project
- × A dev agency would build the AI dashboard on top of the existing data landscape
- × A Big 4 firm would produce a 60-page digital transformation roadmap
What we'd actually do
We’d start with a diagnostic. Two to three weeks mapping every system, every data flow, every manual process. The findings would show high friction, but not yet critical. The diagnostic would reveal that the AI dashboard isn’t the priority. The priority is that the company doesn’t have a single source of truth for customer data. Until that’s fixed, anything built on top of it will be wrong. We’d recommend a Focused Build: a customer data integration that connects the CRM, billing system and product analytics into one reliable pipeline. Not a data warehouse - that’s overkill at this stage. A targeted integration that gives every team the same numbers. Cost: roughly £40-60K. Timeline: 6-8 weeks. Once the data flows, the AI dashboard becomes a straightforward build on clean foundations - not a science project built on unreliable inputs.
The outcome
The CEO gets one set of numbers. The two people doing manual data work get their time back. The AI dashboard project - when it happens - works on the first attempt because it’s built on data everyone trusts. And the company has a clear baseline it can track as it grows.
The Fintech That Couldn’t Scale
The Company
A 180-person fintech. Regulated, growing fast, recently expanded from one product to three. Technology team of 30, mostly engineers.
The Problem
Every new product launch takes twice as long as the last. The original platform was built for one product and the team keeps bolting new functionality onto it. Deployments are fragile - a change to one product can break another. The compliance team spends two days per month manually compiling audit reports that should be automatic. Three key engineers hold all the architectural knowledge in their heads and the CTO is worried about what happens when one of them leaves. The board is pushing for a fourth product by Q3, but the CTO knows the current architecture can’t support it without something breaking.
What most firms would do
- × A staffing agency would provide contract engineers to build faster
- × A dev agency would start building the fourth product on top of the existing architecture
- × A Big 4 firm would recommend a full platform rewrite - 18 months, £2M+
- × A fractional CTO would write a technology strategy document
What we'd actually do
We’d start with a diagnostic focused on the Systems and Knowledge dimensions. The immediate finding: the architecture doesn’t need a full rewrite. It needs targeted decoupling - separating the shared services from the product-specific logic so that products can be deployed independently. The knowledge concentration risk is the urgent problem. We’d propose a Systems Reset Programme: 4-6 months. Month one: architecture redesign and documentation sprint - capturing everything those three engineers know into systems and documentation the whole team can use. Months two to four: targeted platform changes to decouple the products. Month five onwards: compliance automation and the architectural foundation for product four. Cost: £30-45K per month. The board gets their fourth product capability, but built on foundations that won’t break when product five comes along.
The outcome
Deployments become independent per product. The compliance reporting that took two days now takes 20 minutes. The knowledge risk drops dramatically because the architecture is documented and the team is cross-trained. The fourth product launches on schedule - and the fifth one will be faster, not slower.
The E-Commerce Platform That Needed AI Yesterday
The Company
A 350-person e-commerce company. Profitable, £80M revenue, 12-person technology team. No dedicated data or AI capability.
The Problem
The commercial team wants AI-powered product recommendations. They’ve seen what competitors are doing and the CEO has made it a board-level priority. The technology team has investigated three off-the-shelf AI recommendation engines but none integrate cleanly with the existing platform. A previous attempt with a freelance ML engineer produced a proof of concept that worked in isolation but couldn’t be deployed to production because it needed data that lived in four different systems, none of which had APIs. The commercial team is frustrated. The technology team feels blamed for something that isn’t a technology problem.
What most firms would do
- × An AI consultancy would build another proof of concept
- × A dev agency would build custom integrations to force-fit an off-the-shelf solution
- × An AI vendor would sell a platform that requires six months of data preparation
- × A management consultancy would produce an "AI strategy" document
What we'd actually do
We’d question the brief. The company doesn’t have an AI problem - it has a data connection problem. The recommendation engine (whether built or bought) needs clean, accessible product and customer data. That doesn’t exist yet. We’d propose a Focused Build in two phases. Phase one (4 weeks, ~£25K): build the data integration layer - connect the product catalogue, customer behaviour data, purchase history and inventory systems into a unified data pipeline with proper APIs. Phase two (4-6 weeks, ~£35-50K): build the recommendation engine on top of the clean data. We’d likely use a hybrid approach - proven algorithms for the core recommendations, with LLM capability for things like natural language product search and personalised merchandising copy. The key insight: phase one has value even without phase two. Once the data flows, the technology team can build better search, better reporting, better inventory management - not just recommendations. The data layer is the real asset.
The outcome
The recommendation engine launches and works from day one because it’s built on reliable data. The commercial team gets their board-level priority. The technology team gets a data infrastructure they can build on for years. And the company discovers that the data integration work identified £120K in inventory inefficiencies that had nothing to do with AI.
The Common Thread
In each of these, the real issue wasn't what it looked like on the surface. The AI company had a data problem. The scaling company had a knowledge problem. The e-commerce company had an integration problem. The solution in each case started with stepping back and understanding how things actually connected.