diff --git a/src/content/daily-email/2023-09-16.md b/src/content/daily-email/2023-09-16.md
new file mode 100644
index 00000000..153ff5b5
--- /dev/null
+++ b/src/content/daily-email/2023-09-16.md
@@ -0,0 +1,60 @@
+---
+title: >
+  How not to break 36,000 websites
+pubDate: 2023-09-16
+permalink: >
+  archive/2023/09/16/how-not-to-break-36-000-websites
+tags:
+  - drupal
+  - php
+  - automated-testing
+  - test-driven-development
+---
+
+I've maintained the Override Node Options module for Drupal since early 2012.
+
+I've maintained the Drupal 7 version and written new versions for Drupal 8 onwards.
+
+At the time of writing, the module is used on at least 36,244 active Drupal websites.
+
+I don't want to break 36,000 websites, and automated testing is my way of avoiding that.
+
+I have three examples of how automated testing helped me when working on this module.
+
+## Upgrading to Drupal 8
+
+When writing the initial Drupal 8 version of the module, as I started re-writing a feature, the first thing I did was recreate the tests from the Drupal 7 version.
+
+Then, I followed a test-driven development approach to get the test passing using the Drupal 7 code for reference.
+
+When the whole test suite was in place and passing, I knew there was feature parity between the two versions.
+
+## Resolving a large merge conflict
+
+I was reviewing a feature request that had been open for some time, which included a large patch file with the code changes to implement it. 
+
+However, the patch no longer applied to the code, which caused various merge conflicts.
+
+There were no additional tests within the patch, but I was able to use the existing tests to ensure the original functionality worked once the merge conflicts were resolved and there were no regressions caused by committing the patch.
+
+I did later add tests for the new functionality, but without the original test suite, I would have likely not have accepted the patch and not committed the feature.
+
+## Refactoring the code
+
+A few years ago, a colleague and I wanted to refactor the module code to make it more maintainable and easier to work on.
+
+Then, the module was used on around 30,000 websites, so this could have been risky.
+
+However, we had the test suite to ensure the functionality still worked and that our refactors were successful.
+
+If we broke something and introduced a regression, a test would fail, and we could fix it.
+
+Following the release containing the refactored code, there were no reported issues or regressions from the community.
+
+## Here's the thing
+
+Automated testing is about providing confidence.
+
+Confidence the software works as expected and is releasable, either to clients for custom software or consumers of open-source software.
+
+With a passing test suite, you can add and change code with confidence and without worrying about breaking it.