Feedback Wanted: Rallly v4 and Sustainable Self-Hosting

[lukevella]

Hi everyone,

I wanted to share an update as I'm working towards releasing v4 and I'm planning on making some changes that would benefit from community feedback.

The Challenge

Right now, it’s difficult to prioritize work on self-hosted instances because they don’t generate any revenue. All resources go toward the managed service, and self-hosted users often have to wait longer for updates, bug fixes, and new features.

The Solution

I believe self-hosting should remain accessible, but also want to ensure the project is sustainable. If we can give users a way to contribute financially (by purchasing a license), we’ll be able to dedicate more time and resources to making self-hosting a first-class experience for everyone.

The Plan

• Personal Use: Rallly will remain free for personal/self-hosted use (one account per instance).
• Multi-User Setups: A license key will be required for multi-user setups (up to 50 users per instance).
• Pricing: The target price for a v4 license will be $499, but we’ll launch at a discounted rate of $299 and increase the price gradually as new features become available.
• Perpetual License: This is a one-time fee. Once you purchase a license, you can use it forever—no subscriptions, no recurring payments.
• Enterprise: For setups with more than 50 users, an enterprise license will be required. Enterprise licenses offer tailored pricing and support, based on your organization’s specific needs and user requirements.

The goal here is to give organizations self-hosting Rallly a simple and meaningful way to contribute to the project.

Open Questions

I'm seeking community feedback before making a final decision.

• Does this approach feel fair and sustainable?
• Is there a better way to segment self-hosters who can/should contribute financially to the project?
• Would a perpetual license at this price point work for your organization?
• Any concerns or suggestions about the licensing model?

Your feedback will help make the best decision for the community and ensure Rallly’s long-term future.

Thank you for supporting Rallly!

[p-jones]

I feel it is fair but the sustainability might be questionable (because you’re not planning a subscription). That said, I hate subscriptions and would definitely only pay for a perpetual licence. People who come later to the Rallly game, say in a year or two, would pay more while early adopters pay less. That seems good.

I don’t have an organization but I’d gladly pay the $299 to recognize your significant efforts.

[xambassador]

Hi @lukevella, thanks for this amazing app. I have question about is the license apply specifically to v4 only, or will it cover all future versions as well? Thanks.

[lukevella]

A v4 license will work for any future v4 releases (eg. v4.1, v4.2 etc…). When there is a new major release (eg. v5) a new license will be required to upgrade. I plan on offering a 50% discount to v4 license holders who are upgrading.

To be clear, v5 is far into the future at this point and there will be many updates to v4 before v5 is even planned.

[p-jones]

Might you consider a true lifetime licence for a period as you migrate to the new model? That would cover all subsequent versions?

[lukevella]

I'm not against offering lifetime licenses for a limited time or in limited quantities as a thank you to early supporters. I'm just not sure if it would be worth the additional overhead of baking this into the release or if I should just offer this on a case-by-case basis to individuals such as yourself who simply want to support the project.

[david-uhlig]

Who would count as a user? Registered users, poll participants, ...?

We like Rallly, but we're a non-profit, and we use it sparingly. At most a couple of times a year. So, before considering to pay, we would evaluate other free options or alternative ways to get our scheduling done, even if less sophisticated than with Rallly.

[lukevella]

Yes, it would be registered users. Poll participants wouldn't count.

[cleverer]

I really like the licensing of Jetbrains IDEs: you pay a monthly/yearly subscription and after a year you get a "perpetual fallback license". https://sales.jetbrains.com/hc/en-gb/articles/207240845-What-is-a-perpetual-fallback-license

I a perfect scenario i would love to see 3 licensing options:

• Single user: Free for personal/self-hosted
• Multi-User Personal/Self-hosted/NGO plan: Jetbrains licensing model (~40 per year)
• Multi-User Commercial Plan: Similar licensing model and pricing to Jebtrains YouTrack: https://www.jetbrains.com/de-de/youtrack/buy/?section=server

