The idea of splitting off payment plans into its own abstraction is super interesting. Personally I would really like if the abstraction layer also was independent of the payments processor, currently it seems heavily dependent on Stripe. Even though I currently use Stripe I find them to be untrustworthy and don't want anything that ties me to them even further. And more generally, using a platform built on top of a SaaS is a recipe for future headaches.
I think they abstracted the problem so away that they have no idea what they are talking about. Having a single file that contains all your plans and make both your app, marketing pages, and Stripe work from it is trivial and is just good engineering. It's not a "Pricing Engine" or a "Pricing Stack".
To expand, pricing engines also don't solve other product/licensing problems. At $dayjob, I work on a team that seems to have independently designed almost exactly what you've outlined in PriceOps.org (in January of 2022, right when PriceOps was being initially written), but we've also then had to use it for a year and change. The biggest thing we've learned is:<p>> <i>Just because you have this new "can represent and track everything system" does not mean a customer can transition from one plan to another plan without massive problems.</i><p>Big new plans that are very different from previous plans often come about because of large-scale reorganizations of the product. The issue is that with a big change in the way the product is organized, there might be application state under plan A which is literally unrepresentable under plan B, requiring the customer to manually migrate their application state from plan A to plan B, since it's impossible to do safely in an automated way.<p>I'm currently living through this fundamental oversight : )
Tier seems to be solving a real problem that every company beyond MVP stage will face.<p>What I would love to see is a tool that would make it easy to run multi-variant pricing experiments and give me the optimal pricing down to geo, platform etc. "Optimal" being the maximum cash collected.
It's looks cool. As someone who have been maintaining (among other thing, we also have our actual product) a home made pricing engine, I appreciate the value of this kind of thing.<p>In our case, stripe support wouldn't be enough though (we also need playstore & apple IAP, PayPal, other CC billing engine), and the truth is even if support excited, migrating would probably so painful that it would probably not be worth it (even though I'd happily throw away all those lines of code)
Is this product extensible beyond SaaS style tiered subscription models?<p>I love the pricing space, but at first glance, the limitation in your company's scope seems depressingly limited and is essentially hard-coded into the name of your company (Tier).<p>I have grandiose ideas, hopes and dreams of what the pricing space will look like in the future, and it doesn't involve immutable JSON files.<p>But I can see why this would be really useful right now. Looks great.
My company is building in the same space as Tier - in fact our offering looks close to identical.<p>The problem we've faced so far is catching buyers who want to solve this problem, the deeper, underlying issue, rather than the problem that's in front of their face.<p>For technical contributors, they're usually tasked to throw up a paywall, and you can do that quickly and easily using your billing engine and some lightweight hard-coded logic.<p>For the business stakeholders, they're usually paralyzed by an inability to decide what the pricing should be, and implementation is an engineering problem. I spoke to one buyer recently who was doing a re-pricing exercise (which Tier and Stage both promise to make easier going forward), but even he believed that this re-pricing would be the last, and that further adjustments would be minimal.<p>It's nice to see other, credible people enter the space - I think it actually is a problem worth solving, and it's neat to see how their approach rhymes with ours. Of course I don't wish them <i>too</i> much success, since I'd like to have some customers too.
Oh neat, I'm coincidentally trying to setup tier rn.<p>Bit stuck in progress following Vercel template here <a href="https://vercel.com/templates/next.js/tier" rel="nofollow noreferrer">https://vercel.com/templates/next.js/tier</a><p>But I've already built out my own stripe usage-based billing app b4, and it sucks way more to debug that, so I get what you're trying to do here.
Tier looks great. But unfortunately Tier's commit history on their main branch looks close to abandoned. I'd much rather pay money than risk picking unmaintained solo-dev OSS. If we're gonna end up having to manage the code ourselves I'd rather we write our own abstractions. Tough chicken and egg problem for them, I hope they solve it.
I'm working on an internal pricing service that interacts with Azure. I'm not looking to use this service since I certainly would not want to create yet another external dependency, but will agree that pricing can be complex. For example, I was a bit shocked that there are over 450,000 individual things that Azure can charge you for.
We have probably more complex pricing than what Tier seems to handle, but, it's only a handful of tables and not a significant amount of code to handle it all. I didn't think this was a terribly hard problem and a custom solution seems better for tailoring the system to your particular needs?
Concerned about the number of lightweight marketing blog posts making it to the front page of HN. It’s like it’s part of the “marketing to devs” playbook at this point.
If pricing your product is so complicated that you need an entire separate product to manage it, you are probably indulging some MBAs in their own make-work projects too much. Non-transparent pricing is a huge red flag to potential customers.
Is it just me or did the article just suddenly end after saying what amounted to "you need a separate pricing engine" and "we at tier learned this the hard way"?