diff --git a/README.md b/README.md
index 9e261d9..25c5b8c 100644
--- a/README.md
+++ b/README.md
@@ -42,6 +42,7 @@ Backend development best practices
   - [HTTP status codes](#http-status-codes)
   - [Load balancer health checks](#load-balancer-health-checks)
   - [Access control](#access-control)
+  - [Avoid quick & dirty approaches](#avoid-quick-&-dirty-approaches)
 - [Release checklist](#release-checklist)
 - [General questions to consider](#general-questions-to-consider)
 - [Generally proven useful tools](#generally-proven-useful-tools)
@@ -420,6 +421,16 @@ The load balancer health check page should be placed at a `/status/health` URL.
 
 The status pages may need proper authorization in place, especially in case they expose debugging information in status messages or application metrics. HTTP basic authentication or IP-based restrictions are usually good enough candidates to consider.
 
+## Avoid quick & dirty approaches
+
+In projects with very limited time and/or budget, one might considers an easy approach to error reporting. One of these approaches is to send automatic email whenever something goes wrong.
+
+In some cases, this might be enough, but in case of high traffic applications email-based reporting can produce unwanted side effects:
+* If critical backend API goes down (i.e. some legacy system fails to respond for longer period of time), huge amount of error mails are generated in short period of time.
+* Some errors are more critical than others. Reporting _everything_ generates a lot of noise and actual problems might be missed.
+
+For QA email works out just fine, but in PROD this should be avoided.
+
 # Release checklist
 
 When you are ready to release, remember to check off everything on your release checklist! The resulting peace of mind, repeatability and dependability is a great boon.