In a world where startups are built faster than ever, access to secure, transparent, and affordable tools has never been more important. Enter Marc Seitz, founder of Papermark, an open-source alternative to DocSend that’s changing how founders share and protect their documents.
From studying physics to leading a global open-source movement, Marc’s journey is anything but linear — and his story reveals how curiosity, experimentation, and community can drive real innovation.
From Physics to Software: The Curiosity-Driven Path
Marc didn’t begin his career in tech. He studied physics, fascinated by the universe and cosmology. But after years of waiting on data from telescopes like Hubble, he realized something was missing — instant feedback.
“In software, you write a line of code and instantly know if it works. In physics, you might wait years for results,” he explained.
That instant gratification, coupled with his growing passion for hackathons, pulled Marc into the world of software development. He began building small tools, joining hackathons across Europe, and eventually turning that spirit of experimentation into a business.
HackerBay and the Power of Rapid Experimentation
Marc’s first company, HackerBay, emerged from those hackathon roots. He and his co-founders saw how talented developers — many of whom were non-traditional or even school dropouts — were building incredible things in short timeframes.
HackerBay partnered with major German manufacturers and enterprises, helping them run rapid “micro-experiments” to test digital ideas before deploying them to production.
“We learned that the first version doesn’t have to be perfect — it just has to deliver value,” Marc shared.
That mentality became the foundation for everything Marc would build next.
The Spark Behind Papermark
After HackerBay, Marc found himself frustrated by the legacy data room and document-sharing tools startups relied on — platforms like DocSend, Intralinks, and others that felt dated, slow, and expensive.
So he asked a simple question: Why isn’t there an open-source version of this?
Over a weekend, Marc tweeted his intent to build one. The post went viral. Within days, thousands of people were following the progress of what became Papermark — a modern, open-source platform for secure document sharing and fundraising.
“Founders told me they hated using DocSend — it was clunky, slow, and lacked innovation. We realized we could build something better, faster, and open to everyone.”
Why Open Source Wins
Papermark’s mission is about more than just convenience. It’s about trust, transparency, and control.
By being open source, any user — from a solo founder to a large bank — can inspect the code, host it privately, and know exactly how their data is handled. This makes Papermark especially appealing to enterprises, governments, and financial institutions that require strong compliance and data sovereignty.
“We don’t need to ask customers to trust us — they can see the code. That transparency accelerates everything,” Marc noted.
Papermark’s dual-licensing model allows enterprises to access additional features under an enterprise license while the open-source community continues to innovate and contribute to the base product.
Managing an Open Source Community
Running an open-source company brings unique challenges. Contributors submit code from all over the world — sometimes brilliant, sometimes chaotic. Marc describes being both founder and product manager at once, carefully balancing community contributions with product direction.
“You have to stay compassionate. People contribute because they care. But not every feature belongs in the main branch,” he said.
Papermark encourages small, meaningful pull requests and community-driven feedback, ensuring that the platform evolves rapidly without becoming bloated.
AI Meets Open Source
Marc believes we’re entering a new era where AI and open source are deeply intertwined.
He envisions a world where developers — and even non-developers — can describe features in natural language, and AI agents generate the code for them. Tools like Cursor, Windsurf, and Lovable are early steps in that direction, blurring the line between building and prompting.
“Imagine telling Papermark what feature you want, and AI builds it for you. That’s where we’re headed — personalized, one-of-one software.”
At Papermark, Marc’s already exploring ways to integrate AI review agents that help maintain code quality and filter out low-value pull requests — a glimpse of what open source collaboration could look like in the next decade.
Security, Privacy, and the Limits of “Control”
When it comes to document security, Marc is pragmatic. While Papermark can prevent downloads and track who views a file, true security often comes down to human behavior.
“You can always take a screenshot or a photo,” he said. “The goal isn’t to make data impossible to copy — it’s to make it auditable and transparent.”
In mergers and acquisitions, for example, Papermark’s audit logs help companies prove who accessed what and when — a key compliance requirement that traditional PDF sharing can’t provide.
The Future of Open Source and Startups
Looking ahead, Marc sees open source dominating more of the software stack, even at the application layer where proprietary tools once ruled.
He predicts that AI-generated code will make open source more prevalent — but less visible — as software creation moves from code editors to conversational interfaces.
For startups, the shift is clear: barriers to entry are falling, and founder-market fit is becoming the ultimate differentiator.
“You can build anything now,” Marc said. “So the question isn’t can you build it, but do you understand the problem deeply enough to solve it well?”
Final Reflections
Marc Seitz’s story is a testament to the hacker spirit — start small, move fast, stay open. From physics labs to hackathons to open-source infrastructure, his journey reflects a new kind of founder ethos: transparent, community-driven, and unafraid to challenge incumbents.
Whether you’re a developer, founder, or investor, Papermark’s rise is a reminder that the future of software isn’t just about speed — it’s about openness, collaboration, and trust.
👂🎧 Watch, listen, and follow on your favorite platform: https://tr.ee/S2ayrbx_fL
🙏 Join the conversation on your favorite social network: https://linktr.ee/theignitepodcast
Chapters:
00:01 Introduction and Guest Overview
00:28 From Physics to Software
01:41 Discovering the Physics-to-Software Path
03:06 The Appeal of Instant Feedback in Coding
04:36 Founding HackerBay
05:15 The Rise of Dropout Culture in Startups
06:14 Lessons from Early Experiments
07:25 The Hackathon Mentality
10:30 The Aha Moment for Papermark
11:39 Building an Open-Source Data Room
13:53 Why Founders Embrace Open Source
14:49 Open Source vs Proprietary Software
15:26 Selling to Enterprises and Data Sovereignty
17:14 Transparency and Trust Through Open Source
19:04 Who Uses Papermark
20:59 Licensing Models and AGPL Explained
22:27 Enforcing Open-Source Licenses
23:33 Legal and Ethical Issues in Open Source
24:50 Enterprise Adoption and Pricing
25:31 Papermark’s Growth and Free Tier
28:15 Competing with Incumbents
29:22 Community Contributions and AI Integration
30:45 AI and the Future of Open Source Collaboration
33:43 Control vs Convenience in Software
36:13 Surprising Community Pull Requests
38:22 Managing Product Bloat and Feature Creep
40:32 The Role of Maintainers and Contributors
42:04 Leveraging Community and Capital Efficiency
43:55 Building Publicly and Growing a Developer Community
46:01 AI, RAG, and Secure Document Search
47:15 Is Data Ever Truly Secure?
48:32 Transparency and Audit Logs in M&A
50:31 Evolution of Data Rooms and Compliance
51:02 Adding e-Signatures and Future Roadmap
51:49 The Future of Open Source Software
Transcript
Brian Bell (00:01:17): Hey, everyone. Welcome back to the Ignite podcast. Today, we’re thrilled to have Mark Seitz on the mic. He’s the founder of PaperMark, an open source alternative to DocSend that’s helping startups share documents more securely and affordably. Before that, Mark co-founded HackerBay, helped launch Intel Ignite in Europe and has been deeply involved in supporting founders through venture and open-source communities. Thanks for coming on.
Marc Sietz (00:01:37): Thanks so much, Brian. Thanks for having me.
Brian Bell (00:01:39): Yeah. So what’s your origin story?
Marc Sietz (00:01:41): Well, it’s pretty typical, I guess, went the traditional route through university. I actually didn’t do anything related with computer science and kind of got into that a little bit later. But primarily, I think what really got me excited about startups and software was attending hackathons. So kind of taking on this like non-traditional career path in a way, where you didn’t go to McKinsey four years after university and then another four years in a big company and then maybe start a company after that. I kind of just like dove head in first through hackathons and then making that kind of a business and starting a company right after university.
Brian Bell (00:02:21): That’s amazing. So you actually studied physics and then later moved into software, which is actually a more common path than you would guess in software. I meet a lot of people who did theoretical physics and really smart people. And then you kind of learn how complex data, big data can be in AI and you kind of move into that. What was that transition like?
Marc Sietz (00:02:41): Yeah, it’s interesting. If you haven’t gone through that path, you wouldn’t expect that there’s actually this physics-to-software pipeline. But I think having gone through it, I know why. Just because physics, it’s such an interesting field, but it takes so long to get to an actual result or a success moment. Whereas in software, you write a line of code and you know whether it works or it doesn’t work. So you have that instant gratification, basically, when writing software. With physics, whether you’re on the theory side or on the physical side, you need to run experiments, you need to wait on data, you need to wait that—you know, I was doing cosmologies, we were getting like, I don’t know, ten-year-old data from the Hubble telescope where we have to wait until they actually produce a new telescope that it can send to space, that it then transmits new data back which then will be outdated by the time it’s on Earth. And so that’s very frustrating in the field of physics. So software just kind of made sense. We used a lot of data that we have to crunch together. And doing it with software is like a million times better than with Excel. So it made a lot of sense to kind of dip my toe in and then just build out products and find that path to success much faster.
Brian Bell (00:03:52): Yeah. And I love that phrasing—you know, like you get the instant feedback. I remember when I also came, I came from like finance into tech. And so, you know, I was running Monte Carlos with software and stuff like that. So very statistical and kind of deep in the data. And when I got into software, I, you know, I’m like, okay, I better learn to code. So I took the CS50 course where you build the Google search engine in Python. And I just remember thinking like, this is amazing. I just built like this thing that everyone uses. And it, you know, took me a couple of weeks. I mean, obviously it didn’t take them a couple of weeks twenty-five years ago, but that was my experience. I was like, wow, this is like very powerful stuff that you can just manipulate some blocks of code and some characters on a screen and really add so much value to people.
Marc Sietz (00:04:33): That’s so true. I mean, especially in finance, though, you also have that direct feedback. I mean, more on the trading floor than on kind of like the analytical side, but still you at least work with real-time data. That’s a big album.
Brian Bell (00:04:45): I was actually doing mortgage-backed securities in the bubble of 2007. Yeah, we get instant feedback, but it was garbage in, garbage out in the models, right? The clients would tell us, hey, these loans will default at 8 percent. I’m like, no, I think it’ll be higher or lower. But basically, they told you what the assumptions were so they could get the numbers that they wanted, which is really, really crazy. And then, so tell us about HackerBay. What’s that? And what was the story there?
Marc Sietz (00:05:12): Yeah, so HackerBay was the first company that we founded, built off of kind of like our involvement, like my co-founders and my involvement in hackathons early on, where we just saw that there’s these like incredibly talented individuals that also didn’t go that traditional career path where they, you know, went to high school, then university. So it’s kind of the first time where we really came in touch with like, you know, dropouts, which is so common now in like San Francisco. If you look on Twitter or something on X, everyone’s a dropout—high school dropout, university dropout.
Brian Bell (00:05:43): It’s such a trend right now. I feel like now more than any time in the last twenty years in the Valley, there’s just dropout culture. I have a YC-focused fund, so I invest in a lot of YC companies. In this last batch, I invested in a founding team that were seventeen-year-olds. They dropped out of high school. They decided to forego their senior year, get into YC. And, you know, they have crazy traction and they’re awesome, you know, math Olympiads, like really smart kids. And here they are just hacking together something that’s really useful for society. You know, if you look at the data recently, I think I was watching this on—I think multiple podcasts, like the Allen podcast was discussing this moonshots—is that the perceived value of a college education has dropped precipitously in the last, you know, call it ten or fifteen years. So a lot of kids are just going, you know what? I can use Replit and Cursor and things like this and just go hack something together and go solve a problem. And there’s such a green field with AI right now.
Marc Sietz (00:06:37): Oh, yeah, absolutely. I mean, just the kind of like practical experience trumps like anything theoretical. I mean, I wouldn’t probably recommend dropping out of high school. My daughter just yet. But I mean, she’s not even in that age yet. But I do think about that. Like, yeah, when at least complete.
Brian Bell (00:06:52): I mean, you could drop out to your GED if you had — if you’re a senior. Like, if I have two boys and a daughter, if my oldest son, he’s a sophomore now. So in a couple of years, he’s like, hey, dad, I got this like software thing and it’s generating 30 K a month in revenue and it’s growing really fast. What should I do? I’m like, just go, go for it.
Marc Sietz (00:07:11): Yeah, no, 100 percent. And it’s going to be really interesting. So, I mean, I have still a couple of years to go. So in 20 years or so, she will be making that decision or maybe in 18 years.
Brian Bell (00:07:23): Well, you’re going to — I mean, you’re going to raise your kids in a much different world than I am. I mean, I’m pretty much still in that traditional K through 12 and college. But I think with AI, it’s just going to completely change how kids are educated. What are some other, you know, experiments, lessons that still influence how you think about tech today from your Hacker Bay days?
Marc Sietz (00:07:43): Yeah, so we used to run a lot of experiments for both our own product, but also for our client products. And so we worked with large German multinationals or large IPO-listed companies. The issue was especially among the manufacturing companies — like car manufacturing is very big in Germany, less so than it used to be years ago but still big — and it runs 24 ⁄ 7, 365 days a year, and it just can never go down. Running something in production is extremely hard and difficult, and even pushing that or suggesting that to management is just a non-starter. So what we did is we used to build replicas of their production lines and we would run tons of experiments, micro-experiments basically. And we built our own experimentation platform around that where we could easily deploy something in a sandbox, see the results in a much faster time span than it would have taken us to get real data from a production facility. It wasn’t as appreciated as it probably is now or like in between, but we built something really incredible there that we then could also apply to different software companies or software products that we were building afterwards. And for us what stuck in mind was always this hackathon, this 24-hour hackathon mentality. You can always push something out and get it in front of a client in 24 hours if you just sit through it. It doesn’t take a year or three months of production and discussions just to produce a prototype that can show what value you can deliver to a customer. That got us a lot of meetings and into the door really quickly, and just keeping that mentality of the v0 doesn’t need to be perfect — it just needs to provide value — and you can make it perfect and faster later on. And with AI, obviously, everyone knows that now, or it kind of feels like everyone knows that, that you can just prototype something up really quickly and just see if that sticks, if that adds value or doesn’t. And we just incorporate that into every product that we went on to build. And also now at PaperMark, we do obviously have an extensive preview catalog of just features that we’re trying to test based on customer feedback. We’re just trying to keep that cycle extremely fast.
Brian Bell (00:10:01): Yeah. So tell us the impetus, the aha moment for PaperMark. Why did you guys start doing that? Because you have the incumbents out there, right? DocuSign, I think Adobe bought HelloSign. So there’s probably two or three others I’m forgetting right now. I sign a lot of SAFEs, so I use a lot of eSigns. I don’t know if I’ve ever used PaperMark, maybe once or twice, but why do this when there’s already proprietary ones out there?
Marc Sietz (00:10:25): PaperMark started because I saw a lot of data rooms. And obviously, as a startup at HackerBay and my previous company, we used a lot of data rooms for document-sharing software when we sent our pitch decks for fundraising and whatnot. And what we found is that all of the data-room providers actually are from the early 2000s or at least 10 or 15 years old, even the early 2010s. And it seemed like they weren’t really innovating on that part. And I mean, adding AI to that legacy software was just extremely difficult and slow. So on the other hand, we decided — we’re extremely open-source proponents and we love open source — and we decided there should be something that exists that is an open-source data-room provider. And of course, at the time, DocSend was a pretty large player, especially in the fundraising space. Internationally as well, they made some rounds when they got acquired by Dropbox. And kind of since then, there was like radio silence — nothing on the front of innovation. And everyone that I would interact with said, “Oh, we hate using DocSend. It’s so slow. It’s so ugly.” I mean, there were all kinds of complaints. Their support didn’t work. You can just probably Google it or put it into X and you’ll find tons of complaints. But we decided we could probably build a better solution than DocSend and make it open source. And that’s kind of what we set out to do. Again, with that initial hackathon mentality, we just pushed something out over a weekend and it gained a lot of traction. Before I actually launched it, I sent out a tweet saying like, “Oh, I’m going to build this over the weekend. If this tweet gets, like, I don’t know, 50 likes or something,” it ended up getting like 300 likes and 10 000 views. And then on Monday, when I launched it, it got like 100 000 views.
Brian Bell (00:12:13): It really struck a nerve, right? Because there’s lots of startups out there that are also hackers, right? Most founding teams are hackers. They’re like, you know what? I don’t need to pay DocSend whatever it is, 20 or 30 bucks a month for an inferior product. I can use an open-source one like PaperMark, contribute to the code, get to use it for free, and if I host it myself anyway. And why do you think open source… Do you think open source eventually wins all software categories? Or are there some software categories where open source just can’t win? I think about this a lot as an investor because I see a lot of pitches, and I see the vertically integrated one — we’re going to host it, we’re going to sell it, we have an enterprise sales motion or PLG motion, we’re not going to open source — and then I see the other way: hey, we’re going to go after the open source, we’re going to go bottoms up, we’re going to get a bunch of developers using this. How do you think about that? Put your VC cap on for a second.
Marc Sietz (00:13:02): I think it makes 100 percent sense for a developer-focused tool to be open source or open-source-first, and then kind of add on enterprise features or a hosted version afterwards. Kind of like get in the door, get developers excited early on, and then upsell into the organization. So 100 percent.
Brian Bell (00:13:20): But at some level in the stack, you guys are way up here at the application layer. So why are you guys being successful up here where usually it’s down here at the infrastructure layer where open source usually thrives?
Marc Sietz (00:13:32): Yeah, it’s interesting. So our program — we sell into enterprises, of course — but the way that our data-room offering works is that there are a lot of proprietary data … I mean, it’s used by — so on the fundraising side obviously — which is mostly all private, and so you don’t want your documents or your pictures or anything to get out there and circulate unless you do for publicity reasons, but mostly for M&A cases. Obviously these are private-company sales or mergers. And then on the private-equity side as well. So you need the utmost compliance and data sovereignty. That makes it appealing for larger enterprises where before they either had to build out their own offering for their internal teams and use, or if one of the incumbents would even offer a self-hosted or on-prem solution, they would probably have to shell out a couple million just to get that running on their own infrastructure — if that was even available. And now we can provide that at a much lower threshold. We get a lot of meetings with large enterprises just because of that aspect of being open source and self-hostable. They still don’t want to host it by themselves, but they want that managed on-prem solution just because they vet already the infrastructure. They don’t need to vet just another software startup on the internet. And then I think it’s also like in terms of being open source also has that effect of added security where you can see the source code. You can see if there’s something bad going on — what’s happening with my data that I’m uploading, are there some third-party tools that are listening in or not — you wouldn’t know that with proprietary software, and you’re kind of just relying on the organization. So you have to build up much more trust as an entity that’s marketing and then selling a proprietary solution versus us as an open-source alternative. We don’t need to get blanket trust from our customer. We can prove that we are trustworthy, and we can do that with open source. So that just accelerates our timeline a lot faster. And then, of course, ultimately for us as an application on the application layer, our business model — of course — we also have a hosted version, we have an enterprise license for larger organizations, and then we have a bunch of add-ons. But we have that added ability that if a customer comes along and says, “Hey, we want to extend the platform, we really like this feature,” they can just add that to the platform and to our code and open a pull request. So it’s just as easy as working with your customers together.
Brian Bell (00:16:06): It’s really interesting. And so if I’m evaluating it as a company, I’m looking at it. What kind of founders and companies are getting the most value? You mentioned some — the data sovereignty, the security, enterprises that have pretty secure data needs. What kinds of companies are getting the most value?
Marc Sietz (00:16:25): Yeah, I mean, banks, state-run organizations are probably on the top of the list there because they just don’t have any other option. They would probably alternatively go to AWS or Microsoft and ask them to build something custom with their sales engineers, which would run them up like crazy. And so now they have a purpose-built solution with PaperMark that they can run in their own cluster. But also on our hosted solution, I mean, there’s tons of customers, obviously, or kind of like founders, especially in the early stages. We do have a free version that we want to support. Of course, running this yourself is not your core business. Not everyone should do this and host PaperMark yourself — it just doesn’t make sense because you have other things to do and other businesses than save maybe 10 bucks or something like that. We do have startup programs where we help young organizations get up and running. But also on the A side, we see a lot of transitions from incumbents like Intralinks, Ideals, and others for different types of deals where they just prefer using PaperMark either because of the modern interface, the open-source aspect, the security, and obviously our business model. We don’t have, like, a thousand sales engineers or salespeople that increase the price of the product artificially. So that’s also an upside.
Brian Bell (00:17:53): That’s a really interesting thing you mentioned too, which is the company can extend the product and then do a pull request. What is the licensing mechanism that you use in the platform? What does that pull request process look like? And if I’m using it as an enterprise and I do change something about it, I do owe you back that pull request, right?
Marc Sietz (00:18:11): Yes and no. So primarily, yes, they would probably want to pull-request that into our core product. We do have a dual license. So we have some features that are enterprise-only, which is our enterprise license. It’s still source-available, so you can see everything in there, but just using it is probably not for everyday organizations. It’s just some typical things like SSO, billing, multi-organization capabilities. And the other part is under an AGPL version 3 license, which is the most common open-source license for full-stack applications. It’s a copyleft license, so that means if you do fork or host it or distribute it in any way, any changes and anything needs to be also open source under the same license. So you can’t go off and use it as a base and then make it closed source — that would violate the license.
Brian Bell (00:19:04): You could do it like internally for yourself, right?
Marc Sietz (00:19:08): Yeah, you can of course run it for yourself internally. However, any changes to the source code need to be also made open source under the same license.
Brian Bell (00:19:23): How do you enforce that in the open-source world? I always wondered, like, how do you know?
Marc Sietz (00:19:25): Oh, there’s a whole area in the open-source ecosystem that is analyzing forks and pull requests and can also search forensically across GitHub and other places for certain markers that we have in our code. And then it’s just the same way as with any IP. You have lawyers, both on the trademark and IP side, that will enforce it.
Brian Bell (00:19:51): Have you ever had an issue where somebody ran away with your software and you had to go after them? Or have you ever heard about that in the open-source world? Any interesting stories there?
Marc Sietz (00:20:00): I mean, I did hear about it from a friend’s product — they were using it, and they also have an enterprise part in their application, and they have a ping-back server that’s checking if they use a valid enterprise license. They just send them a cease and desist, and then ultimately they cease the activity and there was not much back and forth actually.
Brian Bell (00:20:24): Usually developers are doing this so they know the drill, they know the license, they know what they’re doing, and they’ll pull a request back.
Marc Sietz (00:20:31): Yeah, and to be honest, no serious organization would steal code and try to host it themselves just to save a little bit. And then, again, they’re not really saving because it also costs you infrastructure and maintenance and security updates, and you need to be intimately familiar with the source code to continue building it. So there are definitely some quality hurdles. But ultimately, if you’re a serious organization, you’re not going to try to steal IP. Everyone would just go the enterprise route and try to see if they can make an agreement.
Brian Bell (00:21:05): It’s like more trouble than it’s worth, it sounds like.
Marc Sietz (00:21:07): Yeah.
Brian Bell (00:21:08): At some point, it’s just like, I’ll just buy the enterprise version. This is like too much work. How do you compare in pricing to DocSend, like both at the kind of the beginning tiers and the enterprise tiers?
Marc Sietz (00:21:18): Yeah. So we offer a free version, which DocSend, I think when they initially started, they used to do that. Probably they closed down the free version after the sale to Dropbox — no idea why. But for us, it’s great because obviously there’s a built-in virality effect: founders or people sharing pitch decks through PaperMark.
Brian Bell (00:21:36): People see PaperMark’s link — I have seen a lot of pitch decks through PaperMark actually. It’s increasingly becoming… I see it, you know, it’s funny because founders, I always want the PDF version of the deck because I use AI to analyze everything in my process, and I need the PDF to upload it into the AI. And I don’t think PaperMark has — there is a downloadable feature. DocSend, though, you can. There are services out there where you can convert it into a PDF. I don’t know if there is an equivalent for PaperMark, but I just tell founders like, don’t bother. I mean, if I really had to, I could screenshot everything. So just let me download the PDF. And not only that, but like for me as an investor, I kind of need that PDF deck memorialized in my database so I know I can get better at my decision-making over time. How do you advise people on the privacy aspects of pitch decks? I mean, sometimes it’s very sensitive and you do need to NDA it and it needs to be not downloadable. For startups, I’m just like, don’t bother.
Marc Sietz (00:22:28): Yeah, no, I agree with you. There’s definitely some type of documents that you don’t want out there and others where you can just offer the downloadable option. I think the only value ultimately then comes from being able to see that, you know, actually, hey, Brian looked at the document and like, okay, like it didn’t just end up somewhere in the ether, got lost, my email didn’t make it, but he actually saw it. And that’s already really valuable feedback at that stage of the startup — having you download it. I mean, that’s obviously an option that they have that they can turn on in PaperMark. But yeah, back to the comparison — we initially positioned ourselves very heavily against DocSend. And, you know, coming in from zero to being the alternative, you have to have that feature completeness up to at least like 95 percent. So until we got there — and now we probably exceeded it in several features that DocSend just doesn’t offer yet — and so we’re looking toward the next incumbents and other use cases. So more than just fundraising, we’re now focusing more on providing data rooms, secure data rooms. And here, most of our competitors are very old incumbents like Intralinks, Datasite, Ideals. On the modern side, there’s a whole other ballgame of organizations using them, but also kind of like use cases in M&A, in law, in real estate, asset sales, etc. So it’s really interesting. And we learn a ton. I think our primary benefit is that we can take in feedback extremely fast from our customers, whereas I don’t know if our competitors are building anything new or — because they existed for so long — they’re probably capped out at what they have to build to deliver to the market. Of course, their products are extremely complex now, but when we hear back from customers, we can reply within like half an hour.
Brian Bell (00:24:26): Not only that, but your customers can just go, hey, I noticed this thing was missing, I built it, or like that.
Marc Sietz (00:24:30): Yeah, exactly.
Brian Bell (00:24:32): I would imagine that makes it so you can move faster because you already have a draft of what that feature looks like from another developer.
Marc Sietz (00:24:39): Yeah, and it will be really interesting incorporating that more into the AI context. So I don’t know, I’m just spinning here, but imagine in the application — because there are obviously non-developers as well — but in the application, you could have something like “suggest a feature,” and it’s connected to like Codex or Cursor Agent or something that’s on our end directly piped into our GitHub. And they could just describe the feature maybe with screenshots or something like that. And they could actually contribute to that feature as a notion.
Brian Bell (00:25:12): That’s a really interesting idea — kind of the vibe-coding of open-source software. Right. And you get these semi non-technical or non-technical users who are like, hey, I really wish it would do this. And so you describe it to a Cursor-like agent, and then it goes and gets the feature kind of working. You’re like, yeah, that’s exactly what I need. And then can you send that back to PaperMark?
Marc Sietz (00:25:33): For sure. It’s like it becomes personal software, right? Like it becomes a one-on-one — you describe what you want to see and PaperMark transfigures or transforms into exactly your use case. I mean, that’s probably a far reach for us, but I mean, it’s good to be ambitious. But no, yeah, it’s an interesting experiment.
Brian Bell (00:25:53): Yeah, it’s an interesting thought experiment. I wonder, as we look forward with AI and agents and Cursor, Windsurf and other platforms like that, I wonder if it’s accelerating. I know it’s accelerating startups and their ability to deliver value faster, but I would imagine that the same is happening in open source as well. Do you see a lot of AI slop kind of being pull-requested in?
Marc Sietz (00:26:15): Yes and no. I think there are these review agents that are really good now. So they filter out a lot. So if it’s junk, they can already review it without me even looking at it and then send a reply and ask for an update or send some comments. So that takes a lot of the maintenance overhead that used to be an issue for open-source maintainers — that takes that away. But yeah, generally across — I think I saw it on like Mitchell Hashimoto’s terminal, like Ghosty. So he built this — the founder of HashiCorp — he built this terminal and it’s open source. And he explicitly wrote in his contribution guidelines: you need to mark whether this was written with AI or not. So that, I guess, by default he will evaluate something written with AI differently. And that’s very interesting.
Brian Bell (00:27:09): So you got to put a little comment string around the code block and say, hey, this is actually AI generated.
Marc Sietz (00:27:15): Yeah, yeah. And I mean, right now the lines are blurred, right? You don’t really know what’s like, whether it’s text or code, like what’s written with AI, what isn’t.
Brian Bell (00:27:24): I would imagine Cursor should build something like that in and say, hey, this is AI generated and untouched by humans. Reviewed, fine, but still untouched. Like this whole block was generated. And then as soon as you go in and edit the block, you could say now, you know, edited by, generated by an AI, edited by a human. Okay, that’s a different code block versus, okay, this is like a human written code block.
Marc Sietz (00:27:48): Yeah, that’s interesting kind of use cases. I think also I feel like GitHub should do a lot more. I mean, they sit at the source on the infrastructure side; they could do a lot more than they’re currently doing. But then yeah, ultimately, is it valuable to know that it’s written with AI? And does it change anything really? Like would you have written it better, maybe, but would it take you longer? Definitely. So it’s all about how much value are you delivering and how much effort does it require. I think there’s always these two trade-offs, no matter what.
Brian Bell (00:28:18): Speaking of trade-offs, I mean, startups are facing this trade-off when they use something like you guys, right? Or open source generally between control and convenience. How do you see open source tilting that balance?
Marc Sietz (00:28:28): Yeah, that’s a really good question. I do definitely see that they actually don’t have to be mutually exclusive. I mean, deploying something obviously requires trust in a way. So you have that convenience factor of using a SaaS, right? Like something that we log in, like all you need is your email or password or just the email and then a link to log in. You can use it if you trust the company, trust that they’re doing well by your data. You probably don’t need anything else. In terms of control, especially when we’re talking about very sensitive documents or data sovereignty — I mean, we have that in Europe, right? Everyone’s talking about hosted in Europe. Especially now, there’s so much marketing happening with “oh, we’re hosted in European servers.” And before it was all about “oh, we’re hosted on German servers.” And now Europe is good enough — I don’t even need to be hosted just in Germany. But you definitely have tooling available, whether it’s Docker, but also cloud platforms make it extremely easy to deploy containerized applications nowadays so that it feels like you have something that can be deployed easily and still have that benefit of convenience while being kind of the owner or controller now of your own instance. And I mean, we saw that with Vercel just making it easy to deploy an application. There’s Railway, which is a great application, kind of took over — I would say it’s like the natural successor of Heroku back in the day. And Railway just makes it super easy to deploy all these different assets. So there are no longer these massive trade-offs that you used to have before, because ultimately there’s also not much magic. And then you have AI, of course, as the glue for any kind of missing content and information that can help you figure out the rest.
Brian Bell (00:30:14): Have there been any surprising features that have been pull-requested in from the community where you’re like, wow, we didn’t even think of that, or that’s really useful?
Marc Sietz (00:30:21): I mean, surprising — there were definitely some unusual requests that we wouldn’t have thought of. I don’t know if they were so valuable at the time. One of them was just completely making the UI customizable. So when you share a link to PaperMark — like a document or a data room to PaperMark — you have kind of like this very form-like interface, right? Where you fill in your email, your name, or something like that, a password maybe. They put in a pull request that would take the whole thing and make it customizable, kind of like a Webflow where you could drag and drop different components on the UI. That would — I mean, on one hand, it’s really nice to have that, but this introduces so much complexity into a product that tries to be relatively simple on both ends, the receiver and the sender. And we just didn’t want to get into the website builder complexity that early on. We know we want to support customizations, but that was just taking it out to the extreme, I think.
Brian Bell (00:31:24): Yeah, that was going to be my next follow-up question — how do you handle pull requests that create technical and product feature bloat, right? Because this is something — I was a product manager for seven years on three different products before. Well, that’s at a high level, probably a lot more than that. But, you know, this is something you constantly wrestle with as a PM. You’re just trying to think, okay, what percentage of users will use this? And what’s the carrying cost of this over time? How do you guys wrestle with that in the open-source world?
Marc Sietz (00:31:53): Yeah, I think not so much different than a PM in an organization. You’re basically the product owner, the product manager — like you’re everything in one person when you’re an open-source maintainer. It helps if you have co-maintainers for sure, that can review code and make sure that everything is aligned with the general roadmap of the product. But of course, you want to also stay open to new commits and new ideas. So I think it’s a lot on making sure you’re compassionate with the person who’s actually contributing, because they are obviously not being paid to do that. It’s either they’re doing it for some reason — they want to experiment and test out their skills while building this, or they have a need for this particular feature that they’re adding, or maybe they misinterpreted some of the roadmap and just looked too far ahead and started implementing that a bit early. And yeah, each of them have different nuances of how you communicate: “Hey, this is not the right time for it,” or “you can fork it and experiment on your fork, but this wouldn’t go into production today.” So there are just different ways of handling it. But ultimately, it’s the burden of the maintainer to decide what goes into the main branch and what doesn’t. And that’s sometimes hard and sometimes easy. But we do typically encourage smaller commits, smaller pull requests, just because it’s too hard to maintain these 10,000-line code changes — it’s just really hard to review. And then it’s also sad because it takes time for us to review, which means maybe the contributor has moved on. If they’re just a drive-by contributor — they see a project, maybe they like it, they throw off a contribution, sometimes half-assed, sometimes valuable — but if they’re not really committed or in it, then if the pull request takes too long, they might not be there to make any updates when we review them. And then it just can’t go into production because we’re not going to sit on that. So we’d probably defer it or just keep it around, maybe they come back — and then yeah.
Brian Bell (00:34:09): So in that case where you kind of deny the pull request into the main branch, they can basically keep running that on their own servers if they want, but they have to maintain it and you’re not taking responsibility and things like that.
Marc Sietz (00:34:21): Yeah, 100 percent. Of course, we will have updates in between, so there will be a divergence between the two branches, between the two forks. And if they want to make sure that everything is still compliant, still secure with patch updates from dependencies, etc., either one needs to maintain that separately or make sure that the upstream can be merged in and doesn’t break anything. And then they have to maintain those breaking merges.
Brian Bell (00:34:52): Yeah, it’s part of the magic here — and I’m putting my VC hat back on again — of open source, that you can do more with less, right? Because you’re kind of leveraging your community basically to just do more of these features. And I imagine if you — I don’t know — Adobe doesn’t probably break it out, or Dropbox for that matter doesn’t break out their data room headcount or whatever. But I would imagine you guys are doing more with less headcount. So you’re more capital efficient.
Marc Sietz (00:35:16): Yeah, yeah, I think so. I think you’re more efficient because of the contributor side, of course. That also tends to go down as the project matures, just because the code base — I mean, naturally any product, as they age, gets more complex. So does the code base. It gets much larger. So it’s harder to maintain or keep an eye on it if you’re not in it full time. We do have some contributors that have stayed around since the early days, and they still merge in pull requests every now and then. But definitely there are diminishing returns to external contributors, just because it’s easy when the project is new and very small to find things that are missing. But as they mature, there’s less to do, and it becomes more of a product that’s being managed from the center on out.
Brian Bell (00:36:11): Yeah, now you’re thinking about technical debt, speed, scalability, security. You’re thinking about other things rather than building out features.
Marc Sietz (00:36:19): Correct. But then also on the other side, open source also gives you incredible leverage in the early days because you’re basically open source. You’re showing off everything already. You don’t have to hide behind like, “Oh, we’ll wait until the version one is perfect and we can reveal it on Product Hunt,” or with a nice press release or with a raise or something like that. You can start shipping and showing at the first commit already. So you can start building your community, whether that’s a developer community or a customer community or just users really from day one. And you just need to be very public about it because you’re already open source. There’s no need to hide. And I don’t understand some — like some of my friends — they are running some open-source projects, but they’re not as public. They’re not showing what they changed, what’s happened. And if you keep that engagement in the public eye, then this will ultimately also convert into users and then customers. So yeah, that’s also something that open source gives you, whereas a proprietary software — obviously you’re not — maybe you ship a website with a waitlist or demo, but like everyone hates those. Nobody wants to see a demo or register to try a demo.
Brian Bell (00:37:34): I want to use — especially developers, right? They’re just like, let me get in the code, check it out, use it. Business users are a little different, right? They’re just like, yeah, just give me the product, I just need the problem solved. But developers are like, give me the tools so I can see how the tools work, you know? Before I go hammer the nail into the wall, I want to evaluate the hammer, the wood on the hammer, and the shape of the alloy used in the hammer. Business users are like, I just need a hammer, I just need this nail on the wall, right? Like, I don’t care how the nail gets into the wall. I just need the nail into the wall. Yeah, true. Different kind of audience. So where do you see PaperMark going in the next three to five years?
Marc Sietz (00:38:09): Yeah, I touched on it a little bit. I mean, there’s obviously — we deal with the document space, secure documents. And if we learned anything from the last two years with RAG and agentic RAG, it’s definitely the place where we’re perfectly positioned to offer some kind of AI search on top of your data rooms, on top of documents. You mentioned that you like the PDF because you can then analyze it with AI — whether that’s in ChatGPT — I have a record of it too, you know.
Brian Bell (00:38:41): When I pass on a startup and they’re successful, I want to go back and go, what did I miss here? And vice versa, when I invest in a startup and they don’t do well, I’m like, what did I miss here? Having that PDF in the data room memorialized, sitting in my G drive somewhere, allows me to go back and say, like, what did I miss here? I’ve noticed with YC founders, they send out PDF decks. They don’t do DocSend or any of that. They’re just like, they must be coached from YC — just shoot the PDF.
Marc Sietz (00:39:05): Yeah, probably.
Brian Bell (00:39:07): And this is kind of like my follow-up question too, which is, is data ever really secure? Because you think about data sitting in a data room, right? Let’s say like, okay, yeah, like you have our back and, you know, some NDAs, whatever, password wallet, right, to get it and look at the data. Let’s say you make it not downloadable, right? This is the problem I was describing. But like, I can take screenshots. Is there technology to prevent me from taking screenshots on Windows? Probably not.
Marc Sietz (00:39:33): I mean, there is actually, but —
Brian Bell (00:39:34): On PaperMark, though?
Marc Sietz (00:39:35): I mean, we have some experiments that we’re running to prevent screenshots.
Brian Bell (00:39:39): But then I could just take my phone out and just take a picture.
Brian Bell (00:39:42): That’s for sure. And then you think about, okay, well, I just don’t want people using the data. That’s a viable use case, right? It’s a bunch of stuff in a CSV or an Excel, and it’s pretty important data, and I just don’t want you to be able to download that and use that data. I think that’s a valid use case. But again, screenshot, take a picture, run it through AI, they’ll recognize all of the numbers on the screen. Maybe you can’t get all the underlying formulas and all the cells.
