Grading Command AI’s YC application

We went through YC in the S20 batch with Command AI. At the time, we were working on a different startup called codePost. We were excited about both ideas and saw YC as the way to break the tie. "If we get into YC that must mean the idea is good." In retrospect, this is not how I think founders should think about applying to YC.

There are a few reasons for that. In short: Getting into YC isn't an indicator that your idea is worth working on for an entire summer/winter. It's an indicator that the idea is decent enough to A) back you as a founder and B) allow you to explore the idea intensely for a few weeks, or pivot until you find the right product.

YC looks for great founders much more than it looks for great ideas. Ideas are cheap. I know multiple founders who went into a batch and pivoted in week 2. In fact, YC encourages pivots. I even know a company that got in under the express condition that they work on any other idea but the one they applied with.

Then why is the YC application so centered around your idea?

For two main reasons:

• YC wants to see how you think / how much thought you’ve given the idea. They want to see you’ve got conviction and understand why what you’re building is a big enough problem to be solved.
• YC wants to validate that you think big and want to build a billion dollar company.

I often serve as a proof reader for other founders and friends who are applying to YC, but I’ve never formally graded our own. So here goes. The focus of this post is on grading our application as an illustrative example for other founders. I’ll probably write a separate one that looks back on what we got right and what we got wrong in our YC application.

In other words, this is an ex-ante assessment of our application (“how good was the application given the information we had at the time”), not an ex-post assessment (”did we turn out to be correct”).

Describe what your company does in 50 characters or less.

Make web apps easier to navigate and learn.

This is still a mostly accurate description of what Command AI’s mission is, even though we’ve broadened our platform over the past year and moved beyond search. Looking back, I like that we focused on the pain / problem we’re solving, instead of jumping to the solution. I remember the first version of the application said “a search bar built into web apps,” which focuses too much on the solution, not the problem. -James

What is your company going to make? Please describe your product and what it does or will do.

Foobar is a searchbar built into web apps that allows end-users to discover and actually execute commands – not just search – straight from the searchbar. It comes as a configurable web component that a front-end developer can start prototyping in minutes using our web interface. Foobar makes it much easier for end-users to access the functionality they want wherever they are in your site, and configuring Foobar is also much easier than trying to build a perfect UI that works for different types of users (power users, new users, etc).

We believe Foobar will improve onboarding, feature discovery, and long-term usability for web apps, ultimately driving better conversion and retention. As well as the web component, our tool includes a web interface for maintenance (adding and updating commands), personalization (customizing who sees what commands), and analytics (how Foobar is being used).

Make sure your first sentence of each of these answers is how you’d answer it if there was a word limit. Imagine they won’t read the rest. What is it that you want them to understand as soon as possible?

Our product was a bit weird, in the sense that it was a new solution to an old problem (”web apps are hard to use”). So we focused on the part of the idea we felt was novel first (”searchbar for commands”). I think this is a good tactic, given the previous advice about structuring your answer so the best bit comes first in case the rest of the answer isn’t read.

(This is equally true of YC interviews by the way — maybe we should do a separate post about that) -James

How far along are you?

Not far.

