UCombinator

Startup Submission 01: Product Pitch

Introduction

UCombinator requires that each startup submit a product pitch that explains the product that your startup wants to develop over the course of the semester.

Your product needs to:

  • Be a desktop web application. UCombinator specializes in web applications, and will not accept other types of applications. In addition, mobile web applications are strictly trickier than desktop web applications, so UCombinator would rather see desktop web applications.
    • UCombinator will let startups write mobile web applications if they demonstrate that they have the ability to execute them without additional support.
  • Use React, Bootstrap, Node.js, and MongoDB. UCombinator specializes in these four technologies, and will not accept startups using alternative software stacks.
    • Startups can use helper libraries where appropriate, but must use these four core technologies.
  • Support multiple user accounts. Your product should let users create and log into their own accounts. Although we will mostly be focusing on a single login environment for most of the semester, the product and pitch must be a multi-user application.
  • Use a database. Your product needs to store information, including user account information, in a database.

Your product cannot:

  • Be a game. UCombinator does not consider games to be web applications. The skills required to create an online game are very different from the skills required to create a web application.

Your product does not:

  • Need a profit plan. Startups like Twitter and Facebook began with an interesting idea, but no immediate plans for profit. They launched and operated for years without advertising. UCombinator does not care or need to know if your idea would be profitable. However, to simulate reality your team should consider how your could profit and be ready to answer that question during the pitch party at the end of the semester.

The pitch should have a minimum of 1” margins on all sides (Microsoft Word’s default setting), be written in a 12-point font, and be single-sided. No extra space will be allotted. Use of the Helvetica font is encouraged, but not required.

Grading Rubric

UCombinator will grade the pitch using the following rubric:

  • 25% Clearly written
  • 25% Displays a clear understanding of the idea underlying the product
  • 25% Contains a brief description of the product’s relationship to existing applications
    • Example 1: TikTak lets you anonymously and privately tell friends that their breath needs freshening. TikTak is similar to YikYak in that you can only share messages with users in the surrounding physical area. Unlike YikYak, TikTak messages are sent privately to individuals, and only concern the person’s breath.
    • Example 2: Chairity lets you list furniture that you would like to give away. Like eBay, Chairity lets you drill down into the category of item you want. Like Craigslist, Chairity is focused on local transactions, as users must pick up items that they want.
  • 25% Contains a brief overview of the technical challenges of the product, and how you plan to overcome them
    • Examples of technical challenges:
      • Your product involves managing multimedia or some other complicated type of data, and a library exists to do that.
      • Your product interacts with an external service (e.g. Twitter), that service has a free-to-use API that contain the functionality you need, and someone in your startup has used that API before.
      • Your product needs to use a complicated algorithm, which a member of your startup is deeply familiar with.

If UCombinator finds your pitch unsatisfactory, or has doubts that your startup could complete the product within a semester, UCombinator will council with your team and potentially require a second, updated pitch.

Honors Student Feature Pitch

Separate from the product pitch, each honors student on your startup must write up a pitch for a product feature that they will develop independently.

The feature must:

  • Require end-to-end changes to the product. In other words, the feature needs to require custom HTML/CSS, server logic (e.g. for fetching/modifying data associated with the feature), and new types of data in the database.
  • Be reasonably isolated from the rest of the product. Your startup should not need to maintain any of the honors students’ code, or be encumbered by it. If an honors student is running behind on their feature, it should not hold up the rest of the startup in any way. Similarly, if the startup is running behind on the product, it should not hold up the honors student.
  • Be implemented entirely by you. While honors students can (and should!) consult with their fellow startup members, they must implement the feature themselves.
  • Make sense for your startup’s product. This should be self-explanatory.
  • Be approved by your startup’s members. If the idea is contentious, and not all startup members agree, it must be decided by majority vote. The honors student must abstain from the voting process.

The feature cannot:

  • Be a game. For the same reasons why a startup’s product cannot be a game.

The honors pitch should have a minimum of 1” margins on all sides (Microsoft Word’s default setting), be written in a 12-point font, and be single-sided. No extra space will be allotted. Use of the Helvetica font is encouraged, but not required. Your document needs to have signatures from every member of the startup, affirming the following:

We, the undersigned, do hereby affirm that we have read the above pitch describing a product feature (subsequently referred to as THE FEATURE), and declare that 1) THE FEATURE is appropriate for our startup’s product, 2) implementation of THE FEATURE will not impact the main product’s development, 3) (name of honors student) is solely responsible for designing and developing THE FEATURE, and 4) members of the startup other than (name of honors student) will not help implement THE FEATURE.

Honors Grading Rubric

UCombinator will grade the pitch using the following rubric:

  • 25% Clearly written
  • 25% Displays a clear understanding of the idea underlying the feature
  • 25% Contains a brief description of the feature’s relationship to the startup’s product as a whole
    • Example 1: This feature adds live chat support to TikTak. While TikTak simply lets you tell friends that their breath needs freshening, TikTak FreshChat™ gives you the option of opening up a meaningful, anonymous, two-way dialog about the merits of fresh breath.
  • 25% Contains a brief overview of the technical challenges of the feature, and how the honors student plans to overcome them

If UCombinator finds an honors student’s pitch unsatisfactory, or has doubts that they could complete the feature within a semester, UCombinator will council with the startup and potentially require a second, updated pitch.

Example Honors Features

Here are examples of bad and good features.

BAD FEATURES:

  • A feature that adds photo posts to a Facebook clone.
    • This feature is not reasonably isolated from the product. In order to implement photo posts, the honors student will need to modify the Facebook clone’s core posting logic. If the honors student makes a mistake or implements the feature poorly, it will impact the product’s core feature set. In addition, if the startup fails to implement the core posting logic in a timely manner, it will hold up the honors student’s progress.
  • A feature that adds the choice of a more condensed news feed to a Facebook clone.
    • This feature is not end-to-end. It does not require any meaningful database changes, and may not even require any server changes.

GOOD FEATURES:

  • A feature that adds chat support to a Facebook clone.
    • This feature is end-to-end, as it stores chats in the database and requires a chatting interface. It is also isolated from the core product. It uses Facebook users in the database, but otherwise maintains separate data.
  • A feature that lets users view a slideshow of nearby cat pictures on SnapCat.
    • This feature is end-to-end, as it requires database changes to store SnapCats by location and a frontend for viewing those SnapCats. While it uses data produced by the core product, it can be developed independently with sample data while the startup works on the core product features.
  • A feature that lets users subscribe/unsubscribe to email notifications.
    • This feature is end-to-end, as it requires an interface for managing notification settings, database changes to store notification settings, and server logic for emailing notifications. While the feature will need to integrate with core product features, the integration should be trivial (e.g. an extra function call) and should be easily worked around should the honors student not deliver on the feature.

Submission

You must submit a PDF of your startup’s product pitch as well as any honors feature pitches by the assigned due date on Moodle. Only one member of your team needs to submit to Moodle.