VyperCore Failed
3 lessons from a failed semiconductor (CPU) startup.
We failed.
Not in a small way, like “we deployed and crashed from user overload”. No, we went fully out of business – insolvent liquidation, with creditors left unhappy and our whole team headed to new roles elsewhere.
£4m of investment burnt on 2 years of salaries, offices, patents.
Most people’s initial reaction is: “Yikes.”
What’s the point of this post?
This is a very difficult post to write. Failure is not something we’re accustomed to celebrating in Britain, and it’s hard not to look at VyperCore as a failure. So why bother writing this at all?
Perhaps this is a cautionary tale – though, there’s plenty of those in the world already so maybe another isn’t really needed.
Perhaps this is a form of therapy – it’s taken me 3 months to even think about writing this post. It hardly matters if you read it, the act of writing it is enough for me.
But really, I hope that this post gives people some idea of what happened at VyperCore, what I learnt from the experience, and the silver linings of failing.1
Lessons learnt
There are at least 4 versions of this story, depending on who you ask: me, my former co-founder, our investors, and perhaps some of our former team. Frankly, the truth is somewhere in the middle of what each of us might tell you, and I’m not going to tell you even half of it.
Here, my focus is on things other semiconductor startups might learn from, and let’s leave the rest in the past.
1. “Start at the beginning”
VyperCore started out with roughly this plan:
Build a prototype processor on FPGA
Give it to people with Python workloads
Measure the performance improvement as a “with versus without” comparison of our hardware’s performance versus a plain RISC-V processor.
Use the results to show the value of the tech, and thus unlock Series A funding to carry us through to an MPW implementation of the processor (scaling the design up several notches along the way).
Early on, my co-founder introduced the term “teacher customers” to refer to these “people with Python workloads”. More on them in a moment.
We also hoped that perhaps the memory safety benefits of our design might lead to a security play. In practice, selling security works a bit like selling insurance, so we found little traction for security features, and that was compounded by our performance-first approach.
What became apparent within the first year of having an engineering team was that building an FPGA prototype was going to be more work than we’d expected. Also, the “with versus without” plan, which had worked in the PhD research, broke down with the introduction of caches.2
We solved the latter by switching to an “instructions per Python bytecode” metric which was sufficiently abstracted from the implementation, as well as a “clocks per bytecode” metric. I’ve only found this concept in one other place since I thought I came up with it – buried in a table of an academic paper from 2019 with no discussion. So, I wasn’t first to have this original thought, but nevertheless it was a nice solution to a tricky problem.
We couldn’t solve the FPGA timeline though. In hindsight, we ought to have built only a simulation (“functional model”) first, using mainly a software engineering team, and introduced RTL and FPGAs later. We did have this simulation, but we were trying to develop it in parallel with writing the RTL. That caused a lot of headaches, possibly even slowing down the work overall.
The lesson learnt is to start at the very beginning (a very good place to start). I hadn’t tried to lead a project like this before, and I learnt the development roadmap the hard way. I’ll take that knowledge with me to every new project. I’ll also remind myself to look even harder at what other people have done before to identify the proper roadmap. (Novel technology doesn’t mean novel development roadmaps or workflows – innovate one thing at a time. I wasn’t trying to jump the gun or innovate the roadmap/workflow, but that’s effectively what we fell into.)
Lastly, our expectations of hitting 1.5x to 10x performance were revised downwards: 1.5x to 5x – better benchmarking revealed a worse top-end than the PhD research had suggested. There was a benchmark in the research which I was misled by and failed to scrutinise properly. We couldn’t get around this – we just had to change the marketing and work with people to push the new message. The lesson here is research is not an absolute guarantee of technical merit, which frankly we all already knew, and it’s already accounted for in the VC model. The other lesson is there’s a silver lining in everything. We were able to talk about the increased rigour and accuracy of our benchmarking.
Lessons learnt:
Try to start at the very beginning - don’t jump ahead.
Study what others companies have done before you, the path they took - you’ll likely end up on a similar development roadmap, even with novel tech.
Research is not a guarantee of technical merit.
The VC model accounts for this risk but as a founder you need to be prepared for things that arise when you try to commercialise technology, issues which won’t have arisen in the lab.
There’s a silver lining in everything.
Pivoting or working around a new issue can often be turned into an advantage.
2. Avoid “build it and they will come”
We’ve seen a couple of engineering challenges. Ultimately, the FPGA prototype arrived 8 months later than originally planned (“shifted right” in the jargon). Given the original proposal to have teacher customers use the prototype, this was a pretty big issue.
It’s not an issue that we woke up to late-on. We knew from at least as early as February 2024 that we needed to change tack (8 months into the engineering and a year ahead of when we needed to close funding). At this time, our engineering team was also grappling with a tricky problem: how could we choose which software libraries, or even which CPython features, to support, when we had no idea what customers were going to run on the prototype?
This is where a crucial part of the strategy had been missed. The idea had not been to launch the platform and then hope customers would find us. We were supposed to be going out and finding people to work with, exciting them about our work, and gathering information vital to guiding the development of the prototype.
This didn’t happen. Not because “we tried and failed to find anyone”, rather the activity just didn’t get started. We ploughed effort into engaging the RISC-V processor design community, which got us lots of “oohs” and “aahs” and interest from bored Arm engineers (among numerous other companies), but none of these people were our customers, or the software product companies that would ultimately benefit from our processor.
The internal messaging, and the message to our investors, was “we need the prototype before we can talk to anyone; Nobody will take us seriously without it.”
Lessons learnt:
Engage early with the right people
Engage with your customers, not just your supporters/the crowd.
“Build it and they will come” rarely, if ever, works.
If you can’t find a way to excite your target customer base about what you’re building, you’re failing to find product-market fit. Beware anything that looks like this strategy.
3. “Know what investors are looking for”
We hadn’t totally missed the signs of the challenges we would face raising funding. My co-founder had pushed us to participate in Intel Ignite, and this bore fruit. Due to confidentiality agreements, I can’t talk about the validation project we had with one of the world’s largest server CPU designers/manufacturers. Needless to say, we were proud to have landed it and that the results were confirming our own internal benchmarking. The rest is a story for another time.
Unfortunately, incumbents saying “we’ve looked at this tech and it’s awesome but we’re up a creek without a paddle ourselves so that’s as far as we’ll go with it for now” isn’t particularly convincing for new investors. Especially investors who, for the most part, don’t understand the details of the sector, let alone the significance of the validation results. This collaboration turned out not to be a good enough substitute for showing market pull.
Lessons learnt:
If you can’t show product-market fit, no amount of benchmarking is likely to get you through Series A or beyond.
If you’re reliant on investment to keep going, understand what investors are going to pay attention to.
You’re unlikely to convince/educate investors about anything else in the time you have available, so shoot for what they’re looking for, even though that might drag you off on a bit of tangent.
It’s necessary for survival, which is a prerequisite to achieving your end goals.
4. “Know your co-founders”
There are multiple team risks for a startup: the founders, the initial hires, advisors, even the investors. But the group that will have the highest influence on the success or failure of the company is the founding team.
I could probably write an entire blog post just about my experience of the impact founders have (from my two very different startups). Everything from “the first 10 hires come from your network” to “a founder is the business’ best and only salesperson in the first 2 years”, and more besides.
Knowing your co-founders is incredibly important: their strengths and weaknesses, how they operate, what they bring to the table, what they’re hoping to achieve, what motivates them day-to-day and month-to-month, which areas they’re willing to grow their abilities, and what’s happening in their life outside of your startup.
VyperCore was no exception — I brought the technical side of the business, as well as a vision for what we could build, and experience from leading my previous startup. My co-founder brought commercial experience across product management, business leadership and venture capital investment (both as an entrepreneur and an investor), as well as his network.
In hindsight, though, neither of us had dug deep enough in the early stages of our coming together. Had we done so, perhaps we might have understood each other better, and perhaps we might have taken a different path forward. It is not useful now to reimagine what might have happened to VyperCore — the lesson learnt is to dig deep enough to hit emotive (‘core’) considerations of your and your co-founder’s relationships to the business and each-other. Use this to shape your way forwards; This will create alignment rather than hoping that alignment comes about incidentally.
I think this also applies to anyone hired into a highly influential position inside or outside the business - senior leadership team members, advisors, chairperson, and similar.
Actions from the lessons
The lessons learnt above are hopefully useful, but you may be wondering “What will I actually do next time?” Let’s dig into this a bit now.
First and foremost, I will spend a lot more time on customer discovery and product scoping, before hiring more than ~2 other people. I’d take somewhere between 4 and 12 months just focusing on understanding the market, identifying customers of different sizes and a range of needs, and scoping out various possible products (each building on our existing (patented) technology in different ways). I’d give extra attention to the most promising leads and product ideas, driving them through to more detailed proposals.
I believe focusing on customer disovery, engagement and product scoping is critical:
It will build confidence that I am working towards a product that solves real customer needs (“pain points”) and that they will buy it.
It will deliver a product specification which my future team will be able to pick up and run with, enabling alignment from Day 1 (rather than bringing lots of people on board and then debating the product spec in a vacuum).
It will create an initial pipeline of early partners, as well as a strong understanding of alternative paths (“pivots”).
Having a strong understanding of the product scope will enable me to map out future engineering and commercial activities, helping me to select the right initial team and set milestones.
I’ve encountered a belief that hard-tech (/deep-tech) companies can’t engage with customers early because they haven’t got a product (or prototype). But today, CPUs are a mature market that has well-established segments. There’s a lot of engineers in senior decision making positions who are willing to spend a small amount of their time discussing the challenges they’re facing over various timescales - challenges which will drive future purchasing decisions. This is enough to gain those initial insights into the market and begin relationships with key decision makers at target customers. Later, some of these can be developed into early access partnerships (/product-steering partnerships).
This focus on customer and product also informs my strategy for building an advisory team, as well as which events I’d spend my time attending. I will try to surround myself with advisors who offer insights into customer engagement strategies, make introductions to people with information about or connections into target markets, or have recent first-hand experience of the category of product I’m trying to build. I’d also focus on attending events where target customers are present (rather than conferences that lack customer presence, like the RISC-V Summits, engineering conferences and “Tech Weeks” we attended during VyperCore - these are valuable at a slightly later stage of the business).
The overall shape of what I’ve described naturally leads me to milestones and staging of capital. Early milestones would focus on market segmentation, building a network and customer identification, tracking the funnel of engagements, and working towards product scoping and Seed Round readiness. I plan to raise Pre-Seed funding to cover this first year of work, with a very small initial team that can deliver on these goals.
By the time I reach Series Seed, I would have the information to set milestones focusing on key areas such as building a prototype, turning pre-seed customer engagements into early access partnerships, evaluating the prototype with those partners, and the supporting activities: recruitment, engineering, publicity, marketing, etc.
These basic aspects of the funding rounds give indications of what size of funding I will be aiming for, but there’s plenty of details that need to be worked out. The timelines of raising rounds are also becoming much longer than historic averages (9 months for Series Seed?!) so that will need to be factored into the plan.
On the engineering front, I know what I need to do differently next time. The first thing is not to start the engineering until the product is better specified - i.e. Series Seed onwards. At that point, being clearer about the product specification will come naturally from Pre-Seed activities I’ve already described.
The second is to ‘do as I say’: to start at the beginning by focusing on building a model of the processor, getting software stacks working on that model, tune it based on understanding of what customers need (and, sometimes, what they want) and then start to move towards prototyping on FPGA. This necessary staging may ultimately mean the Series Seed has to cover the longer-end of typical Seed timeframes. My expectation is that will be acceptable thanks to strong evidence of building a viable product with an established customer pipeline.3
What happens next?
VyperCore went through insolvent liquidation. The team all found new roles relatively quickly and I’ve had plenty of time to relax and enjoy the summer.
I learnt a lot of lessons from VyperCore, many more than are in this post. For example, the Shott Scaleup Accelerator at the Royal Academy of Engineering taught me a huge amount at a crucial moment in VyperCore (you can find interviews on YouTube where I talk about some of this). I’ve come out of it with a lot more experience and greater skill, leaving me much better prepared for leadership roles in the future.
What happened to the assets? The patents, the tech, the equipment…? What am I doing next?
I’ve given a few heavy hints so far but I’ll leave the answers to a future post. For now, I’m off enjoying the summer and doing some of the things I put on hold for the last 2.5 years.
Albeit I’m not sure I can argue it’s £4m worth of silver.
A complex challenge which perhaps I’ll write about in another blog post.
From what I can tell, both aspects are surprisingly uncommon among early-stage hard-tech startups in the UK/Europe.