Why we keep some code private

We open-source almost everything we build. Our libraries, our rewrites, even the site you’re reading this on. So when someone notices a project on our portfolio that doesn’t have a GitHub link, the question is fair: why?

The short answer is that open source is a choice, not a default. And like every choice, it should be made deliberately.

Not everything is ours to share

The most obvious reason is client work. When someone hires us to build a dashboard, an internal tool, or an inventory system, that code belongs to the engagement. It contains their business logic, their data models, their trade secrets. Publishing it would be a breach of trust — full stop.

This isn’t a grey area. Client code is private because it’s not ours.

We’re proud of the work we do for clients. We list these projects because they represent real problems solved with real engineering. But the source stays behind closed doors, and that’s exactly where it should be.

Some tools are our livelihood

Beyond client work, there’s a second category: tools and products we build for ourselves that we plan to sell or license.

Open source doesn’t pay the bills on its own. We’ve seen too many maintainers burn out trying to sustain projects on goodwill and GitHub stars. We don’t want to be in that position, and we don’t think it’s healthy for the ecosystem either.

So when we build something that could sustain us financially — a desktop app, a paid service, a proprietary tool — we keep the source closed. Not because we’re ashamed of the code, but because we need the business model to work.

This lets us keep doing what we love: building good software and giving most of it away for free.

Open source is a commitment, not a dump

There’s a third reason, less obvious but equally important. Opening a repository means maintaining it in public. It means handling issues, reviewing pull requests, writing documentation, and supporting people who depend on your code.

We take that seriously. When we open-source a project, we commit to making it genuinely useful — not just pushing code to GitHub and walking away. Every open-source project we maintain has documentation, clear licensing, and a development roadmap.

If a project isn’t ready for that level of commitment, we keep it private until it is. Publishing half-baked code under an open license doesn’t help anyone. It creates false expectations and wastes everyone’s time.

How we decide

Our rule of thumb is simple:

1. Is it client work? Private. Always.
2. Is it a product we plan to sell? Private, with clear licensing.
3. Is it a general-purpose tool or library? Open source.
4. Is it a learning project or rewrite? Open source.
5. Is it not ready yet? Private until it is.

Most of what we build falls into categories three and four, which is why the majority of our work is public. But we don’t force it. Open source should be a gift, not an obligation.

The balance

We’ve written before about building in public and why we think transparency makes better software. We stand by that. Sharing code forces you to write code worth sharing. It invites feedback, catches mistakes, and builds trust.

But transparency doesn’t mean exposing everything. A carpenter can show you their workshop, demonstrate their techniques, and share their blueprints — without giving you the keys to their client’s house.

That’s the balance we aim for. Open by default, private when it matters. Generous with our tools, protective of our clients. Honest about what we share and what we don’t.

If a project on our site doesn’t have a link, now you know why. And if you want to see the code we do share, it’s all on GitHub.