The recipe for open-source startup pitch decks, by a former VC
Here's how to build your open-source startup seed round pitch deck, according to a former open-source focused VC. Including a template.

The recipe for open-source startup pitch decks, by a former VC

Igor Kotua
Igor Kotua
Growth Engineer @

Get notified when customers mention you online - with Crowdlens

What we cover

  1. Introduction
  2. What makes a pitch deck a good pitch deck?
  3. What makes a pitch deck a good open source startup pitch deck?
  4. Recipe for a good open source startup pitch deck 
  5. The wrap up
  6. Useful links


Making a pitch deck for your early-stage startup is hard. Especially a good one. 

This task can be even harder if you are running an open-source startup. During my days at Runa Capital (an OSS-focused VC) I’ve looked at 1000s of pitch decks and heard lots of questions from founders like: “Will VCs understand why we do open-source? Should we show stars as our primary metric? Do they know something about GitHub? Are they going to look into our shitty code?”

Here, at, we want to put an end to these questions and make OS founders’ lives easier. While I don’t know the right answers to all of the questions you may have (at the end of the day, every VC and startup is different), I am excited to share a guide and template on making an awesome OSS pitch deck. The open-source perspective on building pitch decks isn’t well documented, so this template should fill that gap. 

To be thorough, I want to showcase how we came up with a recipe for this pitch deck - namely by analyzing examples from accelerators (YC, 500 startups, etc), from successful open-source startups (AirByte, PostHog), and talking to lots of VCs.

Below we documented our thinking process, but if you don’t want to read through all of it - feel free to jump straight to the deck template we put together for you. You can always come back here and read in detail about every slide (plus there are speaker notes below each slide).

What makes a pitch deck a good pitch deck

To get started, let's take a look at some of the valuable advice from the popular pitch deck template by Y Combinator.

Slide Titles

The YC deck is very minimal; it only has 10 slides, including a cover slide. It’s super focused on the narrative and the slide titles. Why is this important? Well, while you might think your idea is simple and everyone gets it, you are probably wrong. 

Diving into someone else's idea is a comprehensive process, and often, VCs don't have time for this - they typically just “glance through” dozens of decks a day. The harsh truth is that they mostly just read titles, so it’s crucial to have your titles express the main idea of the slides.


Compare the two slides below. Which one is clearer and quickly helps you to understand the content of the slide? 

I stand for the second variant. In the first variant, an abstract title like “the problem” gives you absolutely nothing. It is in bold, in a big font, and at the top of the slide - of course people will read it, but what information will they get in return? Nothing. That’s bad.

In contrast, the title of the second variant gets straight to the point. Additionally, as you state a problem in the title, you are forced to make it succinct, which is a big plus. 


The YC template also puts significant emphasis on the Narrative, and this is, of course, also important for all startups, including open-source ones.

First of all, what exactly is a narrative? I would define narrative as what you say + how you say it + in the order you say it (the storyline). 

Ordering is especially important because it is how you tell a compelling story. But what sort of story do you want to tell to your reader (VCs & other investors in this case)?

I believe there are 6 main types of startup stories:

  • The team story, for those cases, when a team is really outstanding
  • The market story, when you identified a segment which desperately needs your tech
  • The growth story, when you have some crazy metrics early on (or you have a crystal clear understanding of how to achieve them in the near future)
  • The business model story, when you invented a better model to do existing business
  • The technical breakthrough story, when you invented a better way to do something existing / do something completely impossible before
  • The vision story, when you have a super ambitious and unique way to change the world in the future (which really gives you an edge)

Depending on the story you choose and which best suits your open-source startup, you need to adjust the order of your slides. Usually, the “title” of your story should be the first slide in the deck. 

For instance, if you have a super strong founder team that has much experience in this field and has built things like this before, it is a good idea to tell a “team story” right from the start. Basically, every slide after the first one should support the storyline you’ve chosen.

If you want another example, let’s go back to slide #2 from the “titles” examples. It says “Traditional marketing doesn’t work for developers”. This is probably a good start for the “market story”. Here we define an audience (developer marketers, developer advocates, etc) that desperately needs our tech (because traditional methods don’t work, and they need to turn developers into customers in another way).

In essence, make sure that your slide titles summarize what you are trying to say on the slide in a succinct way and make sure their content and ordering support the storyline you are trying to get across. 

Now, let’s get to the meat of open-source specific slides.

What makes a pitch deck a good open-source pitch deck

To start with, let’s have a look at an OSS pitch deck which is considered great by many VCs, the AirByte pitch deck.

This pitch deck has a lot in common with the YC deck (not surprisingly given that AirByte went through YC) but also adds several slides specific to open-source and dev tools:

  • Main Slides related to open-source:
  • Slide #2: Industry context with a market map showing where this solution fits in the stack
  • Slide #5: Why open-source is a good fit for this particular idea
  • Appendix Slides related to open-source:
  • Slide #12: GitHub star growth history chart 
  • Slide #13: Telemetry/number of deployments - any information about deployed instances of your software
  • Slide #14: Detailed comparison with existing open-source competitors 

