departing airplane

motivations

When we left Sunriver, Oregon, we did so without having settled on an idea yet. Consequently, as we settled into our quiet eight-person house in suburban Palo Alto, the morale high that came with being around the Neo accelerator cohort and participating in its programming quickly faded. We were restarting in a sense at the same spot we were in before the accelerator—we did improve our process for iterating through and validating ideas, but I think all of us had expected us to be a little further along by this point.

That first week post Sunriver was a slow one—we all chased threads independently, but every idea that we dug into were dead ends. At this point, it had been two months of researching without building any product, and our morale was at an all-time low. At the start of the second week post Sunriver, we made a decision to start building product, partly because we finally settled on an idea that we thought was solid, but primarily to boost our mentals. Being four technical founders, coding was a form of therapy for us, at least relative to the other kind of work we had been grinding.

This is not to say that there weren’t other, more salient reasons for starting to build rather than continuing to churn through hypothesis sheets. We have been building together for years, and, by this point, we are capable of spinning up MVPs quickly. A nice benefit of this is that we can leverage our building skills to find insights that aren’t as immediately obvious through user interviews. Maybe if we were really good at user research, we could find these answers without building, but it does feel more comfortable to just sit down and churn through code. Figuring out how to best ideate is a process in itself, and I’m still unsure which is better.

bull case for airplane

The idea that we settled on building out was a tool to convert your scripts into internal apps that you can then share via a link. To elaborate, in many companies you have non-technical members of a team that need to do tasks that require technical knowledge (e.g. customer support needing to delete a user account from the production database). As they lack the necessary technical capabilities to complete the task, they will often simply ping an engineer to do the task. The engineer will code up a script, run the script, and get back to the individual that it is done. If the engineer is bothered enough times by enough people, they will determine that it’s probably worthwhile to spin up an internal app such that people can complete said action without disrupting engineering time. However, creating an internal app, even with the core logic of a script already written, is no trivial task and can take days. Particularly tricky/time-intensive parts of this process involve handling auth (making sure that only the right people are able to run your app), hosting your app on the cloud, and integrations (connecting to your databases, Slack, email, etc.). The idea/problem space converged nicely from all the threads we’d been chasing over the course of the accelerator.

1) The difficulties of creating internal apps were the same difficulties faced in DevOps more generally. We solve this by providing a serverless offering specifically for scripts.

2) Workflow automation/integrations were really interesting for a while—we had a thesis that all business functions can be modeled as a series of workflows. This sort of tool would make it really easy for code and human work to be chained together, enabling employees to work side-by-side efficiently.

3) Internal apps for operations/sales/marketing/growth are a more recent development within tech companies, at least, at its current scale. This is a strong trend that’s less obvious to people outside of tech, and, with advances in software tooling, there’s a strong demand to make the non-software members of your company more efficient as well.

It is estimated that something like 30% of engineering time is spent on internal apps. This was the surprising key insight that made me particularly excited about this idea—at most companies, engineering time is considered the most expensive/valuable resource, and time spent on anything other than product is considered deeply suboptimal.

There is a startup in this space that does precisely this called airplane.dev (feel free to check them out). More broadly in the internal apps space exists a larger startup called Retool (multi-billion dollar startup). Our initial plan was to build out an open-source version of airplane.dev and hopefully realize some key insights through the process. Being open-source does give some nice advantages over a more closed-source option like airplane.dev: it makes it easier for companies to trust you (companies shy away from SaaS offerings from startups because it’s unknown if the startup will be alive in the future), and you can source integrations from the community (which makes it more powerful/generally applicable). But the goal, even from the start, was never to simply become an open-source alternative to Airplane. Perhaps if we were certain that the total market was huge then it would’ve been worthwhile to go head-to-head with them, but the hope was that we’d find ways to differentiate our products.

Screenshot of our app

departure

We actually did come up with key features where we could differentiate from Airplane. Specifically, being able to self-host the solution is rather important to these companies—just as how enabling non-technical members of your team to touch sensitive parts of your tech stack is dangerous, there is much concern over allowing access for a small startup’s SaaS solution. Airplane does enable a self-hosted solution that is open-source, but it’s only the Airplane agent itself (the frontend, surrounding functionalities, integrations, essentially any functionality that makes Airplane useful are all gated behind the paid solution). It’s actually a pretty good business model in the sense that if you were a tech company, you could technically rebuild all the functionality on top of the core functionality of the Airplane agent, but there’s just no reason to if you’re willing to pay an additional $10 per month.