In general i really hate when cool open source tools limit their features or user count for self-hosted and personal use. One feature i hate being paywalled is SSO…
In my perfect ideal scenario the Multi-User personal plan would allow as many users as you want but show the admin user a warning that they are having more than 50 users and need another license if they are a commercial entity.

This would have a lot of benefits: i think a one time fee of hundreds of dollars will deter a lot of self-hosters or enthusiasts, that might wanna use it for their whole family. It also is not really sustainable long-term imho.

It would allow NGOs to also use a privacy minded scheduling tool while still supporting it's development too – often they don't have enough resources to buy full enterprise licenses.

Th only issue could be that enterprises would "illegally" use the personal multi-user plan for commercial entities. However, I believe people using a self-hosted product like this would be honest enough to get a license.

All that said: i'm just talking about self-hosted here. I'm not even sure how many organizations would need an enterprise hosted plan. There i would of course not apply this plan structure.

Also huge thanks for gathering feedback from the community before making a decision! This is why i love using and supporting Rallly 😄

[lukevella]

Thanks for the feedback @cleverer.

I don't intend on implementing a subscription model for self-hosting because:

• I've received feedback that this is a deal breaker for certain organizations
• I want self-hosting to be the avenue for people who want to use Rallly but don't like subscriptions
• It's harder to implement/enforce

I agree that self-hosting enthusiasts might be discouraged if they had to pay a few hundred dollars but they are not the target consumer of a multi-user license. Enthusiasts will be able to use Rallly for free.

I like the idea of a trust-based system where there are no hard limits set. So even without a multi-user license, you can have multiple users registered and using the app but an alert might show up that a license is required. Self-hosters can choose to ignore the alert or purchase a license when they see fit. I believe most organizations will be honest and pay the modest license fee.

[cleverer]

Thanks for your reply!

I'm not sure i understood your initial proposal then: i consider myself a enthusiast, but still need multiple users… I run it on my own servers for my family and friends, free of charge. wouldn't that then already required the 499 license?

Since i also work in software development, I kind of learned to value subscription based services: they provide more financial stability long term, without having to grow your user base. With lifetime-licenses, you might have a decent userbase at some point but then all money might be used up after a few years and you need to invest into getting new users again.

This is also why i like the "perpetual fallback licenses": You can just buy the subscription with a yearly payment and immediately get the perpetual license for that version with one year of updates, if you just want a one time payment. But it also allows for long term supporting.

Another approach that i remembered is how https://workingcopy.app/ does it. You buy the the license of the app (in app purchase, the app is free to download) and get all new features that are released the year after you bought it. After that you still keep that feature set and still receive all bug fixes. If you want a feature that was released after that year, you just purchase another "pro-unlock" for a year which gets you up to date with the features.
Not necessarily a subscription, but you get to keep what you bought and still get updates. But that might be kinda complex to implement for rallly.

[lukevella]

I'm not sure i understood your initial proposal then: i consider myself a enthusiast, but still need multiple users… I run it on my own servers for my family and friends, free of charge. wouldn't that then already required the 499 license?

Yes, you should purchase a multi-user license if you are serving multiple users. If you don't want to, nothing bad will happen. You will simply see an alert saying that you've exceeded the limits of your personal-use license. You can of course, reach out and say that you are an enthusiast self-hosting for family and friends and that you're willing to pay $x for a multi-user license. If I see enough demand for this I might introduce an intermediate tier that has a lower user limit for a lower price down the road.

Since i also work in software development, I kind of learned to value subscription based services: they provide more financial stability long term, without having to grow your user base. With lifetime-licenses, you might have a decent userbase at some point but then all money might be used up after a few years and you need to invest into getting new users again.

I agree that lifetime-licenses are not sustainable, which is why licenses will be for a particular version (eg. v4). When a new major version comes out (eg. v5) you will need a new license. This, along-side subscriptions of the managed service should be enough to make it sustainable to develop new features.

Another approach that i remembered is how https://workingcopy.app/ does it. You buy the the license of the app (in app purchase, the app is free to download) and get all new features that are released the year after you bought it. After that you still keep that feature set and still receive all bug fixes. If you want a feature that was released after that year, you just purchase another "pro-unlock" for a year which gets you up to date with the features.

