Purchasing services for client work

Purchasing services for client work

We (digital services providers) use a lot of different kind subscription based services in our work. Managing service subscriptions, licenses and domains is still an unsolved problem, but with few steps we can make things at least better.

The problem can be divided to Initial Purchase and Management.

This blog post focuses more on the crucial initial purchase phase where lot of communication with the client and rest of the team takes place.

Rachel Andrew wrote an informative article called Small Business Software Audits which focuses management part of the services, domains etc. Highly recommend to read it.


When there is a need for new service/product the next thing is to explain to the customer: why we need it, what it costs and what alternatives there are (if any). Some of them might say that they trust you and there is no need to explain all this. Persuade them to listen for their own sake.

Let's take my current project as an example.

We have non-technical business owner and plenty of highly technical services like DNSimple, Heroku, GitHub, Compose.io etc. Even though the product owner doesn't personally login to those services on a daily basis it's still important to go through each service. Some of the services might be more difficult to explain than others. Continuous integration as a service is a bit abstract, but it's a good communication exercise for the developers.

Explaining each service helps people to understand applications infrastructure, nature of the service, is it for developers/Q&A, is it crucial, helps later to find work force for particular problem etc.


After short discussion with the money holder the service subscription is ready to be purchased.

Most services that I have encountered use email address as a login credential. Addition to email address there might be username, but if you forget your password then valid email address is required.

Even though we're the ones using the service we shouldn't be using our personal or business email addresses. We shouldn't be using client's personal or business email address either as then we get too much access to their personal and/or business information.

For clients I normally create development email account that we use when registering to various services. The client gets access to the email account at the beginning of the project. She/he can then link the email account to her/his business email or use it as a separate account. Best thing would be that email address belongs client's domain and not some random email provider.


Here is a small checklist what to do when new service is needed:

  1. explain what the service is, why it's needed, what are the costs, is it recurring and is it monthly or annual
  2. if there are alternatives then explain those
  3. after short discussion create new account to the service using development email account
  4. open payment page or send payment page link to the person who has credit card access
  5. store password to the service in a secure place that has been decided with the customer

At the end of the project handover deliver infrastructure diagram that lists services, domains, databases etc.

Price tracking for the services should be done by the customer and you should just give an estimate.

Any thoughts on this? I would like to hear how you have handled these situations!