diff --git a/src/content/daily-email/2023-09-02.md b/src/content/daily-email/2023-09-02.md
new file mode 100644
index 00000000..e5381f54
--- /dev/null
+++ b/src/content/daily-email/2023-09-02.md
@@ -0,0 +1,31 @@
+---
+title: >
+  Planning first or reviewing last?
+pubDate: 2023-09-02
+permalink: >
+  archive/2023/09/02/planning-first-or-reviewing-last
+tags:
+  - code-review
+  - pair-programming
+  - mob-programming
+---
+
+Code reviews are something that happens after the code has been written.
+
+Usually, a task is assigned to someone who completes it and makes the code available to their team members before it's merged.
+
+The problem is that if the implementation is wrong, it's already been written, which costs time and money.
+
+If the change needed to be rewritten or majorly changed before it could be merged, as well as being an awkward conversation, it would cost more time and money to do.
+
+## Here's the thing
+
+Instead of reviewing the code after it's been written, invest more time into planning how the implementation should work upfront.
+
+What potential solutions exist, and which would work best in this situation?
+
+Write technical design documents and, if needed, create a small proof of concept.
+
+Do this as a team and decide on the approach before any code is written and time or effort is spent.
+
+Then, the person working on the task will have a clearer path, and if you still want to review the code afterwards, you have something to compare it to.