With my open-source product I'm in a very similar place, and I do _mostly_ the same thing. My product (https://httptoolkit.tech https://httptoolkit.tech) is a

With my open-source product I'm in a very similar place, and I do _mostly_ the same thing. My product (https://httptoolkit.tech https://httptoolkit.tech) is a debugging proxy app. The codebase is broken up into a few modules: a desktop shell, a UI, a backend component for the UI, plus a standalone proxy library and a bundle of smaller libraries that do everything from detecting & launching browsers to reparent react components around the DOM (if you're interested, they're all on github: https://github.com/httptoolkit/ https://github.com/httptoolkit/). All of this is open-source, with some premium features behind a subscription (but even those are open-source, it's just you'd have to fork it to remove the subscription checks, and it's not worth the time of any professional to maintain their own fork of the whole project). The core product is AGPL, but nothing else. More specifically, product-unique components are AGPL (the UI, the backend, etc) where there's no clear case for ever reusing them other than duplicating/forking the product, but everything else is kept under permissive licenses, mostly Apache 2. This is mainly because AGPL really limits practical freedoms in business contexts: It's harder to get sign-off to contribute to (A)GPL libraries, even in a one-off script nobody wants to risk using an (A)GPL library and it would become much harder to find contributors. So far I've found this has worked pretty well for me, and I'd recommend it to others, including Plausible. Put only the core product-specific components under AGPL, but keep everything that might be useful to somebody building a completely different product under more relaxed licenses wherever you can to ensure you can fully engage with the open-source community.