Should reactivity be free? (Reactivity as a premium feature)

So I was thinking of things like scaling, reactivity, business model and other stuff… and I’m wondering, should reactivity really be free, just because it comes for free with Meteor?

I mean, people are paying for bottled water. They could pay for reactivity too.

Does any of you provide reactive features only for premium users, and static content for the rest? If yes, how does it work for your business and how does it work under the hood in your app?

3 Likes

Well, I think the problem is that reactivity is something that a user expects from a modern web application. If you hide such a common feature behind a paywall maybe some of your competitors will provide it for free and you’ll loose users because the handling of your app is too bad for them. It’s not so easy to convert a free user to a paying one, especially when you do not provide more than “reactivity” for money.

1 Like

Yeah I agree, at the markets where most of the competition provides more or less reactive features, like f.e. team management services, it’s surely not going to work.

And the point that reactivity cannot be the only premium feature provided is very important too.

So we have strong arguments against. Will we find the devil’s advocate?

I’m thinking f.e. of situations where developers restrict the reactivity because of the scaling costs it brings. For such applications, providing additional reactivity for premium users could maybe make sense.

So maybe server monitoring tools? Kadira could be an example for that.

1 Like

I’m thinking if you had some sort of monitoring or dashboard tool, it would be easy to sell it based on the update delay - so the cheap version has hourly updates but the fancy version is realtime. But I think it would have to be a tool where the reactivity gives a really tangible benefit.

1 Like

Interesting idea. I think it could be phrased as “single-user-mode” (free) vs. “collaborative” (pay) depending on the application.

I was recently using Intercom for customer support with a few other people and really wishing it was full-stack reactive (some UI elements are, others are not). I don’t know whether I would pay extra for it, since it’s not a cheap service, but I definitely see full stack reactivity as valuable as soon as you add even just one more person to the mix…

1 Like

The problem with this theory is that a reactive app is written completely differently than a non-reactive one. It’s not just a switch that you can flip.

Yes, there are cases where you could turn off reactivity and the app wouldn’t suffer much, but there are many cases where this is not true - you’d have to completely re-write the app, manually add event listeners at both the client and server layers, and so on.

Now, it’s certainly true that until a few years ago, we were all writing apps without automatic reactivity, and IMHO those apps weren’t much worse than the apps we’re writing today, so I sometimes think that the benefits of reactivity are somewhat overstated and perhaps overused. But this is true of any shiny new tool…

4 Likes

One of the neat goals of Apollo is that you can flip reactivity on and off with a switch to trade off cost for UX!

1 Like

Yeah, I can see such cases or ones where it’s more or less close to this distinction.

I totally feel you, lately whenever I see a static website, my frustration grows up, just becasue when I develop with Meteor it’s all so different.

Yes, I’m aware of that and I fully agree. In my case it wasn’t a problem, but to be honest I still don’t know if my non-reactive implementation saves my CPUs anything. Will probably learn that in production.

And that might be very true, I didn’t think of that.

Can’t wait then!
As I hope the whole Apollo user experience won’t be worse than my own amateur functions I’ve written the last few days to switch between publications and methods.

1 Like