• A pricing model that scales with our success and allows for spikey traffic.
• A stable interface. If you want to change something make it backwards compatable or give us notice of change.
• Have a status page similar to status.io that is accurately updated.
• Respond to support requests in hours not days.
• Use webhooks rather than emails to announce outages, maintenance windows and upgrades.
• We need to use an api to deploy or configure your service.
• We need an api to reconcile any billing transactions with payments.
• We will have multiple environments (qa, perf, staging, live) and only expect full price and support on live and perf.

Recently I have been working on a data warehouse project that is trying to extract billing and payment information from a range of cloud services. In all cases it seems that the data needed by the accountants has not been given the care that it needs.

The industry practice seems to be log into a portal and download a spreadsheet of data that may be accurate or timely. Any api’s exposing this data seem to only work on a per order basis – which means that an attempt to keep a database upto date could require geometrically increasing processing times (you need to check each order for changes to a transaction).  These api’s tend to be heavily restricted on the volume of data per call (hundreds of transactions per call) combine this with a frequently undocumented rate limit make catching up historical data difficult at best.

If you are providing services that accountants need think about providing an api that makes reconciliation easy. Reconciliation is important especially if you want to get your tax calculations right.

I am getting increasingly frustrated with the quality of the packages in NPM.

Is seems that it’s ok to randomly change code and leave things in a broken state (or at least have a stack of errors for simple usage.