As I understand it, it's easier to write a program from scratch rather than implement an existing solution?
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-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.
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.
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.
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.
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))
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.
Again, it depends your needs and the complexity required by your business. Happy to discuss that deeper if needed.
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.