The AirByte pitch deck does a great job of setting its solution in an “industry context” (slide #2). It shows different components of the data field and how open-source and close-source solutions fit into these components. Thanks to this slide, readers can quickly “map” other solutions on the market and better understand the product's positioning. VCs like that.

Another important slide (slide #5) explains why this product should be open-source and what advantages this open-source solution has over analogous close-source solutions. Of course, in this slide, you can show pretty trivial benefits of open-source like “extensibility”, “data ownership” and other things, but it is much more beneficial to highlight non-trivial benefits like “cover the long tail of connectors” in the case of AirByte.

Last but not least there are some important slides to include in the appendix. The appendix is a good place to show slides with metrics, deployments and other relevant numbers. Let’s discuss in the next section which other metrics you can show to VCs.

Now that we have looked through the YC and AirByte pitch decks, let's try to merge ideas from them and create our own OSS template deck.

The recipe for a good OSS pitch deck (merging ideas from YC and AirByte)

Without further ado, here is the link to our OSS Seed Pitch Deck Template. We encourage you to open this deck alongside this post and switch between tabs. Please note that the deck also has speaker notes that give you more comprehensive insights into each slide. 

From a narrative perspective, this deck tells a “market story”. This is why we chose to start with “industry context setting” to let the reader know where our solution sits in the overall market. Let’s break down its structure slide by slide.

1. Cover

It’s a cover slide. Add your logo and a short description of what you do. Don’t forget to say you are open-source, so readers know that from the very beginning. Make sure your description here is as to the point as possible.

2. Industry Context Setting

The idea of this slide is to provide industry context for the readers. For instance, it is a good place to highlight different parts of the stack of components of the system so the reader understands from the beginning where exactly your solution fits in. Also, if the reader does not know anything about your industry, it is a good place to educate them a bit.

This slide is not always necessary, but if your product is very technical, it is probably a good idea to begin with it.

3. Problem

This is the slide where you describe your problem (without mentioning the solution). It is good practice to describe the problem with some numbers, money or time losses, and other measurable and painful things (don’t forget to include sources).

4. Solution

Describe your solution as simply as possible, highlighting the real benefits (measurable) that you provide.

5. Why we are open-source

This slide is dedicated to explaining why your solution is open-source. You should never do open-source for the sake of open-source or ride a wave. You better have some reason to go open-source which gives you a competitive advantage, faster time to market, enables specific use cases or a pricing model which is not possible without being open-source. 

Aim for non-trivial benefits. Even VCs who are not open-source experts are getting more and more acquainted with the open-source space and will recognize when it doesn’t make sense.

6. Target personas

This slide is about your target personas and go-to-market strategy. Often open-source products have two target audiences: a technical one and a non-technical one (or less technical). For instance, PostHog targets data engineers and product people at the same time. 

Engineers “bring” PostHog into a company to make their lives easier by better implementing tasks from product people. So the end beneficiary of this product are product people. It might be a good idea to highlight this “internal sales motion” on this slide if that’s the case for your open-source product.

7. Growth

This is the right time to illustrate your early success. In contrast with the AirByte pitch deck, I believe you should include this slide in the main part of the deck. GitHub star growth can be used here, especially if you lack other meaningful metrics at this stage. But please remember, stars are not the golden standard, VC’s often prefer metrics like deployments, user feedback, and user sign-ups and in the open-source space issues or contributors. Check out this article on meaningful open-source metrics you can show other than stars for some inspiration. 

8. Team

You know what to say here. VCs love founder-market-fit, if you have anything that proves this in your team, include it. If you have some impressive advisors from the industry, you can also name drop them here.

9. Timeline

Here you should show how you got to today. Pivots, accelerators, releases, launches - all important milestones in your startup journey.

10. Roadmap

This is a slide about your future plans and milestones. It has four sections: product, team, KPIs and cash. Try to realistically estimate things you can achieve until the next fundraise.

11. Ask

Tell VCs how much money you need to achieve all things mentioned above. Remember to highlight how much money (and when) you raised previously if you have already. 

12. Appendix

This is a barrier between the main slides and appendix. Appendix slides are optional, but encouraged. They are usually needed to “dodge”' follow up questions from VCs.

13. Backup metrics / growth 

Depending on what you chose to display on your growth slide, here you can include some more back up metrics. For example, if you have some more logos of companies who already deployed your product that didn’t make it in your main deck or GitHub star growth you can add that in here. is the perfect place to grab your star chart. Some positive user feedback or media attention can also be nice to include. You can highlight all of this in the “Growth” slide, but often you won’t fit it all into one slide and many “Growth” slides may harm the storyline a bit. Leave something for dessert.

14. Open-source strategy

This slide should answer a question VCs usually have: What would make you choose your paid offering if they can use the free open-source version? Here you should describe the differences between your open-source, cloud, and on-premise options - and especially why an open-source version wouldn’t be enough for big enterprises.

15. Competitive landscape

VCs will google your competitors, no doubt. But you have a chance to do it for them and highlight the differences that make your product look more attractive. Just make a table of your competitors and compare them with your product. Don’t forget to mention which of them are open-source (if any).

16. Investors

Last but not least, if you already have some, this is the investors slide. You know what to say here.

The wrap up

Great job making it through our detailed guide - you are one step closer to securing those millions. Jokes aside, the final piece of advice is to treat a pitch deck like a product you are selling. Remember, your customer is a VC and you want to convince and onboard him or her flawlessly. Do your best so VCs can experience the “Aha!” moment as fast as possible.

Last but not least, if you are actively looking for a VC for your open-source company, you should check out our “Awesome OSS Investors List” on Github.

Any questions or suggestions? Feel free to hit up Igor Kotua on Twitter or at

Useful links

Get insights to your inbox.

Once per month. No spam.

By clicking Subscribe you're confirming that you agree with our Terms and Conditions.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.