Add introduction to readme

README.md

@@ -1,9 +1,21 @@
 # Hipo DRF Exceptions
 [![hipo](https://img.shields.io/badge/hipo-red.svg)](https://hipolabs.com) [![Build Status](https://travis-ci.org/Hipo/hipo-drf-exceptions.svg?branch=master)](https://travis-ci.org/Hipo/hipo-drf-exceptions) [![pypi](https://img.shields.io/pypi/v/hipo-drf-exceptions.svg)](https://pypi.org/project/hipo-drf-exceptions/)
 
-
 A [Django](https://www.djangoproject.com) app for returning consistent, verbose and easy to parse error messages on [Django Rest Framework](https://www.django-rest-framework.org/) backends.
 
+Parsing error messages generated by DRF is a bit of pain for client developers. They need to try-catch different possible error formats. When you add errors raised at the business logic level, the error parsing becomes even more difficult. 
+
+This package unifies the output format of DRF, in "Hipo" protocol. 
+
+####No more "An error occured." errors.
+
+This package also provides the "fallback message", a text string that always contains a human readeable error summary. This way, client developers can always fallback to this messagge and show this message when the client receives an error that is not handeled.
+
+> Sounds cool! Can client devs just use this field all the time?
+
+In our past experience, we noticed that some _lazy_ client developers tend to use this message and avoid writing any code to parse the error bundle. However, the message in this field is automatically generated and not always in an excellent literature format. In order to make clear that this is a *fallback*  message, we named this field "fallback_message"
+
+
 ## Table of Contents
 
 - [Installation](#installation)