Why I Made TwentyMobile Open Source (and Why You Should Too)

The Problem Nobody Was Solving

#

Let me tell you something. I’d been using Twenty CRM for a while — for those who don’t know it, it’s a beautiful, modern, open-source CRM with an active community. Works great in the browser. But I’m a mobile developer. And I do my job on the go: between meetings, at the airport, at the client’s office. Every time I needed to check a contact or update a note, I had to open the browser, log in, wait for it to load… and if I was on the subway with half a bar of signal, good luck.

I was looking for a native mobile app for Twenty CRM. It didn’t exist. I looked for alternatives. Nothing decent. At that point I told myself: I guess I have to build it myself.

From Personal Project to Open Source

#

The first few weeks of development I spent in classic mode: closed source, private repo, nobody sees anything until it’s ready. The typical approach of a developer who’s afraid someone will see their spaghetti code.

But then something happened. I was using Twenty CRM, which is open source. I was using Flutter, which is open source. I was using Riverpod, GraphQL Flutter, Freezed… all open source. My project was literally standing on the shoulders of dozens of developers who had decided to share their work for free.

And what was I doing? Keeping my code closed. It felt hypocritical.

Choosing the License: GPL-3.0

#

When I decided to make the project open source, the first question was: which license? I evaluated the options:

• MIT — Too permissive for my taste. Someone could take the code, close it, and sell it as their own. No thanks.
• Apache 2.0 — Similar to MIT but with patent protection. Better, but still too permissive.
• GPL-3.0 — Strong copyleft. If someone modifies the code and distributes it, they must release their modifications under the same license. That’s what I wanted.

GPL-3.0 protects the project so it always remains open source. If someone wants to contribute, perfect. If someone wants to fork and improve it, perfect. But they can’t take my work and close it. Seems fair to me.

What This Means in Practice for TwentyMobile

#

TwentyMobile is a mobile client for Twenty CRM built with Flutter. What it does is simple to explain but not trivial to implement:

• Contact and company management with fast search, comprehensive details, and optimistic updates
• Notes and voice notes to capture information on the fly
• Tasks with notifications so you never forget a follow-up
• Business card scanner with integrated OCR
• Manual workflows to execute automations directly from your phone

Everything connects to your self-hosted Twenty CRM instance. Zero data collected, zero proprietary cloud, everything travels directly between your phone and your server.

The Fears of Making Code Public

#

I’ll be honest with you: before pressing that “Make public” button on GitHub, I had a moment of panic. The typical thoughts:

“The code isn’t perfect” — And when is it ever? I released with things that still make me cringe. The TwentyConnector is a 52KB file. Fifty-two thousand bytes of GraphQL code in a single file. I know, it’s too big. But it works. And the refactoring will come. In the meantime, the world can see how I solved certain problems, and maybe someone finds a better way.

“Someone will copy everything” — With GPL-3.0, they can copy. But they must keep the license and release their modifications. And honestly, if someone takes my code and improves it, all the better for everyone.

“Who will ever contribute?” — This was the biggest surprise. Through integration with AI agents like Jules, I’ve already received automatic PRs for security fixes, performance optimizations, and code cleanup. It’s not the traditional human-made community, but it’s a community that works.

The Side Effect I Didn’t Expect

#

Making the project open source forced me to write better code. Not because someone was actually reading it — at least not right away — but because I knew someone could read it.

I started commenting more. Structuring commits better. Writing a decent README. Documenting the architecture. Things I should have been doing anyway, but that the laziness of a solo developer tends to skip.

And then there’s the portfolio advantage. When someone asks me “what can you do?”, I send them the GitHub link. Actions speak louder than résumés.

Advice for Those Considering It

#

If you have a personal project and you’re thinking about making it open source, here’s what I’d tell you from my experience:

1. Don’t wait for perfection. Perfect code doesn’t exist. Release when it works, improve later. The community (human or AI) will help you.

2. Choose the license carefully. It’s not a bureaucratic detail. The license defines what others can do with your work. Do your research before choosing.

3. Write a good README. It’s the first thing people see. If the README is poor, nobody will look at the code.

4. Prepare for weird issues. On any open-source project, sooner or later someone will open an issue like “doesn’t work” without giving any context. It’s part of the game.

5. Use CI/CD from day one. Automated tests, automated builds, linting. If the project is open source, these things are not optional.

What’s Next?

#

TwentyMobile is on GitHub, on Google Play, and on the App Store. The project is active, features keep coming, and the code is there for anyone who wants to take a look, contribute, or simply learn something.

If you want to know more about the project, check out the official website. And if you’d like to contribute, PRs are open. Even AI agent PRs are welcome, apparently.

Next time I’ll tell you in detail how the app is built from a technical perspective. Spoiler: Flutter, DDD, Connector Pattern, and a whole lot of GraphQL.