After I graduated last year, I evaluated different startup ideas for a few months. Here's a list of ideas I ultimately didn't end up pursuing, with varying levels of research and prototyping.
A few personal requirements besides the generic evaluation set that I set for myself:
- Unique insight – What is something that I know that few others do? My deep expertise is in software engineering and finance.
- Large total addressable market (TAM) – I think most startups are equally hard to do, so I might as well pick the largest potential outcome. Of course, at the early stage, TAM is not always a helpful measurement (the best startups create new markets or expand existing ones), but I wanted to have a plausible narrative.
- High-risk tolerance – I'm relatively young and have decent fallback options. So I'm searching for high-risk ventures. Of course, I'd like to pick the best idea with the best risk-adjusted return in that subsection of the asset class.
- Intellectually stimulating – If I'm going to devote the next few years (hopefully, at least) to building this, I want to be passionate and excited about what I'm doing.
PaaS – Every infrastructure engineer wants to build a PaaS – it's a generic problem and something that many engineers can create a show-stopping happy path. I've spent a lot of time building the pieces (CI/CD, developer tools, Kubernetes, containers). Companies in the space have done reasonably well (Railway, Render, Fly), and Heroku's free tier sunsetting has created some tailwinds of migrating customers. In addition, remote developer environments (Codespaces, Coder, Gitpod) might unlock some interesting PaaS workflows.
Some of the writing that came out of this discovery process: AWS is Not a Dumb Pipe, and Why Did Heroku Fail?
Agentless data observability platform – All DevOps companies are observability companies. Data pipelines will always be fragile (M:N connectors), so observability is an acute need. Saturated market, but most products are designed by data analysts (rather than DevOps engineers). Take best practices from Kubernetes observability and eBPF monitoring and put them in the data stack.
Machine Learning Infrastructure – There are many parts of the machine learning stack to build, from core infrastructure to developer tooling. I worked on distributed training and inference infrastructure at Google and had some ideas for improving it. I also believe that MLOps/DevOps will converge rather than diverge. LLMs didn't exist then, but it shows how quickly this market changes and how much remains to be built.
Next-generation spreadsheet for building internal tools: Taking what Figma did for design and doing it for spreadsheets. After seeing how edge runtimes and functions-as-a-service fit into the infrastructure stack, what would it look like to embed them in a function-native UI, the spreadsheet? For example, I had a prototype of hooking up Excel to Kubernetes in 2018 and saw how easy it was to build declarative systems that leveraged the calculation graph.
Some companies ultimately launched Figma-like next-generation connected spreadsheets (Equals, Rows, Casual). However, these companies struggled to find the right market to start with, and I thought internal tool builders (Dynaboard, Retool) was an exciting and decent business to explore.
Some other ideas:
- Security information and event management (SIEM) – There's potentially a great business to be built by rethinking Splunk in a cloud-native architecture. The deployment model and pricing model of Splunk have been waiting to be disrupted for some time.
- Consumer VPN – Tailscale showed that WireGuard-based VPNs could be made into zero-configuration experiences. Like Cloudflare, I believe building infrastructure around the network is a unique and defensible position (e.g., file-sharing with Tailscale). While the enterprise VPN market is tough to compete in (incumbents like Cisco, newcomers like Tailscale), different markets might have white space (e.g., VPN as a dev tool).
- Crypto infrastructure – From RPC to the web3 data stack, there's a lot of infrastructure to be built. However, I don't believe these products will look much different than typical enterprise SaaS and be made with the same technology.
- Backend-as-a-Service – The backend-as-a-service pattern will continue to grow in popularity. It's a decent solution to both technical and organizational problems. There are a few ways to build these, but they all resemble different levels of specialized PaaS.
- Version control system – Something I've wanted to build for a long time—Monorepo-first, package-native, and ergonomic. A fun experiment, but I couldn't figure out a viable business.