That's a fair question!
To be honest, it was a no brainer choice for us since we were 2 engineers at the beginning with 10y exp on Ruby, we wanted to be focused on our product and not on the tech we could use.
Ruby ecosystem is still a very good choice imo, as Python or NodeJS or any other language could also be!
I have the strong opinion that regardless the language you use, you will always face the same problems, so go with what you're familiar with and let's focus on what you want to do. I can swear that we had some headaches about our core billings features, if we had a tech we did not master, we may have lose all our hairs!
The only downside I can see is recruitment, it can be harder to find experienced ruby developers, but well, if it's the only one we have, I'm pretty happy with it!
Hey @haolez, yes the main repo contains all the docker configurations and 2 subsmodules, so you just have to clone this one and have Lago up in 2 minutes if you want to try it out!
Our api uses Ruby On Rails and our front end is build with React!
The pain in there is that every time you want to have a PDF generation system, you have to do the same stuff, it's not "complex" at all, but it definitely takes time, whatever the technology you use. On my experience, having ten thousand PDF generating at the same time was a very high load for our infrastructure and the cost was enormous, that is one of the main thing I'll focus on today : the scalability of it. It also depending on the way you create your template, hard coded with pixels or HTML!
I totally agree with you, I had to work on the Qonto's billing system (that Raffi is talking in the blog post) and it wasn't fun to maintain. I remember the pain it was to change anything without breaking the whole system, not because the system was bad, but because it's complex and when you build it in-house, you will certainly take some shortcuts that makes it not so flexible!