4 ms·

As I understand it, it's easier to write a program from scratch rather than implement an existing solution?

PaulHoule 4y ago
"Build" vs "Buy" is the dilemma of enterprise software. My first instinct as a software dev is that coding up a prototype of a billing system can be completed more quickly than evaluating two or three vendors of billing systems. Either way you can be highly successful or deeply disappointed. What really matters is the match between the mental model behind the system and your domain. In principle the product you buy can have a lot more labor in it both in terms of design and implementation. On one level you benefit from outside investment into vendor but on another level you (and the investors) are paying for sales, marketing and management at the vendor too. The commercial product almost certainly has a better looking UI for your team to use. Something you develop yourself will likely have a minimal UI but if it meets your needs than that's good enough.
- MountBridge 4y ago
  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.
koliber 4y ago
Not necessarily. Using a platform is the best way to go if the platform fits your needs. I'm guessing that you already suspect that your use case might not fit what Stripe or Recurly or other platform vendors offer. It might be tempting to build your own, but.... Read this: Billing systems are harder to build than anyone ever thinks https://www.getlago.com/blog/why-billing-systems-are-a-nightmare-for-engineers https://www.getlago.com/blog/why-billing-systems-are-a-night... There is another way. Simplify your use case so that it does fit one of the platforms. Reduce some features, or change the complexity of your billing setup. It may seem counterintuitive, but often this is the way to go. You don't need a custom kitchen if one of the IKEA cabinets does not fit in the corner. It may be better to go with IKEA after all, and leave the corner without a cabinet.
- deleted 4y ago
  [deleted]
zomgwat 4y ago
After spending years maintaining a home grown billing system, I recommend against rolling your own. It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting (that more directly impact the value of the business). I learned through experience that billing systems are complex and the complexity can sneak up on you over time.
- mgkimsal 4y ago
  > It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting The key diff between 'build' vs 'buy' seems to come down to an accommodation of one-off and sometimes frankly 'wrong' processes. Using off the shelf prevents accommodating many oddities companies have accumulated (via growth, acquisition, whatever). Build from scratch seems to always implicitly include "we'll handle every weird-ass edge case anyone might come at us with in the future, because we built it ourself". There could be a middle ground of "build with certain parameters, but also normalize some existing processes by refusing to spend hundreds of hours building weird accounting processes for 1 customer someone because a salesperson needed to hit their target and told them anything was possible". Dealt with accounting stuff years ago, and ... there weren't any accounting systems which could simply/easily handle 20 years of homegrown cruft. "If the customer number starts with P or X, and the account rep is Randy, they get a 5% discount until next summer". They had... 5000 customers, and about 30% of them had ad-hoc 'rules' like that. Hundreds of business rules various people just 'knew'. Just documenting and classifying them can take weeks. I'm not saying no commercial systems can ever support that level of customization, but "we'll import all your stuff with 3 mouse clicks"-style marketing fluff ignores the reality that ... you have to adapt your business some, or you have to build in house. But even building in house, you still need to adapt your business processes to reduce/eliminate ad-hoc rules that people just yell down the hall to the accounting team.
  - zomgwat 4y ago
    It sounds like we've had very similar experiences. The fact that what you've described is so similar to what I've seen may say something. There are reasons to have a bespoke billing system but people should try REALLY hard to avoid the situation. Something I saw regularly with one-off style sales deals was not accounting for the collateral damage to business processes like end-of-month accounting. It's not just the development costs for adding support to things like subscriptions. Changes ripple all the way through the business. Updates to the bespoke billing system (and related business processes) end up half-baked because they aren't a core part of the business. I've seen sales deals end up as a net loss over time due to the increased labor costs on the backend. Having some reasonable constraints that an off-the-shelf product will intrinsically enforce can prevent a lot of pain for all involved.
hbrn 4y ago
It is not easier, but in order to understand why it's not easier, writing from scratch is one of the best options. And without understanding, what are the chances you'll come up with a good solution (either yourself, or through another SaaS)? In essence, whatever path you take, anticipate that you will do a bad job on your first attempt. Failing is a learning step you can't skip.

