Client Rider

Entertainers often specify a set of requirements or demands for their performance in form of a so called “rider” (see Wikipedia). Since we believe that it makes sense to clarify expectations as early as possible, we decided to als come up with a rider for our clients.


Technical Infrastructure

** Sending emails **

Because it doesn’t make sense to setup/maintain own mail servers, we exclusively work with commercial 3rd party mail sending services. We currently recommend Mailgun (an alternative option would be SendGrid).

** Hosting **

  • You will need at least 2 different servers: one production server and one staging
  • We strongly recommend hosting with companies that have a proven track record hosting Ruby on Rails applications, e.g. Brightbox or Heroku
  • If your application will allow any uploading of files, you will need to create an Amazon S3 account and provide us with credentials. An external service needs to be used for file storage, because otherwise there can be only one application server which is very bad for scaling.

** Invoicing **

Almost every plattform needs invoices. Instead of implementing our own invoicing tool we’re using SalesKing. SalesKing has a very easy to integrate API and can integrate it into your plattform very quickly.


Agile Product Development/Management

Some good resources:


Design

How to provide your design?

  • Ideally designs should be provided in 3 different formats (in order of importance):
    • rendered layouts
    • source .PSD files
    • sliced up images (preferably .png)

Fonts

Sliced images

  • should generally be .png files (except for larger photos it’s better to use .jpg)
  • use alphatransparent backgrounds for your .png’s whereever needed
  • please don’t use .gif
  • if you provide icon’s please slice up with consistent dimensions (e.g. all in 20x20, or 32x32, or whatever)
  • if you provide images for hover states call them “normalimagename_hover.png”

Working with freelancers & new developers

Successfully integrating new developers into an existing project is difficult and should not be taken lightly. Here are some things you should take into account:

  • Before working well together remotely, it is absolutely required to have at least a short face-to-face meeting to find out about each others backgrounds.
  • Depending on the experience of the new developer there should be a face-to-face learning phase, that should be between 2 days and several weeks. For example in the past it has worked very well to train a Junior Developer in Cologne for just some weeks to have somebody working really well in the project afterwards.
  • It does NOT make sense to train a new developer below senior level, who will likely only be with the project for less than ~3 months. The cost is just too high, no matter how cheap the developer is.
  • Being able to ask the right questions and communicating well are much more important skills in a distributed team, than technical skills.