This is really cool. How do you handle changes of pricing with something like this?

Great question. Basically, you would change your billing.config.ts and update the price.

Then, you run the `sync` command - it matches prices by a composite key: `productId:amount:currency:interval`. Since the amount has changed, it won't find a match for the old price. So, it will create a new price in Stripe and update the Price ID. Your new customers automatically get the new price in the Pricing Table component.

Your old subscriptions stay on the old price - which is still active in Stripe. We haven't added support for migrating these customers to the new price yet but it's in the roadmap!

I would like to add that we've tried making the porcelain / user API for the library to best fit today's commonly uses SaaS pricing models so most actions usually do what you would expect (like this price update) but, it's hard to strike a balance between customizability and the _just works_ factor.

Interesting! Is there an escape hatch to drop down to raw Stripe primitives if someone needs a feature you haven’t modeled yet?

This feels like something many teams eventually build internally — curious how you’re thinking about long-term API surface + compatibility with new Stripe features.

How does this compare to other open source integration platforms like Nango or Airbyte?

I should start by saying that we love Nango & Airbyte, rely on Nango for certain oAuth flows, and support Airbyte as a Connector! I'd say the main high-level differences are:

1. We're built for self-hosting / single-tenant mode and focus on customers with this need. Our data plane runs in a Cloudflare worker on our customer's Cloudflare account, so we never get access to the data.

2. Airbyte is mainly focused on internal ETL data movement. Nango also syncs data into their app DB while we enable you to plug in your DB to collocate it with your app data for easier joins.

3. We'd like to think that OpenInt sits at a higher level than a regular iPaaS as we replace the glue code you'd have to write to bring in traditional unified APIs. Imagine being able to plug in and use both a Plaid and a Yodlee with a unified UI/API. Let them focus on what they do best. Orchestrate aggregators so genuinely become the last integration you'll ever need. More: https://openint.dev/launch-week/introducing-orchestrate-and-...

Hey everyone, we were doing some repo admin and briefly changed the visibility of the repo from public -> private and back to public, then discovered in horror that we lost ALL the github stars and forks! Googling suggests that others have ran into this issue too and github is not able to restore it (see https://www.qovery.com/blog/we-lost-3800-stars-on-github-in-...).

Could you help us by starring our repo and perhaps spread the word? Would really mean a lot! https://github.com/useVenice/venice

PSA: Never change a public repo to private, not even for a moment, because doing so means you will irreversibly lose ALL your github stars and forks, there is no going back! :(

Can you comment on cells and rows ? Document columns?

Congrats on the launch!!

if it's postgres, then 5 mins as shown in the video :) Otherwise what data warehouse are you thinking of and what's the use case behind it?

Can you clarify what you mean by "not out of box" API? We haven't built an integration with Argyle yet but once we do it would be the same experience as Plaid

This is a lesson that needs to be learnt and relearnt over and over again, with increasing level of clarity each time.

@CharlesW we mostly focused on the facts and running as controlled of an experiment as possible without bias or drawing conclusion on exactly why heavier apps get downloaded less. Though my personal guess from working years in the mobile app space is that users are surprisingly conscious of data & disk usage. Not everyone has unlimited data or 128GB storage iPhones.

If you are not modeling causality, then why do you have an "Impact on Installs" metric next to each asset size?

Impact can exist regardless of the underlying cause for impact. It may be because someone's device is full, or does not want to download over cellular, or any other myriad of factors. But you'll still lose an install statistically speaking.

Can you disclose what the limits of that experiment are, and highlight on the website when they are exceeded?

For example, I assume if you tested apps sized 0mb-200mb, the data does not extrapolate as far as Hearthstone, which clocks in at a sizeable 1.2gb!

The largest size we tested was 150mb, that's why the x-axis of the graph ends at that point :)

We like to embrace different technologies and use each for its strength. MongoDB is excellent for a whole class of use cases and we like it a lot, but we also use other persistence solutions as well. Check out Polyglot persistence post by Martin Fowler, it's an awesome read. http://martinfowler.com/bliki/PolyglotPersistence.html

Hi troymc,

Interesting idea. We might look into that sometimes. Our current focus is on delivering a great experience to end users so we are integrating services ourselves one at a time. Don't want to get too far ahead of ourselves. :)