Jem Walters spent 23 years at Virgin Money, the last stretch as CIO, before deciding he wanted to build something of his own. What followed was Snoop — a money-saving app that launched in 2019, scaled through a pandemic, and was acquired by banking group Vanquis in July 2023. Walters is now CTO at Vanquis, which means he navigated the full arc: idea, build, exit, and integration. That's a rarer perspective than most startup advice columns acknowledge.
What makes his experience worth examining isn't the acquisition itself — plenty of startups get bought — but the specific decisions the Snoop team made early on that held up under pressure. The lessons aren't particularly glamorous, but they're the kind that separate ventures that survive due diligence from those that fall apart when a potential acquirer starts looking under the hood.
The Six-Week Rule Nobody Talks About
Walters' first and most counterintuitive piece of advice: don't write code on day one. The Snoop team spent their first six weeks on a proper feasibility assessment — examining what it would take to build the product, identify the right technology stack, find necessary partners, and map out a realistic customer acquisition path.
This might sound obvious in retrospect, but the startup culture of "move fast" actively discourages this kind of deliberate pre-launch thinking. Accelerators reward demo days. Investors want traction metrics. The pressure to ship something — anything — is enormous and starts almost immediately. Walters is pushing back against that pressure directly.
The feasibility work at Snoop wasn't theoretical either. Open banking regulation in the UK, introduced through PSD2 (the EU's Revised Payment Services Directive), had created an infrastructure that allowed third-party apps to access customers' banking data with their consent. The Snoop team recognized this as the technical foundation they needed, but spent those six weeks asking a harder question: could they move beyond data aggregation and offer genuinely actionable financial guidance?
"We thought about whether we could come up with a 'so what' and give people personalized hints and nudges," Walters explains. That framing — "so what" — is a useful test for any product idea. Data presentation alone rarely sustains a business. The insight layer on top of it is where defensible value gets built.
Outsourcing the Build Without Surrendering the Asset
Rather than hiring a full in-house engineering team from day one, Snoop partnered with two specialist agencies: Inawisdom for data and analytics, and Hi Mum! Said Dad for product and mobile development. This isn't unusual for early-stage startups managing runway. What was unusual was how explicitly Walters' team defined the terms of that relationship from the start.
The agencies knew upfront that they were building a codebase the startup would own entirely, and that as Snoop scaled, internal hires would progressively replace agency talent. "We said to them from the outset that, 'When we're done, this service is going to be run by a Snoop team employed by us. It's our code base. We own the IP,'" Walters said. That transition took roughly two years.
This approach addresses a problem that quietly kills a significant number of acquisition deals. When a buyer examines a startup and discovers the core technology is effectively licensed from an agency, locked in ambiguous IP arrangements, or dependent on contractors who may not transfer with the business, the valuation collapses or the deal falls through entirely. Walters structured the relationship to prevent exactly that outcome — even before an acquisition was a realistic prospect.
The model also gave Snoop something valuable operationally: agency-level speed in the early phases combined with institutional knowledge retention as the team internalized the platform. The agencies built it; the Snoop engineers learned it deeply enough to own it. That's harder to execute than it sounds, requiring active knowledge transfer rather than passive handoff.
Two-Week Horizons, Not Five-Year Plans
Snoop's development ran on two-week sprint cycles, which is standard agile practice — but Walters frames the broader principle in a way that goes beyond methodology. His argument isn't just that short iterations help you build faster; it's that detailed long-range planning is often actively harmful for early-stage companies.
"Have a North Star, have a direction of travel, have a good understanding of where you want to get to, but don't worry too much about planning in detail on how to get there, because life doesn't work in straight lines." Snoop's journey validated this rather dramatically: the company launched, then navigated a global pandemic, macroeconomic instability, and geopolitical turbulence before reaching its exit.
The practical implication for entrepreneurs is that strategic flexibility isn't a nice-to-have — it's a survival mechanism. Startups that over-index on rigid roadmaps tend to treat unexpected circumstances as threats rather than information. The Snoop team's ability to absorb those shocks without the business collapsing likely owed something to this more adaptive approach.
Build It Like Someone Will Inspect It
Perhaps the most commercially significant insight Walters shares relates to quality standards. Snoop was never a bank, but it handled transactional financial data, which meant it operated in a regulated environment. From the beginning, the team decided to build to bank-grade security and compliance standards — not because regulators required it at their scale, but because they anticipated where an exit might come from.
"If your exit strategy is, 'We want to be bought by a bigger business,' then think like a bigger business in terms of the quality of the platform that you need to build," Walters said. This turned out to be prescient. When Vanquis — an actual bank — acquired Snoop, the integration wasn't derailed by the security and compliance gaps that typically surface during financial services M&A due diligence.
The broader lesson here applies beyond fintech. Startups that cut corners on infrastructure, documentation, or security to accelerate shipping often find those shortcuts compounding into liabilities precisely when they need to appear credible — during fundraising, regulatory review, or acquisition. Walters' team ran toward those standards deliberately, treating them as a competitive asset rather than a burden.
What "Good Exit" Actually Means
Walters is candid about the limits of startup optimism in a way that experienced founders tend to be and first-time founders rarely are. "You can't predict the outcome. Many startups never make it. So, any outcome, any exit, is a good exit."
That's not defeatism — it's a precise calibration of what success looks like when you're building something in genuinely uncertain conditions. His definition of a good outcome: the product survives, customers continue receiving the service, and the jobs created persist. Notably, "founder gets rich" doesn't appear in that framework. This matters because entrepreneurs who optimize purely for personal financial outcomes sometimes make decisions that undermine the durability of what they've built.
In Snoop's case, the acquisition outcome satisfied all three criteria. Vanquis got a capable digital team and a proven platform. Snoop's customers got continuity. The team transitioned rather than dispersed. And Walters now sits on the other side of the table as Vanquis CTO, applying the same principles to a much larger operation.
The through-line in everything Walters describes is a kind of disciplined patience — taking time before building, structuring partnerships clearly, maintaining quality under pressure, staying adaptable to circumstances outside your control. None of it is revelatory in isolation. The value is in how consistently the Snoop team applied these principles from the first week to the exit, and that the approach held up when tested by conditions no one could have anticipated in 2019.