Everyone talks about scaling. Growth targets. Expansion plans. Hockey stick curves. But nobody really talks about what breaks first when you go from standing start to £700m processed across 220,000 loan applications in three years. The responsibility is massive. To the business. To the 600+ retailers we've worked with. To the end customer sitting in a showroom waiting to find out if they can afford their new kitchen.
The Tech Breaks Before Anything Else
When we hit scaling challenges at Shermin Finance, the first thing that cracked was our technology stack. Specifically: the lender APIs, the workflows tied to them, and the error handling that assumed everything would work the way the documentation from the build said it should. One lender's API would timeout after 8 seconds but not return an error. Applications would just sit there. In limbo. The customer waiting. The retailer waiting. Everyone assuming something was happening when nothing was happening. We only found out when retailers started calling. "Why hasn't this application gone through?" "Why has this been pending for an hour?" "Is your system down?" The documentation never mentions how to handle this behaviour. The sandbox testing never revealed it. It only emerged at volume, when you're pushing hundreds of applications through and suddenly the edge cases aren't edge cases anymore. They're Tuesday afternoon. A startup typically grows gradually. You add users month on month. You make mistakes, you fix them, you iterate. You learn as you go. By the time you're processing significant volume, the problems have been discovered and solved in smaller increments. We didn't have that luxury. As an established broker operating across 250+ home improvement and renewables retailers at any one time, we immediately had thousands of concurrent users on the platform from day one of any new process. There's no gentle ramp-up. No chance to beta test with a small cohort. When something breaks, it doesn't break for five users. It breaks for everyone.
The Platform Advantage
One of the biggest surprises during this scaling phase was how much competitive advantage came from owning our own platform. When you're a broker working with 5-6 lenders via waterfall decisioning, you're constantly walking a tightrope. You're dependent on each lender's API availability, their decision speed, their willingness to work with you. Our platform gave us something critical: flexibility without friction. If a retail partner needed to change how they worked with a particular lender, or if we wanted to switch to a new lender entirely, or adjust our waterfall strategy, we could do it without retraining staff or losing data continuity. We didn't have to rebuild processes. We didn't have to ask the retailer to update their systems or their people. Think about the alternative. If you're a broker without your own platform, operating through white-label or third-party systems, you're constrained:
- Change a lender? Everyone downstream has to adapt
- Want to modify your decisioning strategy? Hope your infrastructure supports it
- Need data continuity across partner changes? Good luck We could iterate our lender relationships, pivot our strategy, and optimise our waterfall without any impact on our retail partners. At scale, that's transformational.
What Actually Had to Be Rebuilt
Not everything broke at once, but certain things clearly couldn't scale as they were. We had one person who knew how to set up the waterfall of rate cards. One person. When they went on holiday, decisions queued for a week. That's not a process. That's a single point of failure dressed up as a process. We had to systemise everything. Build internal training as a real function. Documentation, videos, ongoing support. What worked as ad-hoc knowledge transfer couldn't survive 600+ retail partners and thousands of staff across those partners. Some of the waterfall workflows had genuine architectural issues too. They weren't designed for the volume they now had to handle. Not just the speed, but the complexity of managing multiple lender responses, handling timeouts, managing fallback options when a lender was slow or unavailable. These required proper engineering work and real rethinking of how the system functioned.
The Scale of the Business
To give you the full picture: Shermin Finance is now the largest consumer credit brokerage in the UK. We work with 5-6 lenders through waterfall decisioning. We have served 600+ home improvement and renewables retailers since launch. We've processed £700m across 220,000 loan applications in three years from a standing start. We're FCA regulated, which itself adds layers of compliance, reporting and infrastructure requirements that don't exist in the same way for smaller operations. The UK consumer credit market is substantial:
- New consumer lending through credit cards alone reached nearly £23 billion in February 2024
- The entire FLA member market provided over £116 billion of consumer credit in 2024 We're operating in a market where infrastructure failures don't just affect us. They affect retailers, their customers, and ultimately, our lenders. That forces you to think about systems differently than you do when you're small.
What I'd Do Differently
If I was building this again, knowing what I know now: API resilience and error handling. Not as an afterthought. The moment you know you're going to scale, you need to assume your lender APIs will fail in weird ways. Build for those failures before you need to. Timeouts that don't return errors. Responses that come back malformed. Servers that go down at 3pm on a Friday. Plan for all of it. Monitoring and observability. You need to see problems before your retailers call you. At scale, problems are silent until they're catastrophic. Real-time monitoring isn't optional. Training and knowledge systems. Systemise this early. No single points of failure. If one person going on holiday means your rate card configuration stops, you've already failed. Waterfall architecture. If you're managing multiple lender relationships, your waterfall is a technical architecture decision. Design for flexibility from the start. Regulatory infrastructure. FCA regulation brings compliance requirements that scale with your business. Build this in properly from the beginning. Technical debt here is dangerous.
The Real Takeaway
Scaling from zero to £700m in three years looks impressive on a spreadsheet. In reality, it's exponentially harder operationally. The problems you face aren't just "more of the same." They're different problems entirely. Your technology breaks in ways you didn't anticipate. Your processes need to be rebuilt, not just expanded. Your team structure changes. Your regulatory obligations intensify. But if you get it right? If you build platforms that give you flexibility without adding fragility? If you invest in proper infrastructure early? Then you end up with something genuinely competitive. A business that can:
- Adapt faster than your competitors
- Partner effectively with 600+ retailers without them having to change a thing
- Manage multiple lender relationships without losing capability when you change strategy That's worth the pain of scaling. That's worth the sleepless nights when the API timeouts stack up. That's worth rebuilding the systems that got you started because they won't get you to where you need to go. The retailers depending on you. The customers waiting for an answer. The responsibility that comes with being the infrastructure between lenders and the real world.That's what scaling actually means.
Sources
- 2024 Guide to Fintech Platform APIs & Integrations
- Fintech API Integration: Challenges and Best Practices
- UK New Consumer Lending Statistics 2024 - Statista
- Bank of England Money and Credit December 2024
- Finance & Leasing Association Consumer Finance Statistics
- Waterfall Lending: Enhancing Approval Rates
- Multi-Lender Waterfall Technology for Point of Sale Financing
- FCA Consumer Credit Brokers Authorisation
- Why FCA Authorisation Matters for Credit Brokers
- Scaling a FinTech Lending Platform to Enable Growth