Billing Engines Don't Solve Pricing Problems | Hacker News Reader

Billing Engines Don't Solve Pricing Problems

tier.run

146 pointsjmacd59 comments

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.

Agreed on not becoming too dependent on Stripe. Billing (or in this case, pricing) is the last thing you want under another entity's control.

There is surprisingly little in the OSS space around this, but I can recommend KillBill (no affiliation). Although it is one component that does combine billing and pricing model, they are separate abstractions within KillBill, that provide the exact benefits the article describes (the ability to quickly iterate on pricing model). Stripe and co. are relegated to simply processing payments when they are due, which avoids the lockin of their value-add services. I'd love to see more in this space but honestly KillBill is the most rounded that I've found.

Another one I've seen around before is Hyperswitch

https://hyperswitch.io/

I haven't used any of these tools, but I'm starting to explore them. The other one I found was https://github.com/getlago/lago

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".

This is a naive view but I'll let someone else elaborate

The difficulty of pricing lies on actually pricing things, there is no missing technical brick, but missing knowledge.

I think recognizing it's a different problem than billing and have it as a different entity is important. And of course that knowledge needs to be materialized into a technical block.

Now, I'm totally with you that calling that an "engine" is misleading for 99.9% of businesses. In most cases that's a configuration file, or a business class if they're dealing with more user behavior check, calculations or conversions.

Yes definitely. The domain of "Pricing" things is a giant industry; i.e., the accounting and finance industry.

Did you previously get a new-customer discount on a previous order? What promotions are in effect? Are you eligible for that promotion based on your location or customer type? Are there bundle discounts that can apply? If you build an order, can we recommend eligible offers based on what is in the order already?

That'll be a fun config file.

I am sure this doesn’t solve this though. It’s hard question to answer on individual basis, require some complex logic, and for sure some coding. You won’t be able to solve this with a “Pricing Stack”.

Unfortunately, pricing is unsexy, complex, full unknowns, no easily testable, and odd.

That's precisely what this type of tool targets fixing.

There are definitely easier and harder ways to handle pricing, but especially when you have higher touch sales “just use Stripe” stops working in a lot of cases.

Ultimately bespoke sales deals show up, and you need to be diligent in your tooling and pricing design to make it work well (especially if you have any form of metering or dynamic pricing you want to take effect “immediately”)

It’s easy to have the handful of price points and fixed billing. But there’s a lot of ways for things to get more complicated.

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:

> 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.

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.

I'm currently living through this fundamental oversight : )

well that's not pricing engine job

Tier seems to be solving a real problem that every company beyond MVP stage will face.

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.

PriceOps? Really?

The idea that pricing and billing are separate concerns seems entirely obvious to me.

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.

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?

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).

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.

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.

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.

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.

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.

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 too much success, since I'd like to have some customers too.

I've got agree with your comment about the business stakeholders. The uncertainties around pricing and (at the moment) the even trickier problem of price increases can lead to inaction.

100%. The main reason we created https://priceops.org is that there's a real mind-shift that has to happen for someone to realize that there's even a "there" there. Most people who've been through it understand all too well, but even there, it's tempting to think "Oh, if only we'd just committed ignorantly to a better pricing model..." not realizing that you'll always get it wrong and the context will always be changing, so it's critical to have an implementation that can respond to new information.

> 5. Pray that no one ever has to touch it again. (Or failing that, hope you've got a new job somewhere else before that happens.)

So many otherwise smart people make this foolish bet. It is an exceptionally long shot.

> Of course I don't wish them too much success, since I'd like to have some customers too.

Feeling is mutual, I'm sure <3 I think it's potentially a very big space with a lot of work to be done, so there's room for plenty of players in it.

https://priceops.org/ looks a lot like https://12factor.net/ I guess on purpose and by culture.

The problem most teams have with pricing is they think it’s a sales problem.

It’s not.

It’s a cross-functional problem that mostly has to do with product (how it’s bundled, which features are on which tiers, and how customers move between tiers) and customer segmentation (how different customers value the features).

Linking to your service https://www.heystage.com/ for reference.

Oh neat, I'm coincidentally trying to setup tier rn.

Bit stuck in progress following Vercel template here https://vercel.com/templates/next.js/tier

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.

Would love to help. Let me know whats blocking you with the template? Also you can join our community at https://tier.run/slack

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?

This is known as “rating” in traditional billing systems like the ones telcos use.

Why do you put Lago and Stripe together there when we know Lago is closer to your product than Stripe?

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.

Devs tend to know less about marketing than might be optimal for them. And the startup / side project crowd certainly needs some marketing knowledge.

No wonder sometimes such posts get upvoted as useful or even insightful.

fwiw this post was written entirely by Isaac. It's not ghost written or edited for marketing purposes. The title might be a bit catchy/glib.

there's way more shameless titles that make it on HN. i dont see a problem with this one at all - clear thesis statement, invitation to read more.

> written entierly by Isaac

I see what you did there ;)

