4 ms·

If you are selling digital goods on the app store, you can't use credit cards (and therefore Stripe). You are forced to use Apple's in-app purchase APIs which

If you are selling digital goods on the app store, you can't use credit cards (and therefore Stripe). You are forced to use Apple's in-app purchase APIs which are not very developer friendly (especially for subscriptions) and aren't very complete with regards to metrics. Also, RevenueCat will be around for 1000 years so I reject the notion of us disappearing. :p Actually, I think about that every day. I had a lot of friends who got burned when Parse shutdown and I plan to avoid that. The way our pricing and costs work, we should never have to shut down the service.

kimdotcom 8y ago
What if Mark acquires you?
- jeiting 8y ago
  I will only sell to Megaupload. It's my intention to build the company of my life and run the service forever. I hate the idea of a BigCo buying us, shutting down our service, and screwing over all the devs that trusted us. It would have to be a pretty ridiculous amount of money to make me sell out like that (in case you're listening Mark).
  - privacypoller 8y ago
    I believe that you truly hold this attitude now, but your response could literally be the preface for every "our incredible journey" post ever published.
    - jeiting 8y ago
      Yeah, that's why this objection is pretty frustrating. No one will really believe me anyway so I don't get too worked up trying to convince people. I think we just need build trust in the community. That takes time and I accept that.
    - elwatto 8y ago
      Hi – Miguel here. That is totally valid point. I also think this objection stands true for every dependency of your technical infrastructure. This is the kind of decision you have to make, assessing the risks on a case by case basis. I believe no dependency is 100% safe. It can happen to any given service, from companies like Heroku, MixPanel or Segment to the smallest open source library you rely on. Obviously I think the benefits of outsourcing your in-app subscriptions to us is well worth it, based on our experience and the engineering time you will be saving, but I might be biased :)
  - shanev 8y ago
    Hi Jacob :) Good to see you still building things. I love your optimism but this is something I've heard countless times that almost never holds true. Truth is you eventually get bored of a product after a few years and move on. It's not even always about the money. Also, you're playing in space where Apple could build their own and Sherlock you. I know a thing or two about that.
    - jeiting 8y ago
      Hi Shane! I've grown a lot since the AppLoop days. :) As far as not losing motivation, I can't prove a negative, so I won't try. We are not dead if Apple does something to make the system much better, the problem of multi-channel subscription management will still exist for our largest customers. P.S. Hope L.A. treats you well. I have scooter envy.
gargarplex 8y ago
My experience getting burned by Parse was when the platform was up, it was a flaming pile of shit. Erratic errors, inconsistent downtime, terrible support. The only good thing was the shutdown, IIRC they offered phenomenal support thanks to having the resources of Facebook - 1 year notice, open source software to ease the transition, etc.
- jeiting 8y ago
  This is an excellent, if a little macabre, take on the Parse shutdown. I think they did as good a job as could be done shutting it down. But, I think they missed a huge opportunity though. They could have been Firebase. Maybe making money was an issue but I think they could have figured it out eventually.
  - gargarplex 8y ago
    Thanks for the compliment on my macabre take. Parse was very very good for making it easy to prototype apps. However, once apps began to scale, Parse fell apart and was not a suitable technology. They would not have been able to make money because all the big money comes when people have full scale deployments on a platform, and that simply would not have been possible with Parse's shitty-for-scale technology. Again, very awesome tech for rapid prototyping mobile app development ca. 2012 2013.. It wasn't my decision to bet on the technology; it was in place when I was called in to put out the fires. I have a hard-won personal rule not to bet my organization's technical architecture on any tech that hasn't been around for at least 5 years UNLESS it solves a mission-critical pain point / workflow / etc. I was on the engineering team for another mobile app that did $20M a year in revenue, mostly from in-app subscriptions.. was extremely costly to manage, so seems like you may have a pain point here and a new tech that may be worth betting on. Good luck!

kimdotcom 8y ago

What if Mark acquires you?

jeiting 8y ago
I will only sell to Megaupload. It's my intention to build the company of my life and run the service forever. I hate the idea of a BigCo buying us, shutting down our service, and screwing over all the devs that trusted us. It would have to be a pretty ridiculous amount of money to make me sell out like that (in case you're listening Mark).
- privacypoller 8y ago
  I believe that you truly hold this attitude now, but your response could literally be the preface for every "our incredible journey" post ever published.
  - jeiting 8y ago
    Yeah, that's why this objection is pretty frustrating. No one will really believe me anyway so I don't get too worked up trying to convince people. I think we just need build trust in the community. That takes time and I accept that.
  - elwatto 8y ago
    Hi – Miguel here. That is totally valid point. I also think this objection stands true for every dependency of your technical infrastructure. This is the kind of decision you have to make, assessing the risks on a case by case basis. I believe no dependency is 100% safe. It can happen to any given service, from companies like Heroku, MixPanel or Segment to the smallest open source library you rely on. Obviously I think the benefits of outsourcing your in-app subscriptions to us is well worth it, based on our experience and the engineering time you will be saving, but I might be biased :)
- shanev 8y ago
  Hi Jacob :) Good to see you still building things. I love your optimism but this is something I've heard countless times that almost never holds true. Truth is you eventually get bored of a product after a few years and move on. It's not even always about the money. Also, you're playing in space where Apple could build their own and Sherlock you. I know a thing or two about that.
  - jeiting 8y ago
    Hi Shane! I've grown a lot since the AppLoop days. :) As far as not losing motivation, I can't prove a negative, so I won't try. We are not dead if Apple does something to make the system much better, the problem of multi-channel subscription management will still exist for our largest customers. P.S. Hope L.A. treats you well. I have scooter envy.

gargarplex 8y ago

My experience getting burned by Parse was when the platform was up, it was a flaming pile of shit. Erratic errors, inconsistent downtime, terrible support. The only good thing was the shutdown, IIRC they offered phenomenal support thanks to having the resources of Facebook - 1 year notice, open source software to ease the transition, etc.

jeiting 8y ago
This is an excellent, if a little macabre, take on the Parse shutdown. I think they did as good a job as could be done shutting it down. But, I think they missed a huge opportunity though. They could have been Firebase. Maybe making money was an issue but I think they could have figured it out eventually.
- gargarplex 8y ago
  Thanks for the compliment on my macabre take. Parse was very very good for making it easy to prototype apps. However, once apps began to scale, Parse fell apart and was not a suitable technology. They would not have been able to make money because all the big money comes when people have full scale deployments on a platform, and that simply would not have been possible with Parse's shitty-for-scale technology. Again, very awesome tech for rapid prototyping mobile app development ca. 2012 2013.. It wasn't my decision to bet on the technology; it was in place when I was called in to put out the fires. I have a hard-won personal rule not to bet my organization's technical architecture on any tech that hasn't been around for at least 5 years UNLESS it solves a mission-critical pain point / workflow / etc. I was on the engineering team for another mobile app that did $20M a year in revenue, mostly from in-app subscriptions.. was extremely costly to manage, so seems like you may have a pain point here and a new tech that may be worth betting on. Good luck!