We originally decided to build Foobar as a feature for a different web app that the 3 of us were working on (https://codepost.io). While building it, we decided to turn it into a product -- a component that could be used across sites and configured via a web interface -- instead of just a codePost feature. While building our prototype, we have pitched Foobar to 4 apps: Kapwing (https://www.kapwing.com/), StdLib (https://stdlib.com/), Plan (https://getplan.co/), and Meetingbird (acq by Front) (https://meetingbird.com/). All 4 have committed to piloting Foobar (for free).

We’re about 2-3 weeks away from having our prototype ready to go live in these web apps. If that goes well, we'll look to expand to 10-20 more apps (sourced from people we know and our network).

I’d now maybe switch the very last paragraph to go first (and answer the question straight away). But I like that we addressed up front that we weren’t trying to overstate our traction. This is a technique called anti-selling that I think is super effective in many forms of life (and especially B2B SaaS sales).

We made a mistake here that I see in a TON of YC applications: we touted “company is committed to using us” as traction. Sometimes that “commitment” will get formalized into a LOI. (If you watch YC demo day you’ll see plenty of companies citing “3 LOIs” or “70k of ARR under LOI”. It’s very natural to do this when you don’t have any actual customers or revenue, but the reality is that these types of “commitments” are rarely real. In our case, only one of those 4 companies ended up ever even creating a Foobar account.

The silver lining of this answer is that it shows we were focused on the right things: getting customers and speed.

I’m not sure how to make the answer better, though, because we didn’t really have anything else to show. So I suppose the advice is: if you feel compelled to mention your LOIs, then you should try as hard as possible to get actual users, even if they aren’t overtly impressive logos (for B2B). Some usage is better than hypothetical usage from better sources in the future. -James

How long have each of you been working on this? How much of that has been full-time? Please explain.

3 weeks, full-time. Before that, the 3 founders worked on a different project for the past 12 months, full-time: https://codepost.io, a web app used by CS teachers (mostly at universities) to review student code. The 3 of us built the product and scaled it to 60 universities. (NB: we applied to YC with codePost as our idea in 2016, but didn’t start working on the project until early 2019). When we realized Foobar had the chance to be a bigger company than codePost, we decided to pivot to it full-time.

YC doesn’t shy away from founders who are mid-pivot/have pivoted in the past. Building an early-stage startup requires that (most times). Be genuine about your answers and the extent to which you’ve been focused on the idea you’re applying with, whether that’d 3 years or 3 days.

I’m glad we talked about our history as a founding unit, since that showed we were committed to each other as founders and were committed to doing something in startup land. I end up seeing a lot of YC founders treat YC as summer camp (or winter camp). Do YC, realize startups are hard, piddle along for a few months or maybe a year after YC and then bail (giving back any money they raised that is left over).

YC really isn’t looking for that type of founder, because it limits the expected value of the company they’re working on. Plenty of YC companies have labored in obscurity with little progress to show for years before breaking out. If the founders give up after only a year, it prevents this scenario from playing out. So the repeatable advice I’d give here is: if you have indicators of your seriousness about doing a startup (not necessarily this idea) share them. -James

Are people using your product?

Yes

Grade: N/A

I think by this we meant codePost was using Command AI, which is very obama-awarding-obama but ok. -James

How many active users or customers do you have? If you have some particularly valuable customers, who are they? If you're building hardware, how many units have you shipped?

Four companies have committed to piloting Foobar: Kapwing (https://www.kapwing.com/), StdLib (https://stdlib.com/), Plan (https://getplan.co/), and Meetingbird (acq by Front) (https://meetingbird.com/). An alpha is also live in our old company's site (codePost).

Yep lol -James

Do you have revenue?

No

Grade: N/A

Not much to this one. -James

Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you're making?

We originally decided to build Foobar into codePost because we were facing some UX challenges. codePost is a relatively complex web app. Many of our users are power users; some spend 20+ hours a week using it to review student code. We found it difficult to create a UI that made functionality easily available to these power users in a way that was also accessible for new users. We were inspired by other components we’d seen in the wild -- in Superhuman and Google Docs -- that allow users to actually execute commands via text. We liked the idea of making functionality accessible without matching GUI elements, and empowering users to easily find what they want to do instead of churning, wading through help docs, or messaging us via in-app chat.

We decided to work on this full-time when we realized that (a) many web apps face the same problems that Foobar solves, and (b) there was a lot of functionality we wanted to build into our Foobar that we thought would be very valuable generally but tedious for others to build. Specifically, functionality for easy configuration and maintenance, by-user personalization, and data mining. (Foobar generates really valuable data, because users use it to express their intent around your site.) The 3 of us (the founders) have domain expertise in building web apps, having spent the last 12 months building and scaling one full-time. We also know people, other web app developers, who need it: we’ve pitched 4 so far, and plan to pitch more.

A theme of this analysis is that most questions in the YC application have two parts: a literal question and a meta question.

The literal question here is asking for a narrative about why this idea is exciting, and maybe YC will use that to assess the idea. But the meta question is: how do you decide what to work on?

In my experience, the best founders are obsessed about their problem space. By that metric, what you want to show in this answer is credible obsession — show why you’re so excited about the idea. DO NOT try to give the “right” answer by talking about things like moats, “capturing a small piece of a big market”, TAM, etc.

Using this framework, I think we smashed this answer. The story was very specific and referenced non-obvious observations (like the point around user intent). We could have easily spent the whole time talking about our credibility (”domain expertise in building” apps), but instead we showed that we were experts with the answer itself. Good job us. -James

What's new about what you're making? What substitutes do people resort to because it doesn't exist yet (or they don't know about it)?

Foobar's job is to make web apps easier to learn and navigate. The most common substitute for Foobar is to try to design a UI that works for all of your users, resorting to patterns like nested menus and panels of buttons to handle complexity. Getting this right is obviously really hard. Another common way to help users navigate a site is search, either home-grown or offered as a service by vendors like Algolia. Search surfaces content, so doesn’t work well in web apps that aren’t structured around hyperlinks or inventory.

Web apps may also resort to "customer success" tools. These include help centers, in-app chat, and in-app product tours. Intercom is a vendor that offers all 3. Foobar doesn't replace these tools. Depending on the query, the best path for the user to follow might be to execute the command within Foobar, execute a related command within Foobar, read a help doc, or initiate a chat. Regardless, we think Foobar is the best place for a user to start their “how do I do this” journey. In our experience a user doesn’t think “I really want to read a help doc right now”: they just want to do something. Starting with Foobar means a user can quickly find the next steps that gets them closest to their goal.

This was a solid answer. We referenced a lot of partial substitutes (which reinforces that we’ve thought a lot about this problem). I do think the answer could have been enhanced with a bit more emphasis on they “why now”. Why hasn’t this product been made before? Were we just the first to have the idea? Or are there reasons it won’t work? -James

Who are your competitors, and who might become competitors? Who do you fear most?

We don't have any unique advantage that prevents someone else from building a Foobar clone. We worry most about search vendors and customer success vendors, who are solving a similar problem to Foobar. Also, no-code development tools like Webflow might be able to disintermediate us if web apps are built using their tool. Obviously we want to differentiate from potential clones by building a great product. We also think we can build an accumulating advantage against clones (see below).

Another potential "competitor" is that apps will try to build something like Foobar themselves: a simple command-line-lite GUI with a few actions. To compete against this competitor, we think we need to make sure Foobar is better than a home-brewed version could be. We’re doing this by making Foobar easy for engineers and non-engineers to configure (adding and maintaining commands), personalize (show different commands to different users based on personas), integrate with third-party services (like help centers or APIs like Sendgrid’s), and refine based on user data (e.g. A/B test different commands). We think getting these steps right is key to unlocking value from Foobar, and they probably exceed the buy vs. build threshold for most companies outside of very large ones.

The first sentence is great - it acknowledges that our “moat” was our idea. A lot of people think this is a problem for YC, and it is absolutely not. Imagine this thought experiment. You tell 100 founder teams about your idea, and make them really excited about it. All 100 teams, and you, start working on the idea at the same time. Do you have some special sauce that makes you likely to succeed? Now re-do the thought experiment, but instead of founder teams, sprinkle in incumbents in your space.

Very, very few YC founders have this kind of inherent advantage. (Maybe the exception are some really technical products that require knowledge that only a few people have, like a database or hardware product). If you’re in SaaS, it’s exceedingly unlikely you have an advantage like this from the start. Your advantage is your conviction that your idea is worth exploring, your execution speed, and your ability to focus on nothing but this idea. And that’s totally fine. The next question pokes at this concept. -James

What do you understand about your business that other companies in it just don't get?

We didn’t invent the idea of a searchbar that can execute actions. Some examples exist in the wild, most notably Superhuman. Our unique insight is that this component should be a product that is bought instead of a feature that is built.

We don’t think others get this for three reasons.

(1) A searchbar that can execute actions can be useful in many, many web apps. Way more than have built their own version to date.

(2) To get the most out of Foobar, you need users to be able to rely on it, just like search. That means that they get used to pulling it up and finding what they want (or something that works) on 90%+ of searches. To make this happen, you need to be able to add lots of commands to Foobar, remove ones that aren’t working, and personalize responses so users see results that are most likely to be relevant to them. This functionality is hard to build into a home-grown feature.

(3) It may seem hard to build a moat around a company that sells a "searchbar that can execute actions", but we think there is an opportunity to build a defensible business here with a durable competitive advantage. When an app uses Foobar, it creates a map of intents (“clear calendar for today”) to actions (code that actually updates user data), which is essentially an API. We could make it possible for businesses using Foobar to expose commands they've built to other businesses using Foobar. This functionality enjoys network effects: more customers means more potential integrations. We could build a cross-site “meta-Foobar” that centralizes commands from all apps that use Foobar, used by consumers. More consumers using meta-Foobar means Foobar is more valuable for apps, which makes meta-Foobar more valuable for consumers, etc.

This answer gets a bit carried away at the end (which is the right place to get carried away — remember, best stuff first!).

The meta goal of this question is similar to “How did you pick this idea to work on” question. You want to demonstrate that you have thought about this more than anyone on Earth — that’s what demonstrates that you have the conviction needed to be a successful founder. This matters way more than whether the observations you have about your space are ironclad. Remember, it’s much easier for the YC application reader to assess “were they observations nuanced and non-obvious” than “are these observations right”, because the application reader is very unlikely to have sufficient context in your space to know if your ideas are (a) correct and (b) widely known. -James

How do or will you make money? How much could you make?

(We realize you can't know precisely, but give your best estimate.)

If Foobar creates value for web apps (via better conversion and retention) and is easy to configure, then we should be able to capture some of that value via a subscription fee.

The biggest possible market for Foobar is all internet businesses, since any website could benefit from Foobar. The key question we need to better understand is: for what types of web apps is Foobar substantially valuable? We think the answer is: most. Our heuristic is that any web app that is complex enough to have a help center can probably benefit from Foobar. Even a relatively simple ecommerce site could benefit by making it easier for users to access important actions like “add to cart” or “shipping estimate.” We plan to answer this question by pitching Foobar to a bunch of different web apps and seeing where it sticks. If we can match the value proposition of incumbent “customer success” vendors (like Intercom) then we could charge on the order of what they charge: $100 to $1000 dollars per month.

What YC wants to understand with this question is TAM (Total addressable market), so in hindsight, we’d probably try to come up with a number that looks at this at scale. Regardless of it, YC wants to see that you, as a founder, have thought about your idea being something that can become a billion dollar business. They want to make sure you’re thinking about building something that can be used by a lot of people and become more than just a hobby or lifestyle business. -James

How will you get users? If your idea is the type that faces a chicken-and-egg problem in the sense that it won't be attractive to users till it has a lot of users (e.g. a marketplace, a dating site, an ad network), how will you overcome that?

First, we'll continue to do what we're doing right now: implementing our prototype Foobar in our own web app (codePost) and pitch our peers (other web app developers we know or can get connected to) to have them try it out.

This means "high CAC" initially but it also means we can discover the niches in which Foobar resonates most strongly and focus our engineering efforts on those niches. The early-adopter niche might be defined by end-user-type (e.g. lots of power users), app type (e.g. high complexity), or some characteristic of the development team (e.g. a team that likes to ship lots of new features).

The tough times imposed by COVID-19 may make it harder for us to get users because businesses are less likely to have spare engineering cycles to implement it, and may be hesitant to spend on a new tool. To combat these forces, we plan to focus on making it possible for non-developers to configure Foobar, and to build case studies demonstrating the ROI a web app can achieve with Foobar. The lack of spare engineering cycles could play to our advantage too: companies will probably be less interested in building their own Foobars if they see value in the concept.

We do have one idea to scale Foobar faster. We're building a chrome extension to allow end-users to build a basic Foobar for themselves on top of any app. Usage data (who is using Foobar for what apps, and how they are using it) should help us understand our early adopter niche. It also gives us a powerful sales pitch: "look how many people are already using Foobar for your site!"

It’s always good to call out problems here. The best answers to this question convey some sort of unique acquisition channel. “My brother is a product consultant and works with tons of companies that could use Foobar” would have been an amazing answer. This answer is basically: “we don’t know but we know this is an important topic and we’re thinking about it”. Which is fine. -James

Conclusion

Whether getting into YC is something you’re striving for or not, filling out a YC application is one of the best exercises you can do as an early-stage/pre-PMF founder.

Good luck! 🍀