Vibe Coding Needs Receipts

On June 25, 2026, Papermark's Marc Seitz published a post on X accusing Nico Laqua's Corgi DataRoom launch of using Papermark's open-source and enterprise-licensed code. The post asks Corgi to take the product down and includes screenshots comparing parts of the DataRoom interface with Papermark screens.

My read is deliberately cautious: the public source is a serious allegation, not a completed code audit. But it matters because Corgi's own launch message framed DataRoom as something the team built for itself, and Corgi's site presents it as a one-workspace answer to document sharing, signatures, data rooms, and analytics. When a product launch leans on speed and self-built credibility, a provenance challenge becomes part of the news.

Answer Snapshot

Question	My read
What happened?	Marc Seitz publicly accused Corgi's DataRoom of infringing Papermark code and attached screenshots that compare similar product screens.
What Corgi had launched	Nico Laqua's launch post said DataRoom was released by Corgi as a cheaper alternative to DocSend-style sharing, while Corgi's launch materials describe sharing, e-signatures, virtual data rooms, and engagement analytics in one workspace.
Why it matters	Papermark's public repo is open source, but its license file and enterprise folder draw a boundary around commercial features such as data rooms, Q&A, and advanced permissions.
My takeaway	"Built it ourselves" needs receipts now: source provenance, license compliance, attribution, and a public explanation when a credible maintainer raises a code-origin challenge.

The Launch Promise Is Real

The reason this blew up is that Corgi's pitch is easy to understand. In the launch post, Nico Laqua said the team released DataRoom because it did not want to spend thousands on DocSend. A Corgi launch release says the product combines secure sharing, e-signatures, virtual data rooms, and engagement analytics, and that it began as an internal tool for Corgi's own operations.

Corgi's own About page tells the same story in more operational language: insurance work runs through documents, and Corgi wanted sharing, signing, rooms, and analytics under one login. If that story is clean, the beneficiaries are obvious. Founders, sales teams, legal teams, and finance teams do not love stitched-together document workflows.

That is why the allegation matters. The product category is not trivial. A data room touches confidential documents, access control, audit trails, recipient analytics, signatures, and customer trust. This is exactly the kind of workflow where the build story and the trust story cannot be separated.

The License Boundary Is the Story

Papermark's GitHub repository describes the project as an open-source document-sharing alternative to DocSend, with shareable links, branding, analytics, and self-hosting. That alone does not make every commercial reuse suspicious. Open source exists so people can inspect, modify, and build with code under defined terms.

The important detail is that Papermark is not a flat permissive-code bucket. Its top-level license file says content outside specified enterprise areas is AGPLv3, while content under the enterprise paths is governed by a commercial license. The enterprise README lists Data Rooms, Q&A Conversations, and Advanced Permissions as Enterprise Edition features, and the commercial license limits production use to customers with the right commercial subscription.

That is the practical center of the dispute. If Corgi independently built a similar product, it should be able to say so. If it used AGPL code, there are compliance obligations to examine. If it used enterprise code, the question becomes whether there was a valid license. The public material I inspected does not answer those questions, and that absence is the point.

The Screenshots Are a Signal, Not a Verdict

Seitz's attached images compare settings and danger-zone screens. I can see why they caught attention: the examples involve similar language around replicating folder structure and similar destructive-action layouts around freezing or deleting a room. That is enough to make the provenance question concrete rather than abstract.

But the next step cannot be a pile-on. Similar UI ideas, copied copy, copied component structure, copied code, and use of enterprise-only code are different claims. The evidence bar should rise as the accusation gets sharper. A code diff, dependency notice, commit history, source release, or license grant would move this from social-media allegation toward something more inspectable.

What Public Reaction Reveals

The public reaction I found was not one-note. One quote-post framed the launch as part of a broader trend where agentic development lets companies ship free lead-generation tools faster. Other posts were more skeptical, including criticism of the YC-free-year offer and claims that the product looked copied.

I would not overread that as a consensus. It is better evidence of a tension. People like cheaper tools and faster internal-tool-to-product loops. Maintainers, developers, and buyers also want to know whether the speed came from legitimate reuse, licensed reuse, or something murkier.

The AI-Era Trap

The phrase "vibe code" is useful here because it captures how product storytelling has changed. A founder can imply that a small team moved fast with modern tools, and the market will often reward that. But AI-assisted building does not erase authorship, license obligations, or provenance. If anything, it makes those records more important.

The danger is that teams start treating "the model helped" as a fog machine. That should not work. If a product uses open-source code, say which code and under what terms. If it uses commercial code, keep the license trail. If it was written from scratch, preserve enough engineering history to answer a credible challenge without turning the response into vibes versus vibes.

My Takeaway

The allegation against Corgi may be resolved by a license, a source release, a rewrite, a takedown, or a public rebuttal. I do not know which is true from the public record I inspected. What I do know is that "we built it ourselves" has become too important to leave unsupported when open-source maintainers raise their hand.

This is the standard I want more AI-era product launches to meet: move fast, but keep receipts. The receipt is not just a legal defense. It is how a team proves that speed did not come at the expense of the builders whose work made the launch possible.