diff --git a/website/src/daily-emails/2022-11-24.md b/website/src/daily-emails/2022-11-24.md
new file mode 100644
index 00000000..5ce18efe
--- /dev/null
+++ b/website/src/daily-emails/2022-11-24.md
@@ -0,0 +1,29 @@
+---
+title: >
+  Doing the simplest possible thing
+pubDate: 2022-11-24
+permalink: >
+  archive/2022/11/24/doing-the-simplest-possible-thing
+---
+
+I spent most of today working on some code I wrote for the first phase of a client project a few months ago.
+
+The previous version used hard-coded data within a Vue.js application, which was sufficient for the previous criteria and in line with the lean approach we decided to take.
+
+It was the simplest thing that worked.
+
+A new requirement means that the hard-coded data no longer works, so I need to refactor and enhance the code to work with different configurations. I have a proof of concept of this working using JSON from an API endpoint, but I would also like to use a static JSON file when needed for local development.
+
+I experimented with a few different ways to approach this before asking myself, "What's the simplest possible thing I can do to get this working?".
+
+I already knew that I needed to make a change to the structure of the data, which I was able to do quickly with the hard-coded data that I already had, and whilst a static JSON file would be a nice-to-have, I could quickly move the hard-coded data into the API endpoint that I'd already created and continue building on my proof of concept.
+
+The idea of "What's the simplest thing?" is something that I use regularly.
+
+When teaching or coaching test-driven development, I want to write the smallest failing test and then find the quickest and simplest way to get it to pass - even if it means returning a hard-coded value for now.
+
+When working on development tasks, I like to break things down as much as possible and find the smallest thing I can do, commit, and push. This gets the ball rolling, and then I repeat the process.
+
+Even when writing an email or blog post, once I start writing, it's much easier to continue once I'm in the flow.
+
+Taking the simplest approach and not making assumptions about future requirements or scope means less and more maintainable code, as well as being a productivity hack.