91–100 of 105 posts
Earlier quoted context omitted.
I built a billing system for a web hosting company in PHP, almost 20 years ago. This was for a few hundred users. There were a couple of edge cases, but nothing incredibly challenging.
Was it a basic subscription model or have you faced challenges with taxes, usage-based components, entitlements, grand fathering?
Billing in general is very hard. Especially subscription billing. Just from my experience in building billing and also later on using a third party system for another projects, I can mention so many edge cases: 1. Grandfathering 2. Upgrading across different length memberships (monthly tier 1 to yearly tier 2) 3. Crossgrading across different lengths (monthly tier 1 to quarterly tier 1) 4. Offering free trial to tier…
>> Now, when someone asks for advice about their billing system, my answer is clear: DO NOT build it yourself.
Moving from using CGI.pm to CouchDB/PouchDB about 10 years ago made it much easier to manage users and their data, and implement the UI. It also moved most of the workload to the user's web browser and made the app much faster for users.
CouchDB was practically designed for this. Early on their developers used "invoicing" as an example for using CouchDB.
But... if you have a marketing team that keeps moving the goals it wouldn't matter what you built the app with, it's going to take time to build and debug it. Could be that CouchDB/PouchDB could make that easier, but my experience is developers who've only been using SQL may get frustrated with it.
Creating and maintaining a billing system would be another good test for AI.
What's your vision? Can AI handle revenue prediction and billing engineering tasks? Both? How?
Good article, and I generally agree that people are too quick to say “Ahh, this looks like a two week project” and ignore broader complexity. I’ve definitely seen a fair amount of that. My question is, how do I know that the OTS solution would actually be much better? For example, OP describes some tricky migrations from one type of billing to another, or complex grandfathering schemes - how would you have any guaran…
Earlier quoted context omitted.
Except with many of these enterprise solutions (SAP, Netsuite, Salesforce) most companies will still need to pay consultants 300 dollars an hour to configure and maintain the application. These costs often exceed the license cost itself. Bottom line, complexity is expense regardless if you build or buy. Companies need to factor the systems and operations impact of complicated pricing and billing models into the decis…
The absolute cost isn't important here. What's important is that cost is now explicitly on the balance sheet were someone can see it. If you have an in-house system, that team is treated as an infinite supply of features for no apparent cost. (Ask me how I know.) And as a developer, I love being able to hand certain people over to vendors who are used to dealing with those certain people. Hell, if we picked the right…
Good article, and I generally agree that people are too quick to say “Ahh, this looks like a two week project” and ignore broader complexity. I’ve definitely seen a fair amount of that. My question is, how do I know that the OTS solution would actually be much better? For example, OP describes some tricky migrations from one type of billing to another, or complex grandfathering schemes - how would you have any guaran…
>, how do I know that the OTS solution would actually be much better? For example, [...] how would you have any guarantee that your third party solution would be able to support those? The business (employees in the accounting dept and/or consultants) do a "fit-gap analysis" when evaluating potential software: https://www.google.com/search?q=fit+gap+analysis For the "gaps" of missing functionality, look at either : (…
I've built several billing systems and managed a team that built a much larger one, and it's not that hard, but it does require an attitude and attention to detail that a lot of people lack. E.g. one thing that worked well in the systems I've worked on was to break things into small state transitions, very firmly document the allowed states and their transitions, and log every transition to the database. Wherever pos…