Top of Hacker News with Anh-Tho from Lago
Anh-Tho Chuong's co-founder posted his first-ever Hacker News submission — a rant titled "Billing Systems Are Still A Nightmare For Engineers" — then went for a beer, assuming it would sink. It hit number one for 48 hours. Lago pivoted around that unsolved pain point eight months before this conversation.
Anh-Tho Chuong is the co-founder and CEO of Lago, an open-source metering and usage-based billing platform, built by a team of early employees from the fintech unicorn Qonto.
We get into the three things that convinced the team billing, not their original no-code ETL idea, was the real business, why open source was the only credible way to solve a problem every engineering team quietly hates, and the actual hit rate behind their content strategy — 60-plus posts, five that really landed.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Lago, and how did the team end up building it?
We're a team of early employees from Qonto, a fintech unicorn valued around $5 billion — I was the first employee and VP of Growth there, owning revenue. Most of the Lago team are also early Qonto employees. We started in summer 2021 wanting to build something zero-to-one together, in areas we all liked: B2B SaaS, fintech, data. We applied to Y Combinator without even having a product yet, got in, and built a no-code ETL tool. We shipped during YC and started monetizing, but learned three things that changed our direction entirely.
What were those three lessons that led you away from the original no-code ETL idea?
First, it wasn't going to be a big market — our no-code wedge was aimed at marketers, but as a company grows, it's really only the data or engineering team that reliably handles data transformation, so the no-code angle stopped being a real wedge. Second, we realized we were just synchronizing data from point A to point B, not producing any new, important data that didn't already exist somewhere else — to build something massive, we felt you needed to actually produce data that other systems want to connect to and depend on, becoming the genuine source of truth rather than just a pipe. Third, while monetizing our own product with hybrid subscription-plus-usage pricing, I personally struggled badly trying to build that in Stripe Billing — and our own engineers, who had built Qonto's homegrown billing system from day one all the way to Series D, told me Stripe Billing couldn't handle it either.
Why does billing seem to be a problem so many companies end up solving themselves rather than buying a solution for?
We kept asking ourselves that at Qonto too — no engineer likes writing this code, and it's genuinely hard to hire and retain engineers with real billing experience. Our conclusion was that billing is deeply specific to each company, so you either build it yourself, like we did, or keep things manual and try to control costs, sometimes by outsourcing the manual work somewhere cheaper. Being immersed in the data and open-source world through YC, we slowly built real conviction that open source, not another closed-source SaaS, was actually the way to solve this — the fact that companies keep rebuilding the same painful billing systems over and over shows the existing options clearly weren't working.
Why specifically does open source solve billing better than a closed-source product could?
Three things. First, it builds trust with engineers much faster — the alternative is building in a cave for three years before shipping something 'complete,' which felt far too risky, so we opened the GitHub repo as soon as we had anything to show, about two months after starting, in June of last year. When people can look directly at your code, criticize it, and scrutinize it, trust builds much faster than it would behind a closed product. Second, extensibility — a lot of billing needs, like proration, multiple time zones, coupons, and credit notes, are common across almost every company, so we built Lago as a set of primitives engineers can build directly on top of, and because it's open source, they can see exactly how those primitives work under the hood rather than treating them as a black box. Third, scalability and control — we offer both a cloud version and a fully on-prem version, so companies that want complete control over their own infrastructure can run it exactly as they want.
Do you know why your Hacker News launch specifically did so well?
Honestly, I don't fully know — it's much easier to analyze why something fails than why it succeeds. One fun fact: back around March or April, before we had full conviction we were pivoting into billing, my co-founder wrote an article titled 'Billing Systems Are Still A Nightmare For Engineers,' listing seven or eight pain points. It was his first-ever Hacker News post — he barely knew what Hacker News even was — and he posted it and went to get a beer, assuming it would get one point and disappear. It hit number one and stayed there for 48 hours, with 300-400 comments. The response was so strong it told us this was a genuinely unsolved problem worth investigating properly, and that early post is probably what first put Lago on people's radar, especially since we kept the same company name through the pivot.
What's your actual hit rate been on content since then?
We've written more than 60 posts, and maybe four or five have really done well. After that first viral post there was a real valley — we kept writing, nothing landed for a while, and we wondered if we'd just gotten lucky once. But once we had a handful of genuinely successful posts under our belt, we realized you just need a routine and to keep pushing — if roughly five out of sixty posts land really well, that might just be the expected ratio, not a sign that any individual failure means something's wrong. That reframing made it much easier to stay calm when a post didn't land, even though it still stings a bit every time.
What actually makes a post land, versus one that doesn't?
Self-promotion doesn't work, especially on Hacker News — that community is sharp and genuinely allergic to it, and posts that lean into it get flagged fast. What works is that everyone already knows billing is painful, but there's a real gap in content that explains why, in real depth, or walks through the actual concepts. Our angle became writing about specific billing problems and how we solved them, spending real time explaining exactly why something is hard, with genuine detail. That gap — deep, honest explanation of a real problem, rather than promotion — is where our most successful posts have consistently come from, and I think that's broadly true well beyond billing specifically.
A lot of your competition is really 'people building it themselves.' How have you approached that?
Since we were the exact persona who'd built a billing system ourselves, when we opened the repo we got real demand from later-stage companies — Series C, Series D — who'd already built their own and were hitting real pain points, even before we had a full feature set. That confirmed our hypothesis directly: these companies weren't going to switch to another closed-source SaaS, and they were fed up building and maintaining it themselves without wanting to hire more engineers just for billing. A strong early signal was a European company called Lydia, with 5 million users, who found us about two months after we opened the repo, inspected the code themselves, and started submitting pull requests before choosing to actually adopt Lago.
How does someone go from using the open-source project to becoming a paying customer?
We opened the repo eight months ago and started testing monetization about three months ago, and we already have paying users in production. Some people sign up purely to self-host and use the free version, which we're genuinely happy about. What we sell are premium plans — premium features, premium support, and hosting, or premium features and support without hosting if they'd rather run it themselves on-prem. Right now it's entirely inbound — people reach out on Slack or Twitter, we have a conversation, and we try to help regardless of whether they're on the free tier. Sometimes people move from free to paying quite organically over time.
Does billing's nature as an existing, well-understood need make that motion more organic than for other dev tools?
I think so — we're not creating a new use case or trying to convince anyone billing needs to be solved; it's an existing, obvious need, and companies are already used to paying to solve it. That's different from a lot of other dev tools that have to first convince someone a problem is even worth solving before getting to whether they should pay for a specific solution.
A lot of billing tools take a cut of revenue. Why did you decide against that model?
When we were evaluating billing solutions ourselves, we hated that model. It makes sense for payments, where processing money genuinely carries more risk as volume grows, but billing is fundamentally a data and software problem, not a payments problem — so a revenue cut doesn't map to any real cost we're incurring. One of our most successful posts was actually about Stripe having 21 different products — a lot of founders don't realize that if you use Stripe to get paid, you're probably using three or four of them (Stripe Billing, Payments, Invoicing, Data), each with its own pricing, and those revenue cuts stack up in ways people don't fully track. There's also real lock-in — using Stripe Billing effectively locks you into Stripe Payments as your processor, so if you expand into a market where a different processor, like Razorpay in India, is genuinely stronger, you can't easily use it. That's exactly the kind of lock-in we resented and are deliberately avoiding with Lago — open source, but also philosophically open to whatever tools make up the rest of a company's revenue stack.
You also do angel investing. What's a lesson from that world that's shaped how you think about building Lago?
Some founders have every star align from day one and get explosive growth almost immediately — that happens, and it usually reflects real talent and hard work, but also being in the right place at the right moment. But if you're not in that tiny fraction of outcomes, that doesn't mean you won't succeed. My first angel investment was Hugging Face, back when it was a B2C app nobody understood, years before their pivot to B2B — a tiny five-person team that, at the time, almost nobody outside the company really got. Watching how enormous they've become since, after years where very few people understood what they were doing, has been genuinely inspiring, and it's shaped how I think about our own launches. Even a genuinely successful launch can be followed by something that doesn't land the same way, and that's just part of the journey.
Does that perspective help with the emotional side of a launch not landing?
It still hurts, honestly — everyone feels like a failure in that moment, even repeat entrepreneurs launching something that people don't instantly want or understand. But seeing other people in the exact same situation bounce back afterward has genuinely motivated me to keep pushing. That's one of the biggest things I've taken from pivoting and searching for product-market fit.
What's the one takeaway you'd leave a founder with, based on everything you've learned about content?
Set the right expectations for content success — we posted more than 60 times and maybe five really landed, and having that ratio in mind up front makes it much easier to keep going without getting discouraged, rather than assuming every single post should work. The second thing: early on we were genuinely bad at distributing content well, on the right channels at the right time, and we've had to actively iterate on that. A lot of people put real effort into content and then don't think enough about distribution, or give up too early on something that took real work to produce.