These subscription models might make sense for desktop apps where the vendor can control the distribution of updates but Rallly is published as a public docker image. It's neither possible nor desirable to stop people from upgrading to the latest version.

[rastacalavera]

Rallly has been great for scheduling meetings for my sports club. I self host it and am the only user so we would qualify for the free license. That being said, I greatly appreciate the work that you do and I think I could convince the club to donate yearly to keep us off of ad driven platforms like Doodle poll or whatever. I am a supporter of devs receiving value for their work and appreciate you taking the time to have an open conversation about what is needed to keep the project moving forward.

[jgwehr]

I have to admit being torn in my reaction. This is such a great project. And supporting it is "right". But, a $299/$499 price tag seems disproportionate to its capabilities. Although - probably - an unfair comparison, my $65/year subscription to HomeAssistant supports a vast feature set and industry standards my family uses every single day. Rallly v4 would need to be relevant for over 7.5 years in "HomeAssitant dollars". Worth noting I'm a single-user environment so really (and graciously) unaffected.

The other side of me sees the potential for Rallly. And I would like to support it in some way. So, to be constructive: perhaps sharing a roadmap and/or communicating that these Self-hosting licenses grant not just first-class updates but first-class roadmap direction? I ask this in part because the login process prevents me from sharing "registered users" with my less tech-savvy friends - and thus not considering a multi-user setup.

In any case, the discussion so far indicates you may be on to something. I hope you and project are successful regardless of my own opinions :)

[cleverer]

Absolutely, i totally get your point of view as well (as i professionally also have to take those decisions).

Just trying to point out possible pain points and/or current unique selling points. And i think the independence of third parties is the biggest one of them, otherwise I as a user might just as well directly go to https://doodle.com/… or at least that's my point of view.

Of course payment through a third party is unavoidable, but having the self-hosted version "call home" constantly to a third party is not comparable to a one time payment (or even monthly subscription) imho, as it would not get direct access to my hosted instance.

[lukevella]

Just trying to point out possible pain points and/or current unique selling points. And i think the independence of third parties is the biggest one of them, otherwise I as a user might just as well directly go to https://doodle.com/… or at least that's my point of view.

Personally, I think there is a very large gap between validating licenses through keygen and using a service with google ads on it when it comes to your privacy.

Of course payment through a third party is unavoidable, but having the self-hosted version "call home" constantly to a third party is not comparable to a one time payment (or even monthly subscription) imho, as it would not get direct access to my hosted instance.

The keygen API is called only once to validate the license. Since it is a perpetual license, there is no reason to make further calls. No access needs to be given, it's just one call that sends the license key to keygen and it will respond with whether it is valid or not.

Note: I do plan on offering offline licenses, but this feature will be reserved for enterprise customers who require it for air-gapped or highly secure environments.

[cleverer]

Fair points. I guess it depends on the implementation. If your code handles the call to the license server I think it is as you lay it out.