Another insight that we had from interviewing various engineers is that most companies already have some sort of internal app built in house. Giving them a completely separate platform to use for their internal apps is actually leads to friction to transition away from their existing solutions. There also seems to be some degree of sunk cost here—building out these internal apps might’ve been a process they hated, but after completing it, it would feel quite bad to scrap all the bespoke functionalities of an internal app built in house. To that end, instead of generating an entire independent internal app, we could generate React components that captures all the functionality of an internal app, but adds the additional capability of being plugged in anywhere within your preexisting internal app. However, around two weeks into building, Airplane announced a massive product release that did precisely this.

From the beginning, I was rather hesitant to go up against Airplane, a company that has raised significantly more funding than us, but more importantly, has a rather strong founding team (I’d rather go up against a more ancient incumbent). Our advantage of being able to maneuver faster than a large corporation is severely lessened when going up against another venture-backed startup, particularly of one whose founders seem competent. The fact that Airplane came to the same insights/solutions that we arrived at after working on the product for a week was hardly surprising to me. That’s why it felt weird to me to suddenly decide that this idea wasn’t worth continuing shortly after this product release came out (nothing really fundamentally changed in my eyes). After further discussion, I agreed with our decision to move on—our hope had been that building out the product would give us insights to differentiate from Airplane on. Having failed to do that, the prospect of playing catch-up/entering a feature war with Airplane was not as exciting—at the end of the day, building something new is just more optimal compared to simply putting a different spin on the same fundamental product. I do think that we could’ve raised funding, hired a bunch of developers, and entered a feature war with Airplane—I have conviction that the market is big enough and that we’re talented enough to carve out a viable business here, but I am also relatively certain that there are better opportunities for us out there.

UPDATE 9/29: Airplane announces $32 million Series B

learnings

Back in Sunriver, I remember a particular piece of advice that Reid Hoffman gave which was to reflect each week on what you did and identify which things you would do differently if you got the chance to do it again. The reasoning is that founders are expected to make a lot of mistakes, but the better you are at not repeating mistakes, the faster you’ll learn/move. On paper, it sounds like a really good method for both personal and startup growth—I will try to do this more regularly on all threads/work I do for my startup.

The most obvious takeaway is that ideating/hypothesis sheet generation is a lot more emotionally taxing than building product. The key difference between the two is that the former is composed of unconstrained problems whereas the latter contains not only constrained problems, but problems that I’ve used to solving. It’s nice to wake up in the morning, walk to my desk, and know exactly what I need to get done. It’s just a matter of figuring out how to get it done, and when you do get it done, there’s a massive sense of productivity/accomplishment. That sort of feeling does not exist when iterating in the infinitely open space of possible startup ideas.

I didn’t reach a concrete conclusion here for whether or not it’s better to build versus simply conducting user interviews/research. It’s tricky in this case because we did validate that this would be a legitimate problem/solution, but part of our validation process was the knowledge that airplane validated the same exact problem.

Wedges are really essential not only from a business logic perspective, but also from our intrinsic motivation to continue working on a differentiated product. We came up with possible wedges, but there wasn’t enough of a moat in this case to defend ourselves from competitors (i.e. Airplane releasing React views).

We did spend a lot of time/thought on GTM here, but given how sales went combined with the fact that this should be a burning need for companies, there’s clearly much for us to learn along this front. John handled most of the sales stuff for this product, so he probably learned the most along this front. This was our first experience with sales, so this skillset is assuredly much weaker within our team compared to our abilities to build. This is definitely something to focus on in the future—no matter what we build, we’re going to have to learn how to do sales/marketing really well, really quickly.

I haven’t coded on a legitimate project in quite some time. I generally learned a lot about software engineering—I feel pretty comfortable for whatever we build next in the future. One of my personal goals is to get really good at software dev—I think this is not only going to happen naturally over time as we continue to build out ideas, but it’s a necessity. These learnings will also be extremely useful in the case where my startup fails as they are extremely hirable/useful for pretty much any career in tech.

Pivoting shall continue—stay tuned :).