Building an an Early Stage Startup: Lessons from Akita Software
Jean Yang sold her startup to Postman, and shares the details on what happened in the 5 years leading up to this sale.
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover one out of five topics from today’s subscriber-only deepdive on Advice on how to sell a startup. To get full issues twice a week, subscribe:
Venture funding is on a downward trend, and we seem to be at the start – or the middle – of a “startup purge” event. Startups that are running out of money, and are unable to raise more capital, are having to forcibly shut down.
Of course, it’s not just grim news: startup funding might be harder to come by, but it’s not impossible to get. And it’s not just startups shutting down: there are plenty of startups being acquired.
Today’s Thursday issue is a bit different than usual: we’ll share the story of a startup acquisition that had a happy outcome to showcase the viability of this exit path. At the center of the story is Jean Yang, who interned at Google, Microsoft Research, and Facebook as a software engineer. She got her Ph.D. at MIT and was a professor at Carnegie Mellon (CMU) before founding Akita Software. Earlier this week, I sat down with Jean to talk through her story of how her startup just got acquired by Postman. This news is hot off the press, publicly announced by Postman and by Akita yesterday, and you are among the early ones to hear about this event.
In this issue, we cover:
How Akita was founded
On cofounders
Raising funding
Pivoting and growing the company
On hiring
The tech stack
The biggest challenges of building a startup
For this article, I interviewed Jean directly. My questions are in italics, with the answers coming from Jean.
1. How Akita was founded
How did you start Akita?
I was working on programming languages research: language design, dynamic analysis, and static program verification. I regularly talked to industry teams on these topics. As I did, I realized that there was a bigger threat to software reliability than the language design topics that I was working on – the threat of how software grew into these complex and heterogeneous ecosystems that nobody really yet understood how to reason about.
The problem of ever-more complex software was one that bothered me over the last decade. However, it was only a few years ago that I realized that APIs could be both the cause of the problem and the solution. The cause of the problem – thanks to the rise of APIs, SOAs, and SaaS – is greatly accelerating complexity and confusion. But the solution as well: because the API layer is an easy, relatively standard layer to gain visibility into.
When I decided to start Akita, I reached out to everybody I was connected to on LinkedIn who worked at a company, and I asked if they were open to talking. During the first 1-2 years of my startup, I continued to call in every favor I could to talk with software teams, so I could continue to test the market.
2. On cofounders
You founded Akita with no cofounders. Did you seek out any at all?
I wanted a cofounder! I trialed working with two different cofounders for a few weeks each, but we weren’t going through it with the same motivations and levels of commitment. Ultimately, I felt it was the right time to start the company, so I decided to do it alone.
I 100% believe that starting a company is easier to do when you have cofounders. Ideally, you have people who are philosophically and financially incentivized in the same way that you are. I’ve seen multi-founder teams accelerate incredibly quickly when that’s there. It was Steven Sinofsky – the former president of the Windows Division at Microsoft and the author of Hardcore Software – who once told me that a cofounder is not someone you find, but someone you already have in your life. I completely agree.
3. Raising funding
How did you get the funding, and how much was it?
I feel that I got lucky raising the first round of funding: it was surprisingly smooth. I started an accelerator with my friend at Highland Capital in 2015. In 2018, my friend was still running this accelerator and convinced me to participate instead of applying to Y Combinator or another accelerator. So I did: in the summer of 2018, I took leave from Carnegie Mellon, where I was a professor by then. I moved to the Bay Area, hoping to raise investment in the next six months.
I started with early conversations with venture capitalists. These conversations didn’t really go anywhere; there were a lot of “let’s keep in touch” endings.
Things changed when a friend of mine introduced me to his seed investors. These seed investors were familiar with the API and security space and “got” my vision. I got my first term sheet a week later – and I raised a seed round the week after that.
My seed round co-leads were Martin Casado at a16z and Mike Vernal at Sequoia, and we had participation from people like Kevin Durant. I had been talking with Martin all summer but actually met Mike three days before the deal got done. I was able to convince Martin that adding Sequoia would be a benefit; Mike was the second person to the deal, so he agreed to split with Martin. To this day, we’re one of the few seed deals split between a16z and Sequoia!
Over the years, Harpoon Ventures also got interested. In 2021 and 2022, they also invested into our seed extension round. Thanks to this funding, we did not need to fundraise until this year, in 2023.
4. Pivoting and growing the company
In 2021 – when we last talked – you had just pivoted your company. What happened?
The original vision for Akita was to solve problems for API security. As a first product, we built an API fuzzer.
API fuzzing is a type of API testing where an API fuzzer generates various inputs meant for testing and aims to uncover security vulnerabilities, or bugs. People loved our fuzzer demos. But then we couldn’t deploy our fuzzer because most teams were lacking specs for their APIs!
So we started to build API specs on top of our API security product. In 2019, we were on our way to signing our first major customer contract for API fuzzing. But to close this contract, we’d just spent months building an API spec for this user.
We kept running into the same problem with other customers, and so we realized that to solve for the API security problem space, we also needed to solve for the API spec problems.
We pivoted to API observability in 2020. This happened a year later, in 2020, and this pivot took about a year to execute, in large part because we were building something so different we needed to recruit different people to help build it.
5. On hiring
Every startup hires differently. How did you hire?
We have a pretty involved interview process for an early stage startup, and we kept tweaking it. We do have two things that are less standard compared to other early stage companies:
We have a more hands-on interview than many. We do a bug bash and also a collaborative coding exercise.
We take references more seriously than just doing it as due diligence. For example, I asked people to put up as references their thoughts on why the person would be a good fit for a fast-moving environment with a lot of uncertainty.
I had to relearn how hiring works, compared to academic hiring. I had only ever hired before in academia. In academia, you’re building a team to optimize your chance of getting “superstars.” Since you’re only judged on your top papers, you’re optimizing for having a few good papers. In academia, you can tolerate high variance. Consistency and teamwork are not quite as important.
At my startup, I’ve come to value consistency, the ability to execute with a team, and product sense more highly than I previously did. I also don’t value high-variance brilliance as much as I used to when in academia. For example, try to imagine hiring John Nash from A Beautiful Mind as a product engineer to a startup. While that profile would excel in an academic setting, it likely wouldn’t go well at a startup.
The tech stack
What was your tech stack, and how hands-on were you?
Our tech stack is this:
Go on the backend
Python: We have a bit of Python left over from a developer who preferred Python to Go. This is one of the benefits of working at a startup: it’s easy enough to influence technology decisions!
JavaScript/Node.js on the frontend
AWS EKS (Elastic Kubernetes Service) as the infrastructure we run on top of
As for how hands-on I've been: I’ve focused on the product side of things at Akita – things like market research, user research, and customer success.
I still got very involved in how the technical solutions map to the product. When we’re solving hard technical problems, I also get involved because I’ll sometimes have insights about how we can leverage constraints from user needs to simplify the problem.
And to give a sense of the product: here’s a screenshot of the app:
The biggest challenges of building a startup
What were the biggest technology challenges when building the product?
I’ll be honest, growing the company was much harder than any technical challenge. I solved hard problems before and knew how to do it – you talk with people, you iterate, and so on. I feel like it’s hard to throw a technical problem at me that would really scare me.
Building out the team was the most difficult. I showed up to Silicon Valley with a pretty small startup engineering network, as most of my friends are either in academic research or founders who need to hire themselves.
It took me a while to build up my network, build up the trust of people outside of the programming languages community, and even figure out startup hiring! When I first started, I really didn’t know how to hire for an early stage startup. I am grateful to all of the people who have worked with the Akita team and me over the years and have learned a lot of lessons to use going forward.
Talking about technology challenges, two did stand out.
Dropping into a team’s tech stack with minimal work. We built Akita on top of BPF (Berkeley Packet Filter), which made things easier, though. BPF is a networking interface that allows user-space applications to inject small programs into the kernel. These programs get triggered in response to events, like a packet received on the network interface.
One part of the work that was unexpectedly hard was to actually get BPF to be “drop-in.” Being “drop-in” means getting things as close to a one-line install as possible. This means that we need to figure out exactly what versions of software our customers are using, and how we can automate Akita to install and run on top of that stack. Doing all this took more time than I expected!
Building algorithms for conveying insights from API traffic. After we first got our API spec generator working, our users reported they were overwhelmed by the sheer number of endpoints showing up.
We realized that we had to do a much better job of automatically figuring out which API calls might correspond to a single endpoint. We also had to offer teams a way to prioritize certain endpoints. This got us down the path of showing latency, errors, and endpoint changes – like adding and removing endpoints, or fields changing on endpoints. The challenge of endpoint changes is quite hard, and we’re still working on that.
This was one out of the five topics we covered in the article How to Sell an Early Stage Startup: Lessons from Akita Software. The full article additionally covers:
Jean’s background. From learning to code with Logo and Visual basic to working on F* – a security-typed programming language.
Selling Akita. Why Jean sold the company even though she was about to close a Series A. And how the Series A term sheet helped with the sale.
Advice when selling a startup. Building up a network, conducting the sale process, and how to think about privilege, luck, and hard work.
Future plans at Postman. Her plans as Postman’s Head of Product - Observability.