Unfortunately i have seen it too much already, that bigger companies shipped an update for their libraries and then later on turning on "advanced statistics and error handling" remotely. So that's why i am always assuming those tools are already containing those features. I'm not even necessarily worried about my personal data here, but more about the image of Rallly and would like to avoid what happened with Moq (https://steven-giesel.com/blogPost/1939d20c-2493-4bf7-9636-96436283fb72, devlooped/moq#1372)

[gxtu]

The keygen API is called only once to validate the license. Since it is a perpetual license, there is no reason to make further calls. No access needs to be given, it's just one call that sends the license key to keygen and it will respond with whether it is valid or not.

Note: I do plan on offering offline licenses, but this feature will be reserved for enterprise customers who require it for air-gapped or highly secure environments.

I don't really see the point in relying on a third party service then. If you're planning to implement them anyway, offering offline licenses for everyone would

• alleviate the privacy concerns with involving a third party
• be cheaper for you and allow you to be more flexible with pricing tiers, since there's no need to take keygen's 100 licenses pricing threshold into account
• be more robust, since there's no risk of connection problems during the license check
• eliminate the need to maintain two licensing systems (offline and keygen) in parallel

I imagine you could just e.g. embed a public key into the application and use signed/encrypted JSON blobs (containing information about the licensee and the version it's valid for) as license keys.

Edit: What happens if someone buys a perpetual v4 license today and at some point in the future

• you abandon the project and thus stop paying for keygen, or
• keygen doesn't exist any more, or
• you change the licensing API provider?

Wouldn't their perpetual lincense eventually stop working (e.g. during a fresh reinstallation) for the version they're using?

[lukevella]

@gxtu I decided to build my own licensing API in the end for most of the reasons you mentioned.

[herget]

Hey, congrats on how far you’ve taken it.

I actually forked the old codebase for a few experiments and really liked the clean approach. It filled a nice gap as an ad-free Doodle alternative. Since WhatsApp polls became a thing, I haven’t used it as much personally, but I still think it’s a solid niche product.

That said, I don’t think a project like this can grow meaningfully like cal .com, especially without similar funding and given the presence of built-in alternatives now.

I’d suggest leaning into charging for the hosted version. If someone wants something free, they can self-host. But if they want the convenience, they should pay for it. Discourse and Ghost are good examples of this model.

Just my two cents — looking forward to seeing where v4 takes things.

https://www.discourse.org/pricing
https://ghost.org/pricing

[lukevella]

Thanks for your feedback. I haven't shared a lot of details about the direction of the project, primarily because I wasn't sure about it myself. For a very long time (until very recently) I was committed to focusing on general scheduling. However, I've decided that it would be better to focus on polling, group decision-making and group scheduling specifically. This is a much smaller niche, but less competitive and I believe Rallly can grow to be the number one tool in the space rather than being a cheaper alternative to a well-funded competitor.

Rallly is B2B software that has some consumer use-cases. The goal is not to make the best tool for scheduling birthday parties and DnD nights. You can of course use it for that purpose and for that it should be free (or use whatsapp if that works for you) but the primary aim is to help teams and organizations make decisions more quickly and provide a better collaborative experience for inter-organizational decision-making.

[herget]

Thank you for clarifying Rallly's direction. Focusing on the niche and B2B market is a good idea. I recommend keeping the approach simple—business models should be easy for you to maintain and straightforward for users to understand.

Why not keep the open-source version available for both commercial and personal use for now? You might end the free and $7/month Pro hosted versions for new users (while grandfathering existing ones). Let self-hosting remain, with support limited to GitHub issues.

For the new hosting plans, perhaps a $49/month "Team" package (up to 5 users, personal email support) and a $99/month "Business" package (up to 20 users, same features)? I recommend A/B testing different pricing models.

Having built a tech company from zero to $10M in annual revenue and tested various SaaS models, feel free to DM me—happy to help out.

[LarsLH]

Dear Luke
First off I'm a very content user of Rallly Selvhosting. Thank You.

The goal here is to give organizations self-hosting Rallly a simple and meaningful way to contribute to the project.
We would like to contribute and I actualle find Your plan interesting.

Open Questions
...
Does this approach feel fair and sustainable?
Yes it does - but I need pricing models for enterprices/municipalities (in Denmark) where we have from 50 to 150 users.

Any concerns or suggestions about the licensing model?
As an IT-consultant in a Danish Municipality I see difficulties in paying with Creditcards as we are only able to pay via electronic invoice.

Thanks
/Lars

[lukevella]

Hi Lars,

Thanks so much for your kind words. I'm really glad to hear you're enjoying Rallly self-hosted!

Indicative Pricing for Enterprise License:

The price will depend on the number of users and any special requirements (such as offline activation). For example:

• Base fee: $499 (includes up to 50 users)
• Additional seats: $5 per user
• Offline activation: +30% surcharge (if needed)

Non-profit Discount:
For non-profit organizations, I can offer a standard 50% discount, or I'm happy to discuss working within your budget.

Payment:
I have a registered UK business and I can issue invoices and accept payment via bank transfer (or electronic invoice, if needed).

If you have any other questions or need a formal quote, just let me know!

Thanks again for your support,

Luke

[Akorian]

Hi, I hope I am not too late for the party.

I must say, that I don't have any issue what so ever with a developer wanting money for their work. But with Open Source there are many factors where I am rather weary. I hope you can shed light on these topics.

---

1. Other contributors. Having a program open source with others contributing to it and then at some point demanding money for it is kinda scummy. It just doesn't sit right with me. Others helped bring this to action. And towards the users such change in direction is also not the best look imho. I want projects to be predictable and reliable. Such change proves to me, that the devs might have other random things in store that might be not for the best of the user, as seen as with the projects that made full OSS rug-pulls. Maybe I am just not aware, but was there at some point a statement / goal / milestone defined for stuff going behind a paywall? But yes, that is not something quantifiable and I also do understand that in the early stages of a project, making money and being 100% transparent to users etc is hard AND also just impossible due to unknown unknowns.

2. What about the license? On GitHub I see the code is AGPL. How are you incorporating your pricing model into the AGPL / to which license will you change (since you cannot modify the AGPL)? Or will there be some dual licensing going on?
   “You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License…”
   Is there other code that is running outside of this license? Is it readable still? Where? Because something I hate is dual licensing and injecting proprietary stuff to FOSS.

3. How are you enforcing the payment? Is there proprietary code somewhere? Do you require connectivity to licensing servers? Can I still just add more users or is the software blocking me somehow? If it is blocking people from the "premium" features how do you protect against forks that just always remove the limitations?

---

I am sorry if I missed information that would have answered any of my questions, but I still hope that these questions can be answered and I hope that I will be able to use rally still - which just depends on the actual openness of the code, its license and the transparency of how the business side of things operate / will operate.

PS:
Did you use a LLM for the original message? The emdash (—) is something I mostly see in AI slop :D

[lukevella]

Thanks for taking the time to share your thoughts.

While there have been a few helpful contributions, the vast majority of the current codebase has been written and maintained by me. I’ve dedicated thousands of hours to Rallly, and in order to continue doing so sustainably, some form of monetization is necessary.

The project remains licensed under the AGPL. The full source code is available and can be self-hosted freely. Monetization is aimed primarily at companies and individuals who benefit from the convenience of a containerized setup tailored for easy deployment. That convenience requires additional work and without funding, updates would be less frequent, documentation would suffer, and support would be limited.

The AGPL also allows third-party providers (like PikaPods, Cloudron, Elestio, etc...) to redistribute Rallly and offer one-click install options to non-technical users. While this doesn't directly generate meaningful revenue for me, it aligns with the goal of making Rallly widely accessible.

License validation is minimal, and usage limits operate largely on an honor system. If someone exceeds the free tier, they’re shown a message encouraging them to purchase a license. It’s easy to bypass and that’s intentional. The goal isn't to block usage, but to offer a clear and fair way for people who benefit from the project to support it.

If someone shares their self-hosted instance publicly, they’re essentially giving away for free what I offer as a paid service. While that doesn’t always mean lost revenue, in some cases it might and I think it’s fair to ask for support in those situations.

Ultimately, my goal is to grow Rallly into a more powerful, useful tool. Monetization helps make that possible, both to support my own time and to fund contributions from others.

[david-uhlig]

I'm not the original poster, but I just want to say, that's a very sensible take, with good points. Especially the public redistribution part, I didn't think about it in that way. These one-click providers benefit from your work without sharing the profits. I appreciate how you implemented the licensing and that you keep the code under AGPL.

Maybe your message is worth sharing in a broader context? It would have been a good statement in the 4.0.0 release message.

[Akorian]

Hi, thanks for taking the time to answer my questions. I fully understand and support paying devs for their work esp. OSS devs. But as stated, monetization using in the OSS world is tricky. But think that you are going a great route with it by not strictly enforcing it. Ans since the code is AGPL, you can't require buying a license since the AGPL forbids that. But your wording in the documentation is smart and I guess works ^^

I just want to clarify:
There is NO code outside of this repo / outside of the AGPL included in the releases of rallly? Specifically the code that checks for a license when the user-limit is surpassed and asks for payment is inside the repo under the AGPL?

[lukevella]

Thanks @david-uhlig. To be clear, the providers I mentioned are the few that do share revenue but there are many redistribution channels that do not and I believe that it's better to leverage this by capturing value through monetization rather than trying to restrict access.

Maybe your message is worth sharing in a broader context? It would have been a good statement in the 4.0.0 release message.

Yes, you're probably right. I did make a statement about the motivation behind monetization of self-hosted instances in the release notes but perhaps there is more that can be said.

[lukevella]

@Akorian

There is NO code outside of this repo / outside of the AGPL included in the releases of rallly? Specifically the code that checks for a license when the user-limit is surpassed and asks for payment is inside the repo under the AGPL?

That's correct, there’s no code outside the repo or outside the AGPL. The license check and related logic are all part of the open-source codebase.

You are not required to buy a license to use Rallly. Anyone is free to self-host it, modify it, or remove the license check entirely if they wish. The pre-built Docker image we provide includes the license prompt and is intended as the primary distribution channel for self-hosting. We don’t offer support for modified builds outside of that, but people are free to go that route if they prefer.

[compgeniuses]

I built a selfhosted App for Nethserver 8, Announced here https://community.nethserver.org/t/rally-event-scheduling-tool-need/23139

Would have loved to contribute in this feedback before being announced. I like the Model fro pricing youre proposing, however for my market, it may not necessarily sail well. Am from Kenya.

[jordankrueger]

Unfortunately I can't see using the package going forward—I self host for a nonprofit, using Cloudron, and we're already paying $200/year for that package. My folks don't see the value in paying $200/year for a scheduling tool like this. I lured them in to paying for Cloudron on the promise of it being cheaper than paying individually and without the kinds of ads we see on Google.

Totally understand you need to sustain yourself, but this doesn’t seem like a viable plan for nonprofits that are already struggling to pay the bills.

[compgeniuses]

bro, you should have just used coolify, or generally installed nethserver... anyway, knowledge for thefuture

[lukevella]

Thanks for your feedback.

I understand that nonprofits operate with budget constraints and I'm happy to offer discounts and custom pricing tailored to your needs to support your efforts.

This license model is designed to support Rallly's sustainability and my ongoing development efforts. If the current features don't provide enough value to justify a one-time investment for a perpetual multi-user license, I need to understand what would.

So, the key question remains: what specific features or improvements would make a Rallly perpetual license a worthwhile investment for your organization?

[jordankrueger]

bro, you should have just used coolify, or generally installed nethserver... anyway, knowledge for thefuture

We use Cloudron to host a number of things together, not just Rallly.

So, the key question remains: what specific features or improvements would make a Rallly perpetual license a worthwhile investment for your organization?

Honestly: If it operated as a Calendly replacement, maybe? We use Rallly as a replacement for Doodle, which is so laden down with ads and a pain to use. Rallly was a good alternative but only as a FOSS alternative when it was a part of the larger package of Cloudron software.

Again, totally understand that you have to make a living! Just telling you how our situation works.

[compgeniuses]

@jordankrueger everything you are hosting with cloudron, coolify can host it, and supports even more, anyway, its just information, do your own research, i think it will save you alot of chums, coolify cloud is $40, but if you selfhost, there is not cost to you.

if you could reduce your cloudron cost, you can then support the underlying projects directly.

[heikkiheer]

I am late to the party. but better late than never.

We are also a non profit organisation: towns soccer club. For the club I am evaluating different participation polling solutions for our coaches.

Pricing: totally fine with me as it is not a montly based model. I really dislike montly payment models for many reasons. I'd rather pay a bigger amount for every major release (similar to Affinity).

[Novapixel1010]

Same I have stopped paying almost every company that wants monthly fees.