[BinaryIdiot]

I'm always curious why companies like this one choose to charge for their app as a one time fee when, to support the app, they have to subscribe to data feeds which cost money per month. I feel like you have to have a subscription model for that unless the price per month is just so low that, with a small amount of volume, you can easily make up for it.

Either way always an interesting write-up. I do find it odd that so many in SV use the term "sunset" when their company is shutting down. Seems like a weird spin.

[zippergz]

From a purely practical standpoint, it's easier to charge for the app and let Apple do the billing and payment processing, than to set up a system to handle recurring billing (and then you need to deal with cancelations, chargebacks, etc.). I've gone through this thought process for a few side projects, and unless I anticipate really large MRR, it's hard to convince myself to go through the hassle of setting up subscriptions.

[manarth]

Apple supports in-app purchase of subscriptions, so you can still use the standard App-store tools to handle recurring billing.

[lentil]

I think they're restricted to certain types of apps, though? The app review guidelines[0] say:

> "Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected"

I assumed that's why so many iOS apps use non-recurring billing instead. You can still sell access to your service, but users have to manually purchase at each subscription interval.

[0] - https://developer.apple.com/app-store/review/guidelines/#pur...

[intrasight]

This app did sound to me like an enterprise business app. So I agree with other commenters here that the author didn't pivot soon enough to business users.

[zippergz]

Oh, right. My bad. Somehow I totally forgot about that!

[levemi]

> than to set up a system to handle recurring billing (and then you need to deal with cancelations, chargebacks, etc.).

You just plugin the Stripe SDK and set up a Stripe account and it's done. It's not hard. It takes like half a day. You don't have to do any of this manually. If you're a tiny team and you are doing this manually you're doing it wrong. I've never had to worry about chargebacks or cancelations being a problem.

[seibelj]

You cannot use the strip SDK for iOS devices. IAP only. And by that I mean, any situation where you want to purchase something in-app (an upgrade, premium service, etc.) and not a transaction for a real-world good. Real world goods can be purchased using whatever, but digital goods must use IAP.

[wehadfun]

Never used them but https://www.chargify.com/ is supposed to be a service for this. Of course then you run into the disappearing service problem again.

[adamfeber]

I work for Chargify and wanted to comment on the "disappearing service problem." Chargify has been around for over 7 years and has been growing and profitable for the last 4 years. If disappearing services is a concern, we do not plan on going anywhere for a long time :)

[JimDabell]

Apple handle recurring billing for iOS applications too.

[SquidLord]

When you design a service but charge for it as if it were a product, the inevitable result is that in short order you discover that if there is a demand for the service you offer, the demand continues – but your charging does not.

You would think that the consideration of "how will people actually use this application if we're successful?" would come up a little earlier in the design process than four years after implementation and deployment. And yet…

[themodelplumber]

> sunset

They might like that it implies more of a gradation than a binary on/off. A lot of these companies do help people migrate, etc. before going completely offline.