"Build" vs "Buy" is the dilemma of enterprise software. My first instinct as a software dev is that coding up a prototype of a billing system can be completed more quickly than evaluating two or three vendors of billing systems. Either way you can be highly successful or deeply disappointed. What really matters is the match between the mental model behind the system and your domain. In principle the product you buy can have a lot more labor in it both in terms of design and implementation. On one level you benefit from outside investment into vendor but on another level you (and the investors) are paying for sales, marketing and management at the vendor too. The commercial product almost certainly has a better looking UI for your team to use. Something you develop yourself will likely have a minimal UI but if it meets your needs than that's good enough.

MountBridge 4y ago
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.

koliber 4y ago

Not necessarily. Using a platform is the best way to go if the platform fits your needs. I'm guessing that you already suspect that your use case might not fit what Stripe or Recurly or other platform vendors offer. It might be tempting to build your own, but.... Read this: Billing systems are harder to build than anyone ever thinks https://www.getlago.com/blog/why-billing-systems-are-a-nightmare-for-engineers https://www.getlago.com/blog/why-billing-systems-are-a-night... There is another way. Simplify your use case so that it does fit one of the platforms. Reduce some features, or change the complexity of your billing setup. It may seem counterintuitive, but often this is the way to go. You don't need a custom kitchen if one of the IKEA cabinets does not fit in the corner. It may be better to go with IKEA after all, and leave the corner without a cabinet.

deleted 4y ago
[deleted]

zomgwat 4y ago

After spending years maintaining a home grown billing system, I recommend against rolling your own. It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting (that more directly impact the value of the business). I learned through experience that billing systems are complex and the complexity can sneak up on you over time.

mgkimsal 4y ago
> It's frustrating to spend time adding yet another hack to account for some new use case while there is a stack of other priorities waiting The key diff between 'build' vs 'buy' seems to come down to an accommodation of one-off and sometimes frankly 'wrong' processes. Using off the shelf prevents accommodating many oddities companies have accumulated (via growth, acquisition, whatever). Build from scratch seems to always implicitly include "we'll handle every weird-ass edge case anyone might come at us with in the future, because we built it ourself". There could be a middle ground of "build with certain parameters, but also normalize some existing processes by refusing to spend hundreds of hours building weird accounting processes for 1 customer someone because a salesperson needed to hit their target and told them anything was possible". Dealt with accounting stuff years ago, and ... there weren't any accounting systems which could simply/easily handle 20 years of homegrown cruft. "If the customer number starts with P or X, and the account rep is Randy, they get a 5% discount until next summer". They had... 5000 customers, and about 30% of them had ad-hoc 'rules' like that. Hundreds of business rules various people just 'knew'. Just documenting and classifying them can take weeks. I'm not saying no commercial systems can ever support that level of customization, but "we'll import all your stuff with 3 mouse clicks"-style marketing fluff ignores the reality that ... you have to adapt your business some, or you have to build in house. But even building in house, you still need to adapt your business processes to reduce/eliminate ad-hoc rules that people just yell down the hall to the accounting team.
- zomgwat 4y ago
  It sounds like we've had very similar experiences. The fact that what you've described is so similar to what I've seen may say something. There are reasons to have a bespoke billing system but people should try REALLY hard to avoid the situation. Something I saw regularly with one-off style sales deals was not accounting for the collateral damage to business processes like end-of-month accounting. It's not just the development costs for adding support to things like subscriptions. Changes ripple all the way through the business. Updates to the bespoke billing system (and related business processes) end up half-baked because they aren't a core part of the business. I've seen sales deals end up as a net loss over time due to the increased labor costs on the backend. Having some reasonable constraints that an off-the-shelf product will intrinsically enforce can prevent a lot of pain for all involved.

hbrn 4y ago

It is not easier, but in order to understand why it's not easier, writing from scratch is one of the best options. And without understanding, what are the chances you'll come up with a good solution (either yourself, or through another SaaS)? In essence, whatever path you take, anticipate that you will do a bad job on your first attempt. Failing is a learning step you can't skip.