Is it really “lightweight”? Have you ever run a business and been responsible for pricing strategy? I have, and I thought the post made a good point—if pricing is tightly coupled to billing implementation, it discourages experimentation since pricing changes are technically non-trivial.

If you don’t relate to that, maybe the post just isn’t for you? HN is a forum for engineers and entrepreneurs—it’s run by a startup accelerator, after all. Not everything on it has to be purely technical.

None of that changes the fact that this is marketing for their product. Many similar posts have made the front page of HN recently and it’s getting a bit formulaic. It’s great that you like some of them, but are you ok with HN just being a bunch of covert marketing copy?

I don't see the issue here. They're solving a real problem for developers with their open-source solution and telling people about it.

Most content is marketing in some form. Would you complain about a developer who blogs about open source so they can get consulting projects or a job? If the content is good and I can learn something useful from it, it seems like a win-win.

Social media users who have impracticably many dead authors’ books to read and choose not to are always going to complain about the impacts of cultural materialism, one comment at a time.

My main gripe with this article, is it mentions that their product was born as a result of a "painful expensive experience" of not creating a "Pricing Engine", but they don't at all elaborate on what that experience was.

I want to know what problems that they built this to solve specifically, so that I can foresee future problems that I may run into. But they don't elaborate at all, and instead just mention that their product solves those unmentioned problems.

That’s fair. Having dealt with this myself, I’m very familiar with the pain involved, as I’d imagine most developers/entrepreneurs who have had to implement billing and then iterate on pricing are. It gets messy really fast.

Perhaps they’re more targeting people like me who have experienced this issue and don’t really need it explained, but I agree going into more detail on the specific challenges is probably a good idea to appeal to a wider audience.

If you find bad posts you can flag them or write the mods to convince them to fix it. Posting meta about them mostly makes it worse.

I noticed that that guy who posted his "I asked HN founder X and here is their top 10 responses" blog got flagged. I think that is a bridge to far in building a self brand with content marketing.

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.

The problem is not so much complicated pricing as grandfathering existing customers every time pricing changes (generally considered a best practice to avoid pissing off your customers). Then you end up with lots of gnarly conditional logic around anything that touches billing because you have to support a bunch of different pricing/billing versions, different upgrade/downgrade paths, etc. It gets even worse if your pricing model changes, like you go from tiers to per seat or usage-based.

You could just never change your pricing, but you’ll almost certainly be leaving significant money on the table as you’re highly unlikely to get it right on the first try. It could even kill your business, since the right product with the wrong pricing can be as much of a non-starter as the wrong product. Iterating on price can be as important as iterating on the product.

I've worked on pricing. There's a lot of complexity, even with a fairly simple product. Our product was a monthly subscription with 4 different tiers. Complications included:

  - Annual plans that include a discount vs paying month to month.
  - Introductory pricing (and how long that lasts)
  - Promo codes
  - Dealing with multiple currencies
  - Pricing on iOS, where you have to pick on of their "pricing tiers"

Hmm, I don’t know, what about products that have very thin margins? I suppose you would like to mirror the market price of that product as closely as possible, and that seems like it’s better to automate it.

That definitely is top of mind for any startups heavly relying on OpenAI or other hosted LLMs.

We don't advocate complex pricing models. KISS is often the best approach, although some complexity does have its place.

The real complexity comes from when you need to make changes to your pricing and have to manage grandparenting, upsells, etc.

Another vector of complexity comes from the need to make different pricing and packaging offers for different markets, geographies, etc.

You can have a very simple pricing model, but that doesn't mean that there isn't complexity that emerges pretty quickly.

A previous job was working at a supermarket's online store. Supermarket's have all sorts of weird specials eg "4 pies for $5" or "a pie and a coke for $3".

We were running into problems when we had large test baskets ( $500 always, $200 sometimes ) that there would be so many combinations of specials that calculating the best way to apply them was causing CPU load and timeouts.

Fix was somebody sat down, remembered their CS classes and applied a more scalable algorithm. Problem fixed.

A pricing SASS company without a pricing page? Umm?

Guess they need a pricing engine.

"Don't worry about pricing ever again, we'll take our money without you ever knowing ;)"

/s in case it isn't obvious

It says the Pricing Page feature is coming soon :-D

We've been primarily OSS, so free.

We do have Tier Cloud with customers actively using it, but it has been invite only so far. It's a fair point though and I think we can put pricing up now in advance of making it publicly available.

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"?

Reply on news.ycombinator.com