Why I'm Choosing to Bootstrap my Intel Competitor
Some readers may have noticed the 𝔸𝕟𝕠𝕕𝕪𝕟𝕖 link that’s been on the main page for my substack for the past few months. Back in May, my friend Alex and I went on a month-long roadtrip around the country to raise money for our startup.
The 𝔸𝕟𝕠𝕕𝕪𝕟𝕖 page is the pitch we were using, granted one that needs quite a few updates by now.
We happened to leave just as the markets crashed, and some of the people we met and conversations we had left Alex rather jaded, so we’re back to the plan I originally had, which was to bootstrap the whole thing.
This might maybe sound reasonable until I mention we’re trying to build an ambitious hardware startup. And that I’m currently couchsurfing in Austin with substack as my only real income at the moment.
Our basic thesis is that a combination of Moore’s Law and limitations in compiler technology have resulted in incentives within the hardware industry that favor compatibility over efficiency in ways that have compounded to a massive degree over the past 50 years. Most of the 10,000x difference between CPUs and ASICs is unnecessary and general-purpose CPUs that are 2-3 orders of magnitude more efficient should be perfectly feasible.
This is nothing new, as many companies have successfully done this before. Building record-breaking chips with a single engineer on a tight budget has been done before. That’s the easy part, actually.
The hard part is tooling. Especially with some of the recent examples, many ambitious chip startups have put nearly all their effort into hardware and very little into tooling. Abandoning backwards compatibility and building the relatively weird hardware necessary for these huge efficiency gains necessitates that programming without significant help from tooling will be difficult for mere mortals.
Adapteva shipped their chips with a GCC backend and a few parallel programming libraries. For an architecture that’s as weird and different as the Epiphany, how is anyone supposed to program such a thing? Hardware without software is just an expensive paperweight.
That said, it’s possible for a single engineer to build an entire operating system and software suite by themselves, not even factoring in all the open source code that can be ported and the fact that much of the existing complexity is purely a product of bad decisions made by short-sighted hardware engineers. If a single engineer can design a record-breaking chip, and a single engineer can build all that software, think about what two engineers can do, especially if they work together to make sure each other’s job is as easy as possible.
The current bootstrapping plan is focused on tooling. Getting a round of chips produced at a top fab like TSMC costs a couple million dollars. Not cheap, but bootstrappable. We’re going to need very good tooling as it is, and some subset of that tooling is probably going to be useful for existing languages and hardware (after all, how hard is it to compete if much of your competition dates from the 70s and 80s?). A combination of dogfooding and consulting with startups should give us something actually valuable.
Good dev tools can bring in a lot of money if you can convince people to buy them (I’ve been warned this isn’t easy, but frankly I’m up for the challenge). Enterprise tooling can easily bring in >$1000/engineer/year. It doesn’t take a lot to raise a few million dollars that way.
If you’re someone writing code who wants to talk about what kinds of powerful tooling we could build for you, DM me on twitter. I don’t care about your tech stack - if it’s code I have ideas on how I can help. I just need to refine ideas with some feedback and build.
But why not just take some VC funding?