3 ms·

I totally agree that this is a huge issue. Especially if you don't do much coding) These vendors are probably solving the problem of letting you automate your

I totally agree that this is a huge issue. Especially if you don't do much coding) These vendors are probably solving the problem of letting you automate your billing and invoicing process without developing your own system. As you said earlier, there's already a lot of Ask HN about this. So a solution does exist. I take your point that on the other hand it may require a lot of input on my part into an already existing program. For example, if you were going from project to project as a developer - you would probably be doing your own system. And if as a project manager - you would look for an existing solution on the market, hoping to reduce development costs))

PaulHoule 4y ago
Organizations and individuals tend to oscillate. Often they do a "build" project that goes badly, resolve they are going to "buy", then "buy" goes badly and they are going to decide to "build" next time. It would be a mistake to assume that either "build" or "buy" is automatically superior in any given situation. What I will say is that the vendor has a team of flying monkeys that will spread FUD about "build" and the other vendors because that is the marketing message that moves the needle. How good the product is really depends on the mental model it is based on. If the mental model is right it will be excellent but if it is wrong you are in for a world of pain.
- Rafsark 4y ago
  Hi there, I'm Raffi, one of the co-founders of Lago (Billing API). I think this dilemma is amplified with specific topics like authentication, permissions or billing. Even if you come with a home-made solution that took you a month to build, it's a month that you've not dedicated building your own product. The second reason is because they require a lot of maintenance. Building a first version is never enough, especially if you have a sales or marketing team with a lot of imagination/needs. When we built a billing engine for a fintech (Qonto, that is now an European unicorn), the home made billing system took a month or two to develop, but it became a monster: iterations every month, new features asked by non tech users, new behaviors, bugs. The team of 2 engineers working on billing ended up being a core team of 12 people. We switched from backend engineers to billing engineers (that is not particularly funny when it's not your core product). Again, it depends your needs and the complexity required by your business. Happy to discuss that deeper if needed.
  - fendy3002 4y ago
    I've read your story and agree completely that billing is hard. However I see that you mixed billing/payment with pricing or bill calculation.

PaulHoule 4y ago

Organizations and individuals tend to oscillate. Often they do a "build" project that goes badly, resolve they are going to "buy", then "buy" goes badly and they are going to decide to "build" next time. It would be a mistake to assume that either "build" or "buy" is automatically superior in any given situation. What I will say is that the vendor has a team of flying monkeys that will spread FUD about "build" and the other vendors because that is the marketing message that moves the needle. How good the product is really depends on the mental model it is based on. If the mental model is right it will be excellent but if it is wrong you are in for a world of pain.

Rafsark 4y ago
Hi there, I'm Raffi, one of the co-founders of Lago (Billing API). I think this dilemma is amplified with specific topics like authentication, permissions or billing. Even if you come with a home-made solution that took you a month to build, it's a month that you've not dedicated building your own product. The second reason is because they require a lot of maintenance. Building a first version is never enough, especially if you have a sales or marketing team with a lot of imagination/needs. When we built a billing engine for a fintech (Qonto, that is now an European unicorn), the home made billing system took a month or two to develop, but it became a monster: iterations every month, new features asked by non tech users, new behaviors, bugs. The team of 2 engineers working on billing ended up being a core team of 12 people. We switched from backend engineers to billing engineers (that is not particularly funny when it's not your core product). Again, it depends your needs and the complexity required by your business. Happy to discuss that deeper if needed.
- fendy3002 4y ago
  I've read your story and agree completely that billing is hard. However I see that you mixed billing/payment with pricing or bill calculation.