I Open-Sourced My SaaS and Here's What Happened

Last week I launched Briefkit — a client portal for freelancers — and I did something that made a few people raise an eyebrow: I shipped it under the MIT license.

Not "source available." Not "BSL with a four-year delay." Full MIT. Fork it, modify it, self-host it, do whatever you want with it. Here's what happened, what I learned, and why I'd do it again.

Why MIT for a paid product?

Let me be honest about the thought process, because I almost didn't do it.

The fear is obvious: if you open-source your product, why would anyone pay for it? Someone will just spin up their own instance. Someone else will fork it and undercut you. You're handing your competitors a roadmap.

I've heard that argument. I've also watched it play out in reverse — GitLab, Plausible, Sentry — where open-sourcing the code builds the business rather than killing it. The key insight is that most people aren't paying for the code. They're paying for the hosted service, the updates, the support, and the trust that you're not going to disappear with their client data.

That last one is where Briefkit's audience is different. My users are freelancers. Developers, designers, consultants — people who have been burned before. They've had clients in tools that shut down. They've seen platforms pivot, raise prices 3x overnight, or just vanish. When I talked to them, the question wasn't "does this have a nice UI" — it was "what happens to my data if you disappear?"

Open source is the answer to that question. If I disappear tomorrow, the code is on GitHub under MIT. You can run it yourself. You're never locked in. That's not a marketing tagline — it's a genuine promise, and it required putting the code where my mouth was.

The stack is Next.js 16 + Supabase + Vercel. Self-hosting Supabase is actually pretty straightforward, and Next.js needs no introduction. Anyone comfortable with those tools can run their own instance. That felt right for a tool aimed at developers and tech-adjacent freelancers.

So: MIT license, added to the repo before launch day. Decision made.

First week stats — the honest numbers

Briefkit launched on February 20, 2026. One week in, here's where things stand:

Signups: 2. Both are test accounts — one is mine, one is a friend I asked to poke around. Zero strangers have signed up yet.

GitHub activity: Low. A handful of stars, no forks, no issues, no PRs. The repo exists, it's public, it has a README. That's about it.

Viral moment from open-sourcing: There wasn't one.

I'm telling you this because every launch post I've read has at least some number to point to. "We got 200 stars on launch day!" or "Hacker News front page!" I did not have that experience. I posted, I shared it in a few places, and the internet mostly kept moving.

That's fine. It's also the truth, and I'd rather tell you the truth than dress up a quiet launch as a triumph.

What open-sourcing actually did (and didn't do)

Here's what I've worked out after one week:

What it didn't do: It didn't generate signups. It didn't drive a wave of GitHub stars. It didn't get me on the front page of anything. If your goal is instant traction, open source is not a growth hack.

What it did do: It made me write better code, because I knew it would be public. It forced me to clean up the README, write setup instructions that an actual human could follow, and add environment variable documentation that I definitely would have skipped otherwise. That's not nothing — a well-documented codebase is a better codebase.

More importantly, it changed how I talk about the product. When I tell a freelancer "the code is on GitHub, MIT license, you can check exactly what we do with your data, and you can self-host if you want" — that sentence lands differently than any feature list I could write. It's a trust signal that I can't fake. Either the repo is there or it isn't.

I don't know yet whether that trust will convert to paid customers. I suspect it will, but I can't prove it after one week with two test accounts.

What I can say is: the people I've talked to who are the most interested in Briefkit are the same people who asked about self-hosting first. That audience exists. It's small, it's specific, and it's exactly who this product is for.

What's next

A few things I'm focused on over the next month:

Finding the self-hosting audience. There's a community of developers who specifically seek out tools they can run themselves. I want to get Briefkit in front of them — not to convert them all to paid users, but because they give the best feedback and they'll stress-test assumptions I don't even know I'm making.

Building a feedback loop. Right now the feedback channel is basically me DMing people. That's fine for now, but I want a more structured way to surface what's not working. GitHub issues will be part of that.

Shipping the next few features. The MVP is intentionally thin. Client onboarding, file sharing, basic project tracking — there's a lot of ground to cover, and I'd rather build it with input from real users than in isolation.

Being honest about growth. I'm not going to paper over a slow start. If next week's numbers are the same, I'll say so. If something works, I'll say that too.

Try it / Fork it / Tell me what's wrong

If you're a freelancer who's been looking for a lightweight client portal — try Briefkit. It's early, it's rough in places, and I want feedback more than I want you to be polite about it.

If you're a developer who wants to poke at the code, read the setup docs, or just see how we're doing things — the repo is on GitHub. Fork it. Open an issue. Tell me what you'd do differently.

And if you've gone through a similar launch — open source or otherwise — I'd genuinely like to hear how it went. The honest version, not the polished retrospective. You can find me at @briefkit_dev on X.

One week down. A lot more to go.

— Bob