We’re in the home stretch of our seed raise currently, which is very exciting, because I cannot wait to have money so we can go back to product building and community onboarding and pay people who want to work with us.
What we’re building is pretty moonshot-ty (or so I’ve been told), with a lot of moving pieces, and right now, the way I talk about the narrative is very extemporaneous (a term I have just learned from this thread about inner monologues), based on who my audience is, and how well they understand about our market space and vertical.
I figured it’d be really great practice for me — especially as we start thinking about how to reorient the consumer-facing narrative — to sit down and take all of these different components of our pitch, and talk about it as one streamlined, polished story, complete with a character arc and fairytale ending.
So that is what this is.
Part 1: Open source is the future of work
Look. Top talent these days aren’t going to Big Tech companies and joining high profile enterprises anymore. It’s too easy to make it on your own; you can work and grow faster by being scrappy and leveraging the resources at your fingertips; high schoolers are launching venture-backed businesses willy-nilly, and it’s never been a more exciting time to build something you get to call yours.
What we’re starting to see is a huge shift in how people work and build together. Because they’re building on their own, leveraging tools across open source marketplaces (and by this, I don’t just mean public Github repos — look at how much public knowledge you can gain for free through Figma’s community marketplace, or Framer’s phenomenal community ecosystem), the teams they’re working with are modular, decentralized, and pretty small. I don’t think we’re that far away from a future where the majority of knowledge work takes place in smaller 2-10 person teams — I’ve experienced this firsthand by working and collaborating on web3 projects; the “building in public” and crypto builders community is essentially a concentric circle at this point.
What that means is that people aren’t working in hierarchical silos, split by departments anymore. As a designer, your workflow isn’t necessarily in collaboration with other designers as part of a larger team, on longer term projects split by shorter-term sprints.
In a 2-10 person team, you’re building alongside developers on Github, and creatives on Blender, or someone like myself, whose main workflow takes place on Google docs and Notion. That means that the visibility you’re getting into other people’s roles on your team is pretty minimal, for two reasons. 1) You’re not showing up to the same proverbial “office”. You “go to work” in Figma; which means that you’re not having the internet-equivalent of water-cooler conversations with your other colleagues. Even if Figma allows you to collaborate with other people, in real-time, on demand, that doesn’t matter if people aren’t showing up to work in the first place.
2) Even when you have visibility into other people’s work, you have no idea how to interpret that data. When my CTO and co-founder shares his Github repos with me, I have absolutely zero clue what is going on.
It’s not just that we’re working across platforms — we’re working across modalities and mediums. When we use the term open source, with respect to software, your mind immediately turns to code, doesn’t it? And that makes sense too, because Github is the largest open source community in the tech economy.
But that isn’t how software is made! (And my argument here, for the sake of this essay, is that software, whether B2B saas or creative and consumer tech, is the dominant vertical for knowledge work these days). Software is a combination of backend, and front-end, and UX and UI and storytelling and copywriting and brand design and website development — and honestly, GenAI. When we talk about open source software, we should be taking into account all of the different components of an end product and the multimodal inputs they demand.
Part 2: The first order solution
So here’s our first solve.
We’re building a cross-medium platform for multimodal collaborators — think: a Github, that encompasses the end-to-end collaboration experience of everyone on your team, whether they’re a content creator or a coder.
Here’s an analog. Only a few months ago, my workflow for creating decks looked like: 1) creating the content on Canva; 2) downloading that into a PDF; and 3) uploading that to Docsend, to share with other people.
During my consulting days, when I was working on full-fledged teams with managers and designers, we’d use Google slides. But since branching out on my own, I’m in charge of that entire deck workflow, and using Canva gave me A) the collaboration capacity and annotating abilities that Google slides does, and B) inspiration for template and asset design, because I don’t have the design experience myself to build that on my own.
Now, I use pitch.com for my entire workflow. One singular product has wiped out three different tools for me, two of which I was paying monthly subscriptions for. Now, I pay pitch.com the same price for the cost of one tool — and get more out of it, from template design, to intuitive publishing, to the analytics of who is looking at my deck, and for how long. That’s insane!! They have an entire monopoly on the market (or at least, should) because they understand the full end-to-end user journey of what their target consumer needs, for a very niche ICP (people making pitch decks, and similar slide narratives).
We’re not necessarily building anything that unique, as much as we are offering you a more intuitive and easier way to work across teams. The most basic parallel here is a Google Drive or Dropbox folder: you can organize different types of files into various subfolders. But in this new day and age of collaboration, what does a multimodal Google Drive look like, when the “file types” and folder assets are a Figma file, or a Github repo, or even a pitch.com deck?
Part 3: The first order MVP
We’re building a multimodal collaboration tool, but we’re starting with one modality, using pitch.com’s blueprint for how we capture that entire user journey.
We’ve been working on a cross-platform collaboration tool for research-oriented writers, videographers, and podcasters, who need better ways to open source their work to collaborators and contributors, from research to publishing. In the same way that Canva, PDF, and Docsend made up my previous pitch deck workflow, right now, I use Zotero to prepare my research, Google docs to draft, and Substack/Medium/Mirror/whatever to publish — and something like Hubspot if I care about analytics.
We can replace all of that by building a cross-platform “Git” for research-oriented creators.
Honestly, there’s so much potential here and I’m stoked on this direction.
My hands-down favourite podcast is If Books Could Kill — each episode is meticulously researched, and packaged into well-crafted arguments. I pay for their Patreon in order to have access to their Discord, where community discussions about their episodes take place, and where they sometimes ask for input on new material or ongoing research.
But what does a Patreon for research-oriented creators look like, where subscribers can pay to have access to their works in progress? Not just contributing to community conversations, but the actual work itself — the way you might give friends feedback on Google docs today? A Patreon for writers is not what we’re aiming for — we’re aiming to tackle collaborative research communities, like these two that I am personally involved in. But it’s a use-case that, as a consumer, I’m really excited about.
One of my all-time favourite Youtubers is this woman Kaz, who dresses in medieval clothing and talks about Victorian-era topics. The amount of research that goes into her work is intricate and thorough. She doesn’t have a Patreon, but I’d undoubtedly pay to support her — and I’d pay even more to get insight into her content creation process. Think about how much you’d learn, from being able to watch your favourite creators in the midst of their workflow!
Open source research isn’t just an academic endeavor anymore, reserved for the most prestigious of authors. In fact, esteemed researchers with doctorates from Ivy Leagues have been getting called out recently for how fraudulent their work is. And research management tools shouldn’t be limited to one niche of researchers that represent a stagnating market.
Part 4: Giving credit where credit’s due
There’s an aspect here too, of what it looks like to complement a collaboration tool with a workflow management tool like Jira or Asana. But from speaking to enough potential power users, that’s a lower-tier need. The reason for this is because in modular, smaller teams, you’re likely not working on long-term projects that require fully fledged roadmaps — you’re mainly working on adhoc, short-term projects with a clear output and end date…if you’re entrenched in the web3 space, think about this as a manifestation of ephemeral/flash DAOs.
In fact, most of the time, the people you’re working with are different across each project you’re working on. That’s the cool part of open source — that network effect of collaborators that extends over space and time, as you meet new peers through current teammates. And often, who you’re working with from one draft to the next — within the same project — changes, too. For a hot second, Kairon was a part of our founding team, and something that is pertinently on my mind is how we attribute him for his early contributions, even if that work isn’t being reflected in the end product.
Here’s how: better version history.
When we have a collaboration mechanism that enables cross-modality file aggregation, we’re also able to lose less context around who’s doing what, and when. That means that even when teammates flow in and out of project work, we’re able to attribute the work they have contributed to them, down the line.
And starting with research and long-form written content (where the end output for a videographer or podcaster is a script) means that we can really simplify the work to be done around understanding what better versioning looks like — focusing on one modality is far more intuitive than starting with ten. To be clear: Google docs is not it. Sure, you can check out version history, but you lose the context between each version — from comments that have catalyzed the next draft of a document, to who has contributed what at each point in the process.
Once we’ve built the “Git” for collaborative research, it will be a lot easier for us to architect a “Github” for multimodal collaboration.
And once we’ve built the “Github” for multimodal collaboration, we can then extend that from content creation, to contribution, to social publishing.
Part 5: An onchain patenting system
I used to talk a lot about decentralized patents for internet IP, but that is a part of the story that very few VCs have been able to grasp. That’s fair. It’s confusing.
The best way I can describe this to you is by talking about Crowdmuse. If you know me, you know about Crowdmuse, because I won’t shut up about them — and I am honored to call Maz, Eiman, and Tom my Very Good Friends.
Crowdmuse is a platform for commerce — specifically, fashion. They work with different brands and projects to release merch drops — here’s one example, and here’s another. As a consumer, I purchase a physical item on Crowdmuse and receive a token representation of my receipt (which I then redeem for the product itself), alongside other cool digital assets I get access to as part of my purchase — assets that make up the larger IP output of the physical retail product, but exist on their own as individual IP outputs as well (for example, a 3D raw file of this jumper design, or a process booklet about how the product is made).
As a creator, all of my work gets tracked — whether that work is contributing to the manufacturing of raw materials, the design of the product, or the marketing and launch of the drop itself. Sound familiar? That’s where our inspiration for collaborative versioning stems from. (Tangent: the concept design for versioning you see above is inspired by Highnote. I think it’s important to attribute them, too!)
Because all of this contribution is tracked, it’s also easy to figure out who has added what value to the final IP output — and therefore, split profit appropriately between each party. And of course, because all of this data is represented onchain, it also means that there is total transparency in IP ownership. The team wrote a fantastic piece about this which explains it far better than I can.
I’ll be honest: I’ve derailed conversations with potential investors we’ve pitched to in order to pitch them on Crowdmuse. Pretty much the opposite of self-serving, but I genuinely cannot fathom a better team more deserving of investment.
When I talk about decentralized patents in the context of internet IP, this is the flow I imagine — with the addition of versioning.
You publish on Crowdmuse in order to sell your commerce, but in this case, publishing internet IP is more of a portfolio statement than a selling point. This is where I’d consider it a decentralized patent; you have autonomy over the work you consider significant enough to “patent”, and it’s less of a formal protection mechanism as much as it is proof of provenance that your work is yours.
The reason for this too, is that right now the way you showcase your work on portfolio platforms like Contra, or self-hosted sites, is very singular. It’s based on the work that you’ve done. But in this new paradigm of collaboration, IP isn’t singular — it’s shared. That means that being able to track the work you produce in tandem with others becomes a much more important standard for proof of merit than showcasing the work you’ve created in isolation. There’s social validation, which makes it easier for any employer or potential collaborator to trust you, but there’s also the network effect that as the people you’ve collaborated with showcase the work they’ve created with other people, the valuation of your work increases in turn.
There are obviously some plot holes here. For example, how do you track IP ownership when contribution is such a broad term? That’s why we’re starting with written content — that’s the easiest to semantically analyze, and we’ll cross the bridge of templatizing UX/UI, among other digital assets, down the line. But the first step to tracking that in general is still representing all contributions accordingly, whether or not they show up in the end output. That’s why versioning to us is such an important part of the equation.
Story Protocol is another amazing co. thinking about the same things btw, although they’re more focused on content and media IP. They’re also very conceptual, so I’m not entirely sure how they plan on tangibly implementing programmable IP…but they’re backed by some heavy hitters, so I’d assume the alpha is pretty slick.
If you’ve made it this far, congrats. I’m “open sourcing” our deck to you, as a thank you.
Part 6: Onchain AI
Sam Altman recently posited that the rise of GenAI, and soon, AI agents, means that it’s entirely feasible in this day and age for a solo entrepreneur to build a $1 billion dollar business on their own — something that would have been entirely possible to wrap our minds around only a year ago. Isn’t that mind blowing?? The way that exponential innovation through GenAI has totally transformed the capacity for human capital?
And what makes this possible is the fact that GenAI tools are trained on so much data — data that is publicly sourced, and publicly available to all of us (Mira’s recent interview and backlash aside, as well as Elon’s lawsuit against OpenAI) — it’s just that GenAI has the horsepower to ingest things way faster than we can.
That also means, however, that if plagiarism is already a massive problem among creators and open source builders (and indeed, it is), the scope of piracy and synthetic mimicry by GenAI tooling is a million times more problematic.
What’s the solution here? To put everything behind a paywall, or close down open source practices? If the past is any indication to go by, then yes.
It’s a cycle we’ve witnessed time and time again — the pendulum swing between two extremes — across industries, verticals, markets, and technologies. At first, information feels abundant, and resources are virtually free. Everyone’s excited to help each other out, share data, and contribute to open source knowledge.
But as funding dwindles and innovation stalls, information becomes increasingly proprietary — once collaborative, projects turn competitive, treating former peers as antagonists and becoming increasingly wary of theft.
A decade ago we saw this play out in biotech and STEM; in the last bull-to-bear market, we’ve seen that tide turn over through the crypto ecosystem. Once brimming with adages like “public goods are good”, web3 product development has stagnated, as venture-backed projects internalize formerly open source knowledge…much to the avail of developers and builders originally drawn to the “building in public” culture of the crypto economy.
What we need is a dampener — something to quell the force of the pendulum swing.
And putting IP onchain has the potential to catalyze that dampening effect.
Jacob — formerly Coinbase; founder of Zora — wrote a fantastic essay recently on what Zora’s doing to bring AI onchain.
Here’s an excerpt:
Intuitively, it’s such a one-to-one process: AI ingests and spits out tokens; onchain, everything is inherently tokenized. When you put each component of an IP input onchain, that means that we can track — down to the most atomic unit — the actual synthetic output of those components.
“The fact that the final output of AI is valuable likely means that the other components are too,” Jacob says — and when we’re talking about open source software in the context of internet IP, what are those components except the various IP assets that make up different iterations of a final end product?
That’s the second step to tracking the split of IP across different contributors: tokenizing each individual asset in every single version of a “patented” product, so that we can quantify the contributions in the most concrete way possible.
Part 7: A search engine for collaboration
At The Publics, we’re building a search engine for collaboration. We’re noticing that open source communities (like Github) are swiftly becoming the future of work, and we’re building new reputation infrastructures to support social discovery based on what you create, not who you’re connected to.
This was our elevator pitch when we landed on this product pivot back in January. It’s also the story that resonates the most with consumers. Every time I’ve used the phrase “search engine for collaboration” as part of our pitch, it seems to capture both the problem and the solution intuitively, and without fail. Yes, it’s super hard to find and be found in this new knowledge economy — and Linkedin is not it. And yes, the solution is a Google for people; a discovery algorithm that takes into account new data parameters across the social internet.
It’s a little bit of a flip on the way social-interest graphs work today. Right now, the way that you get recommended content on social networks is based on what your friends have liked, and what their friends have liked, and what you have in common with each other. But if the product of discovery isn’t content, but rather people, how do we build search and discovery around what you’re consuming?
And to take that a step further, what does it look like to build search and discovery around what you’re creating?
That’s where onchain production graphs come in.
Everything we’ve spoken up until now ladders up to this point. We’re incentivizing people to curate data onchain, because by curating data onchain, you get credit for your work. And as a bonus: curating data onchain is what helps you connect with other people; other collaborators, based on who they’ve collaborated with, and what you have in common.
There are so many angles to this. What does collaboration look like, when you’re collaborating with content, and not people? What does it look like for me to stumble upon your work, and be able to remix it — and not only give you credit for that work, but put myself on your radar as someone worth connecting with? What if you find my application of your original work interesting enough to expand upon? What does it look like when we’re creating a regenerative flywheel of human capital?
Take it back to the earliest application of this: research-oriented creators. What does it look like for you to contribute to a draft of your favourite podcaster’s latest episode, and have them recognize you for that work — and for you to be able to gain incremental reputation for your contribution, the way that you earn Karma points on Reddit?
What’s cool about this too, is that it brings trust into the pseudonymity equation. You don’t need to know who someone is connected to in the context of a social network in order to have proof of merit that they do good work.
And then — bring onchain social publishing into the mix. What does it look like to find collaborators based on shared project work? To add social validation to that proof of merit?
To us, and to power users, the potential here is endless. But alas, to investors, it has not been — and frankly, it’s tough to prove PMF beyond market validation alone, because the end product itself is so conceptual.
That’s why we’ve landed on cross-medium platform for multimodal collaborators as a tangible outcome of our first order equation. While we’re more focused on reputation and distribution, as users with existing builder networks, a Github for multimodal collaborators helps new talent without networks start to represent their contributions within the context of someone else’s networks — you may not have any reputation of your own, but you can earn incremental reputation by contributing to someone else’s work. And in order for us to represent that contribution, we need to be able to track and contextualize it.
If you’ve made it this far, I’m amazed. Here are two other wonderful decks that Dani of Jam and Tyler of Beehiiv opened sourced recently as well, which provided so much insight as we crafted our narrative.
Thanks again — and you’re the best :)