How to Sell an Early Stage Startup: Lessons from Akita Software
Jean Yang sold her startup to Postman. At a time when venture funding is harder to get, and acquisitions are trickier to close, she shares what worked for her and offers honest advice.
👋 Hi, this is Gergely with a 🔒 subscriber-only issue 🔒 of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers.
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 yesterday, and you are among the early ones to hear about this event.
While the terms are not public, the outcome was happy for all parties involved. Jean tells me it’s an exciting continuation of her startup’s mission. But she also told me something else that got my attention:
“I was fundraising in early 2023 and told a founder friend how the fundraising market was not where it was, and I was not that happy with the amounts we were looking to get. My friend turned to me and said: ‘Jean, if you end up thinking about getting acquired, I will give you all the advice. Because being acquired happens a lot more than people talk about.’
After I started asking around about people’s experiences getting acquired, so many people showed up to support me and give advice. And here I was, having never thought deeply about how acquisitions work before – because it’s a topic that seems to not be one that’s talked about.”
Jean shared her experience on an acquisition where she had multiple companies seriously interested in buying her company – and her choosing what, in the end, was a win-win situation. I latched onto the opportunity to capture not just her learnings, but also the engineer-turned-startup founder journey. Today, we cover:
Jean’s background. From learning to code with Logo and Visual basic to working on F* – a security-typed programming language.
The story of Akita. How Jean left academia to start Akita, why she had no cofounders, fundraising, going full-remote, and the story of 2 pivots in 2 years.
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.
1. Jean’s background
Jean’s parents were Computer Science professors in China. She learned programming as a kid: her first programming languages being Logo, Basic, and Visual Basic. Her parents got a Gateway 2000 when she was in elementary school:
Jean was hoping to break the family “tradition” and get out of tech: she chose economics as a major for her freshman year. But, on the side, she kept taking Computer Science courses. These courses were the ones she enjoyed the most.
In the end, she also ended up in tech. She did an undergrad at Harvard and a Ph.D. at MIT in Computer Science and became more interested in building reliable software. Here’s how she concluded that this area is important:
“I grew up wanting to do something with social impact. I always thought this would mean working on a cure for cancer or working on public policy. When I went to college, it bothered me that my core interests and skill sets seemed to revolve around Computer Science, which people didn’t see as having any connection to social impact at all.
During college, I came to believe that software is the biggest social problem nobody is talking about. This was in the early 2000s. I saw that software was coming to run people’s daily lives through apps. Software was going to run our cars, and software was going to run our buildings and cities. I agreed with activist Astra Martin, who writes about how software developers are the new urban planners. This led me to realize that the way I wanted to make the world a better place was by building software tools that help people build more reliable and trustworthy software. Reliable software impacts not just people’s livelihoods, but people’s lives.”
In 2007, she interned at Google, in 2009 and 2010 at Microsoft Research, and in 2012 at Facebook. During her internships, she focused on operating systems and security: she worked on F* – a security-typed programming language – at Microsoft and at Facebook as a verifier for the backend privacy language.
Instead of joining one of the Big Tech companies after graduating, she stayed in academia for several years: first as a Ph.D. student at MIT, then as a postdoc researcher at Harvard Medical School, and then as an assistant professor at Carnegie Mellon, focusing on programming language design. She left Carnegie Mellon in 2018 to found her first startup, Akita Software.
I first met Jean two years ago, as I was researching developer experience topics. I came across the article The case for “developer experience” that Jean had just published. This passage very much resonated with me:
“Developers work in rainforests, not planned gardens.
When software was small in size and still relatively simple, it made sense to think of tech stacks as planned gardens. Today, the rise of APIs and service-oriented architectures, the bottom-up adoption of developer tools industrywide, and the aging of software systems have led tech stacks to become organically evolving ecosystems, for better and for worse.
Software tech stacks today look way more like a rainforest – with animals and plants co-existing, competing, living, dying, growing, interacting in unplanned ways – than like a planned garden.”
I got in touch with her, and we talked about how she was seeing an explosion of APIs and the frustration of how most tools bring more complexity, and how there was little effort to tame this complexity. It was the taming of the complexity across large software systems – and helping build more reliable software – that Jean was intent on doing. I found her energy and unique viewpoint both interesting and promising.
For the rest of this article, I interviewed Jean directly. My questions are in italics, with the answers coming from Jean.
2. The history of Akita
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.
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.
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.
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.
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.
3. Selling the company
How did you decide to sell?
By 2021, I had been getting a lot of reachouts from CorpDev teams from several larger companies. [CorpDev refers to Corporate Development, and these teams usually look out for mergers and acquisitions (M&A), strategic partnerships, spin-offs, and capital raising/financial strategy.]
However, in 2021, I got a reachout from a CEO himself: Abhinav Asthana, the founder and CEO of Postman. It is rare to get a reachout directly from a CEO. He wanted to meet, and we had coffee. When we met, he said he liked our blog posts and that we should consider joining Postman. Back then, I did not think it was the right time, but we kept in touch.
In the spring of 2023, I became more open to the idea of selling. We talked with Postman, we talked with a few other companies that had previously approached us, and we talked with a few other companies that were in the mix. At this point, I got advice from friends and learned that if you want to get a sale offer on the table, you should commit fully to going through the sale process.
Once I decided to pursue a sale, we engaged in a series of strategic conversations. Postman seemed like the best mutual fit out of all of the options. They were the first offer in, and we decided to go with them fairly quickly.
Did you want to sell, or need to sell?