Why doesn't Stripe use Stripe Billing?
getlago.com
getlago.com
At the time, we got lots of feedback from the folks who had built that system. Our goal was to build a flexible billing system for all kinds of companies at different sizes, but we were definitely focused on smaller (doing maybe $100k–$10M of ARR) SaaS companies to start. We've come a long way since then and now power billing for a number of large/public companies. Atlassian, Figma, Notion and Slack are either using or migrating onto Stripe Billing today.
Stripe Billing is a powerful tool with a role to play in any company's revenue management system, including Stripe's. Newer Stripe products (such as Atlas) do build on top of Stripe Billing but we haven't gotten around to migrating our existing stack. That said, I do have a personal goal of taking on more internal billing responsibilities over time (e.g. I think we could easily use Stripe Invoices internally today, and it's mostly opportunity cost keeping us from actually doing so).
I do want to say that the specific use case covered in the post is something we have thought about a lot. I think about it as a pipeline with stages for collecting high volumes of usage events, aggregating them, mapping them to rate cards based on usage, and then producing recurring bills, collecting payment, dunning, etc... The post claims we don’t do a good job on the first two stages (collecting usage events and aggregating them) is perhaps missing that the style of percentage-based fees is a one-line addition to a Connect integration as my colleague edwinwee mentioned below. It is also possible to have a scalable usage event collection/aggregation pipeline integrated with Stripe Billing. You can read this AWS blog post https://aws.amazon.com/blogs/apn/building-a-third-party-saas... for information about how to build such a system according to our best practices.
While I’m here, I’m always eager to hear feedback on Stripe Billing from folks who are using it. My email is ark@stripe.com.
We've made several internal and a few external changes over the years to help our users with these kinds of issues and in my estimation we've been getting closer to making the commitment, but as of right now we haven't done a stop-the-world effort to change systems internally.
Is Lago barking up the wrong tree? Or is there really an untapped opportunity here?
The other reason is that Stripe Billing is stupidly good. So good in fact, that they could raise they rates from 0.5% to 1-1.5% and most people would pay up since migration would cause downtime and man-hours. I use Stripe Billing now, but could integrate with Lago once and easily switch between payment processors.
Billing is still a huge nightmare for engineers, this is what we're going after -> https://news.ycombinator.com/item?id=31424450
We've built and scaled it internally in a 5x Fintech Unicorn before joining YC, we would have loved to use an off the shelf solution, but none of them were a fit.
We do not bark up the wrong tree, but try to give our point of view about the perfect billing system
FWIW, we're happy Stripe customers, but also candidly do much of our billing outside of of them. Some of the examples GP cited are in a similar boat. Which is all to say that Stripe solves a lot of headaches, but it hasn't solved all of them. I'm sure investors in Stripe see that as a positive opportunity.
Microsoft's annual revenue is almost US$200 billion. Even if the migration would "cost them millions", they can easily afford it, it would not make any material difference to their ultimate financial position. And, it would actually be justifiable as an investment in their own ERP suite – "eating their own dogfood" would send a signal to their customers about their commitment to those products, and would also help improve those products over time (by exposing them to the distinctive needs of a Microsoft-scale enterprise). As far as time goes, they could always do it gradually (maybe they already are), and even if it takes several years, before we know it those years will be behind us.
Of course, Oracle has so many different software offerings (duplication due to acquisitions, and lots of industry-specific offerings), it couldn't possibly use them all internally. But at least its sales reps could say, that if they weren't using the specific product they were selling, they'd be (for non-industry specific functions) using an equivalent product in Oracle's portfolio.
Amazon themselves say it is true: https://aws.amazon.com/blogs/aws/migration-complete-amazons-...
Although note this small print:
> Amazon’s Consumer business just turned off its final Oracle database (some third-party applications are tightly bound to Oracle and were not migrated).
No idea what those “third-party applications” are and how significant they are - they could be insignificant fringes or extremely core business systems (such as payroll or general ledger)
Probably they've migrated off now, but IIRC they've used PeopleSoft, because of course it is.
So, Microsoft's own Dynamics offers no greater value than their competitor SAP, even within ... Microsoft.
[0] Recent example - https://www.oracle.com/cloud/oracle-at-oracle/ - although they were saying similar things 15 years ago, albeit minus the cloud part
The departments are also not the same, the developers might be happy to have a customer like Microsoft but the hundreds of people using something else today really don't gain anything. They would have to retrain and take on a huge migration. And for a system that has grown for such a long time you can be sure that there are a lot of undocumented edge cases for weird business needs.
Smaller companies have burned millions trying to move off SAP. And there is nothing Microsoft can do or learn to make the migration to their product easier because it's all business problems, not so much technology. Their potential future customers aren't billion dollar companies which are on SAP today.
An example is 3D printers. Prusa makes fantastic 3D printers, and about half of the structural parts for their printers are printed on their own printers. So they have 600 of their own 3D printers printing 24/7 printing their own parts. That means they are forced to address long-term durability and reliability issues even just to ship their own product.
Because it absolutely is true that at that scale, you're usually better off just injection molding the parts, but they'd lose the high-quality signaling that yeah, their 3D printers are good enough for the company to rely on them to print their product. They also lose out on insight to things they could do to improve their own product from a usability standpoint.
Are there any plans for first-class contract term support coming?
https://stripe.com/docs/billing/subscriptions/subscription-s...
If you rent a home, you pay monthly despite the contact lasting a year or longer. If are employed you probably get paid monthly, even with a fixed contract duration of 6 months or a year.
Auto-renewing yearly contracts, on the other hand, are definitely a dark pattern. Luckily many places are outlawing it, so as an alternative a 12-month contract will often automatically convert to a monthly one at the end.
Stripe Billing helpfully allows you to set the original subscription start date to a past date, but only at subscription creation time. If we could modify the subscription start date, then Stripe could be authoritative for when 100% of our subscriptions actually started.
I've had customers complain to my face that we tailor the products to our needs, and are surprised (and sometimes vocally disbelieve) that we don't use it, ourselves.
In certain industries, dogfooding is considered bad, and sometimes illegal.
Isn't that the worry? Say a bug in your timekeeping software underreported hours worked and that lead to workers not being paid their agreed upon rate. When it goes to court you now have to prove that you didn't maliciously introduce the bug to save on employment costs, whereas if it is a third-party providing the software it's their problem. "Conflict of interest" is ultimately just another way to say "I don't want to assume the liability when things go sour". Nobody cares about conflict of interest when things go right.
Again, "conflict of interest" is what people often say when they don't know if it will affect them, but don't want to take the risk. "Regulation requires it", as illustrated in the first comment, is what people say when caselaw actually demonstrates that they would be liable.
The fun thing about language is that it is fluid and can take many forms.
No, it's not.
It's "malice is not a reasonable explanation for things going wrong". It only changes liability when it follows malice, what is much rarer than you seem to think.
It is also a way to assure people that you won't do something bad.
It cannot possibly be the case that Microsoft runs on Open Office and MacBooks.
They only started eating their own dog food when people started making fun of them in public.
They use Zoom & Slack internally, not their own video and chat offerings.
Dogfooding is a good thing.
You’d be surprised how few companies actually do it (which is terribly shocking).
I can tell you that devs that use their own product deliver better quality.
Perhaps you also need to use the product that your competitors use to understand what you need to beat.
EDIT: I see above that others have claimed the opposite, but my experience has been different. I simply cannot take a call from a cafe in Zoom without complaints, but Meets is regularly tolerable, according to those I meet with.
That gets repeated a lot but I have observed the opposite when you have a diversified company dogfooding an internal product that isn't strategic in their portfolio, or is targeted at a market segment that the company doesn't belong to. I have seen companies hamstring themselves by using a product that isn't the best offering for them or a poor technical fit, only because it is their own offering. Also, in the worst case, companies become develop tunnel vision in the market, because they don't regularly use the competition.
If you have a large, international software company targeting small to medium business customers in the US, dogfooding would be counterproductive. It would probably harm their strategic customer base by overcomplicating their product with features they don't need at the same time it slows the parent company down by using a product that's poor fit.
Not a company, but OpenBSD dogfoods exclusively. And they do deliver a good product.
The idea behind dogfooding is that you get more/better feedback and more internal pressure to fix problems.
But the product team should already be getting feedback from a diverse set of customers. And if they're not, that's what needs to be fixed.
Dogfooding can also result in overprioritizing only your own company's product needs, and at worst the ultra specific issues that one particularly vocal VP is having, to the detriment of the overall customer base. (I've seen it happen way too many times.)
Companies should use the best tools for the job, not necessarily the ones they make themselves. If those are the same, then great. If not, then also great.
It might be a goal to move everything internal (I believe Google is now using Google Apps internally, but they didn't for awhile, even after other businesses were).
For example, Stripe is a _very_ large company but their product is geared mostly towards small and medium size businesses.
It's very possible that in the process of making Stripe Billing work for Stripe, they'd make it work less well for their actual customers.
It's the same reason why Intuit probably doesn't use QuickBooks to do their accounting.
When dogfooding, you have to be very careful that you don't end up in a bubble and only see your own needs as the priority.
There's a propensity for developers to start using their own products then changing it to suit themselves thinking that the regular users use the same product the same way. You end up with this mismatch of expectations and it can even get so bad that the developers don't believe the users who tell them that things need to change.
In the version without "ing", that's 5 versus 2 syllables.
However, I find it can get tiresome / has potential compilations.
Customer's can be terrible with incomplete, bad idea, and nonsensical requests. But sometimes internally you get the worst "Someone spilled some words into email that don't sense / no you don't actually want that / bro this is accounting software not Photoshop." situations that folks who are more familiar with the origination might make, but customer's might not make.
It takes an extra level of internal discipline to deal with dogfooding side effects at times IMO. Still, a good idea none the less.
+ you get to keep up with their advances so you’re not relying on your customers telling you about your competition
+ in the case of chat apps, if your infrastructure goes down you can still work as a team to coordinate the remediation
I've actually had an instance or two over my four years there where I discovered a bug in our PROD/App Store version myself; simply from using the software enough.
It's really unfortunate that this isn't the case for a lot of dev shops. Dogfooding is incredibly important to QA.
Second, this article seems to miss the point of Stripe. It seems to want to build a platform, which is what Stripe Connect is designed for.
For example, charging a percentage fee is just one line (https://stripe.com/docs/api/application_fees):
` $application_fee_percent = 5`
Slack, Atlassian, and Notion have all built their B2B billing on top of Stripe. But we don't target just B2B or B2C ecommerce in case a business has multiple revenue streams (which many businesses are increasingly adding). In fact, we designed Billing so it can flex across any business model—per-seat, usage-based, tiered, or even graduated.
This is the point of Stripe. A single stack that flexes with your business as it grows and pricing that's public.
This is confusing because you’re implying that Stripe Billing is used internally but another employee clarifies and says it’s not, it’s simply another billing service was created that predates Stripe Billing.
It used to be that Stripe could be relied on not to do this sort of corporate doubletalk. The OP asked a direct question and you've given a misleading PR answer.
I'm sure you're a nice person just trying to do your job, but your inevitable PR posts to HN, within minutes of anything Stripe-related coming up, are hurting your cause. The Stripe of the past would never have spewed propaganda like "This is the point of Stripe. A single stack that flexes with your business as it grows and pricing that's public" into HN threads. It's embarrassing, and what it's telling us is that culturally you've lost your way.
Maybe that's inevitable on your way to world domination, but if you guys can no longer communicate honestly or treat readers as intelligent, you'd be better off not posting here. I like Stripe, by the way. I know this is harsh but I would like it to be helpful.
It's of course your choice, jfyi
In contrast, reconciling pretty much every other payment processor is relatively straightforward.
Somewhere along the way Stripe went from being developer friendly to becoming more convoluted than Java.
The core of stripe is great, we’re fans. But as you add any complexity you end up with a mess of various internal account balances to maintain. It forces you into gross things like bin packing refunds, complex internal transfer fail handling. Toss in the inconsistent handling across connect and man, you’d be better off just going back to basic charges and ignoring all the value adds.
In Xero you've got something called a "Xero Network ID", which is an ID that you can give to other Xero users and they can link it to your contact record on their account, which means that invoices they raise are automatically posted in your Xero account without you having to lift a finger.
Now, you would have thought that Xero would do the same for their subscription invoices (i.e. automatically post them to your Xero account).
But no.....
Instead they send you one by email which you then have to post manually onto your Xero account. And they do that every ... single ... month.
If you ask them "why ?", you get an arrogant reply that along the lines of "we're too big to use Xero, so go away you silly little person".
But that doesn't answer the question. Xero is their dogfood. So even if they use Sage or whatever internally, surely it is not that difficult for them to build an integration so they can post their damn invoices to the customer's accounts.
Rant over. ;-)
It's nearly impossible to just log in and reconcile all your accounts because you are always fighting with unconnected bank feeds. This degrades the core value prop of making it easy to stay atop of bookkeeping—now I always have some form of "accounting debt" these days.
I got so frustrated that I am in the process of migrating my personal account to Tiller + Google Sheets, and I'm still looking for a solution for our small business account.
I agree about the billing issues; I waste time figuring out where the invoices live in the product and manually posting them. Otherwise, the product would be fine if outdated, if it wasn't for the unreliability of Yodlee.
For a long time I resisted moving to Xero.
Unfortunately my hand was forced because my existing solution (MYOB which was then bought by Mamut) stopped being Apple compatible through their own lazyness (they refused to update the software for 64-bit compatability).
Apple had pre-announced the post-Catalina 64-bit requirement years in advance. Every other developer out there had made the change. But Mamut/MYOB ... nope, they sent out a long email one day basically making that absolutely clear they were not moving from 32-bit.
Their answer was to offer a "cloud" version. I say "cloud" because what they offered was a remote desktop connection to a Mac running an old version of software on their side.
So hence I was forced over to Xero. My accountant was pressuring me too, but Mamut/MYOB killing off their own product was the straw that broke the camels back.
(I believe they may have finally relented and brought out a 64-bit version subsequently, but by that time it was too late, I'd moved already. And I had lost trust in their software support abilities anyway by then).
At least they aren't hiding that anymore.
Basically, with fairly modest investment, the Indian government put together a system to allow instant transactions between bank accounts. There are no transaction fees.
We have so many companies (sometimes the same company with multiple faces - Paypal/Venmo, Stripe, Clover, Square, all of whom want a cut of transactions for the incredible service of making a number go up in one place and down in another place. Instead of fixing bank-to-bank transfers, we're stuck with ACH, which for some godforsaken reason takes days to clear.
There's no technical reason why the US can't have a system like UPI. There's no reason why we MUST allow rent-seeking payment processors to take a cut when someone in Mumbai can make a peer or merchant transfer for free in seconds.
UPI: https://en.wikipedia.org/wiki/Unified_Payments_Interface
Edit: FedNow, May 2023, pricing not yet released. It is for business and consumers
You're right there is no technical reason, but there is a very strong political reason.
They way things are now, people in the US have to pay for a lot of things that people don't pay for in other countries. Bank Transfers is just one example. Health Insurance (and care) is another. Higher education. Filing taxes. This list is endless.
Making people pay for this stuff is extremely good for the economy, and probably a big part of the reason the USA has the highest GDP.
It also makes many, many hundreds of billions of dollars for those entrenched in those industries, who will spend tens upon tens of billions of dollars lobbying to make sure it never changes.
Many nations didn't have such systems in place, so they were prime to have their own technology be brought forward. That's why WePay was able to spread in China.
The other huge factor here is that forcing things on companies in the US is extremely difficult. Our constitution and laws make it a lot more difficult for the government to force certain behavior on private businesses. Along with the cultural idea of free enterprise, people don't like the government making decisions for them on how a business should be run.
In India, the Bank of India and the government was able to force UPI down everyone's throat, and companies have no choice on the matter.
If I sell a cash register app to indie businesses who sell trinkets at the art fair, that doesn't mean my solution meets my own needs for billing my millions of those business customers.
While from the buyer's perspective, "single negotiated cost with overages" may appear simple - it's a single bill after all - on the accounting side for the company selling the product, I'd expect it's much more complicated; with potentially different tax rates for different products and complexity around producing an auditor-defensible determination for "cost of goods sold" and "marketing expense."
So for at least some of these requests, I see Stripe's posture here as helpful - it's not "requesting a dollar figure", it's "creating a detailed enough accounting trail behind that bill to operate your business." Looking across the breadth of Stripe's products, I'd give them the benefit of the doubt here.
https://www.investopedia.com/terms/m/merchant-discount-rate....
For me the navigation bar doesn’t collapse and covers the whole screen.
"We were told recently: “We love your ‘Stripe hate’ content”. While it was intended as a compliment, ‘Stripe hate’ has never been our intention.
We partner with Stripe Payments and love their products. Our own product is an alternative to Stripe Billing (and Chargebee, Recurly, etc.) but with a deep focus on B2B and product-led companies. We actually have common investors on our cap table (e.g. Y Combinator and others)."
Spreedly used to be this, but they went enterprise-only, raised prices 30x, and become so customer-hostile that I recommend avoiding them now.
I'd never heard of Lago before but I think I'll give it a try.
Why would you assume I haven't evaluated Stripe's offering on a post that is specifically about the shortcomings of Stripe's offering.
Passing from the general physicist's uncertainty principle to a more restricted but still physically meaningful case, the Fourier-transform version of the uncertainty principle (requires no physics to derive and) states that the narrower and less smooth a spatial representation of something is, the wider and slower-decaying its frequency representation becomes. (Sharp and abrupt sounds have wide spectra, which is why they get mangled into the strange but recognizable bubbling in low-bitrate MP3s. The two-dimensional case of the same phenomenon is well demonstrated by the JPEG "ringing" around sharp edges, with the caveat that JPEG transforms every 16x16 block of pixels independently.) Physics comes in here only when you say that position and momentum (amplitude) distributions are Fourier transforms of each other.
If a single sample or the average value is all you get, then yes, the width of the peak becomes the uncertainty of your measurement. If you can get many samples, though, then you absolutely can trace the shape of that peak. It's just that the instruments used at the dawn of quantum mechanics were not built that way.
(What "particle-wave dualism" means, I think nobody really understands except maybe Bohr scholars; "dualism" was his personal German-philosophy-style all-encompassing idea that he was smitten with before he even started thinking about QM. It's a wave, period, it's just that high-frequency waves can look like particle propagation if you squint, as seen in optics and acoustics.)
Based on the normal definitions of particle and wave, and based on things like the double-slit experiment, I think we'd have to conclude the behavior is closer to "neither" than to "wave".
If you define "wave" based on quantum behavior, then you're really just begging the question of what to call it.