Great question. I wish Pebble had done this before shutting down. I would have paid double for my pre-ordered Time Steel 2.

Wyze did this recently with their subscription, which they let you pay as little as $0 for. They forced anyone who didn't subscribe onto a lower tier, which only stored still images instead of videos in the cloud.

I believe couple of days ago Wordpress made some changes to their pricing and some people immediately reached for their pitchforks. We all have an inherent tendency to associate greed to any business asking for more or any(!) money.

I believe for that reason, for some founders it is, "you either die a hero or...."

isnt that kind of implied by every service?

If you use something for free, dont be surprised if it isnt there tomorrow.

> I've built an app that I haven't touched in many years with about $1M in monthly revenue (extremely low margin) and it's all good. Yes, it hasn't had any security patches in years

You have a product bringing in $12 million per year (EDIT: I misread the profit remark originally, apologies to Kiro), and you can’t be bothered to do basic security updates?

> it's just a matter of time before it gets hacked but no big deal. If shit really hits the fan I will just shut it down.

You’re basically waiting to get hacked and your response plan is to just shut it down? And turn off $12 million in annual revenue because you didn’t feel like applying security updates?

Are you sure you mean $1 million per month in revenue? Because this doesn’t make any sense at all.

If this is true and accurate, you can at least see why this wouldn't apply to virtually anyone else running a high-profit software app, right? Especially not something like Friday.app which includes customer data.

> $1M in monthly revenue (extremely low margin)

taking a guess that your app is an API wrapper of some kind? the $ you move is basically through your account from customer to service provider on each call and you charge some low flat rate per month for access?

It depends on if their target audience was small companies or enterprises. It may have made a difference, but it wouldn't have changed much for Enterprise customers. At BigCo (a global telecom[0]), it was much easier to add business from a vendor that we already had a relationship with than it was to purchase anything from anyone we didn't. It was also, of course, much easier to buy software/SaaS from one of the existing, boring, established vendors than lesser known/smaller ones. There was a mess of "Purchasing" involvement, legal, and everything else just to set things up so we could make the purchase. I don't know what Friday was for (had never heard of it until, today), but it sounded like it was something that would be company-wide, probably, so sneaking it in with an "expense card" isn't likely going to be defensible.

Then there's the "easy to integrate" side. Expect it to have to pass security reviews if it's SaaS of any kind and will touch any of our IP[1], and particularly detailed ones if it's very easy to "integrate with."

Azure AD Login was easy for us at "BigCo", but tied up several days of more than one grumpy security architecture team member's time with a variety of pen-tests that are required before they'll grant approval for it in our domain. That goes up exponentially to the impossible pretty quickly if it wants permissions to access things on our end via OAuth grants; even things that are typical (profile photo).

IT Architecture might get involved if there would be a need to make sure it worked with our systems, minimally to set up monitoring for it if we're making it available to a large amount of staff because if it goes down, we'll get a million calls into our 4-6 person (state-side by contractual/security requirements) Help Desk over something we can't do anything about and we're going to make sure we have a way to react to it when that happens. Someone's going to have to learn how to do any administrative/integration requirements, because configuration changes, we merge with companies somewhat frequently, and someone's going to have to make sure they know how to set it all back up, correctly, later -- just in case -- even when it doesn't make sense. Likely, BigCo want it to be used, so someone's going to have to write copy for an article for the company landing page explaining what it is, how it works and what problem it solves. There'll be other activities related to this when adoption doesn't take off. IT will have to dedicate some time to tracking usage to make sure we're getting ROI on it when the quarterlies come around and they have to justify every recurring expense, including the ones outside of the sticker price, all over again, and it's easy to trim off the add-on. Plus, they're often the ones who take the budget hit in the first place.

Legal/HR/The Business(tm) might get involved if employees can communicate, uninhibited, through it -- just like they do with E-Mail while they apply a flobbidy-jillion set of restrictions/disclaimers bits of nonsense around. We were not a Defense Contractor, we were just big, spread out and had a lot of employees. At scale, you end up with increasingly many who lack common sense, and a small fraction who still need to be warned about Nigerian Prince scams when one slips through. In a strange alteration of Rule 34, someone will upload porn to it or store porn on it if it is possible to store things on it. For the person who wants the product, it's going to be requiring phone calls, follow-ups, and general "going to bat for the vendor's product" against a hurricane-force headwind.

In fact, an add-on might be less likely to be purchased -- by BigCo, anyway -- because it doesn't do enough to pass the "Why do we need to tie up all of these people to bring this easy-to-integrate product into our environment when they can just use (some terrible excuse for a thing by comparison)?" The "we don't need that bad enough" answer is usually the case for Add Ons, and having a number of ancillary capabilities to distract with sometimes makes it more attractive to "the business" side of the above groups, which has the ability, often, to over-ride all of the rest of the "No"s going around.

At BigCo, an add-on requiring anything that the "good enough to somewhat OK" solution/solutions we already have kind-of sort-of covers doesn't stand much of a chance of being purchased. The one thing that can get in the door is the simple solution that solves a big problem, especially if there's nothing else out there that much of any part of it from any of the big vendors. I spear-headed a small handful of those. It has to be amazing and some reasonable combination of inexpensive, simple to maintain, highly available, non-critical if down (many, many things are unexpectedly critical).

[0] I worked there about a decade for 17 years, incidentally, most of it remote at an organization that was notoriously against remote work ... basically against a major service we enabled and often provided for other businesses. I worked as a software developer in the architecture organization working primarily on security-focused projects (figure that out) and had to go through this process enough to make my soul die a little.

[1] Basically, everything. At least, anything that would have a reason for the company to purchase it.

This was precisely our approach, but we built our own features for the "gaps" that we believed existed in the other products.

If an existing app was doing a decent job, we didn't want to compete with them. The issue is that we ended up arriving in this "dead-zone" where we didn't replace an existing tool and pull budget from an existing category of tooling.