diff --git a/flake.nix b/flake.nix
index 1a108f92..06fca3a5 100644
--- a/flake.nix
+++ b/flake.nix
@@ -6,7 +6,7 @@
     { nixpkgs, ... }:
     let
       system = "x86_64-linux";
-      pkgs = nixpkgs.legacyPackages.${system};
+      pkgs = import nixpkgs { inherit system; };
     in
     {
       devShells.${system}.default = pkgs.mkShell {
diff --git a/source/_daily_emails/2025-01-23.md b/source/_daily_emails/2025-01-23.md
new file mode 100644
index 00000000..c76cc50f
--- /dev/null
+++ b/source/_daily_emails/2025-01-23.md
@@ -0,0 +1,23 @@
+---
+title: Who's Travis?
+date: 2025-01-23
+permalink: daily/2025/01/23/travis
+tags:
+  - software-development
+  - ci
+cta: ~
+snippet: |
+  Who's Travis? Are they a new member of the team?
+---
+
+I remember seeing a talk or listening to a podcast during which they mentioned Travis, as in the CI pipeline tool, and some of the things they were using it for.
+
+They also said that their client thought Travis was a person on their team.
+
+In some ways, having a CI pipeline performing automated checks and tests is like having another team member.
+
+Instead of waiting for a person to manually check code styles, run tests and spot potential bugs, why not automate them and run them in the CI pipeline every time code changes are pushed?
+
+You'll get results sooner than waiting for a person do check the code by hand and, arguably, more consistent results.
+
+Then, if you do peer code reviews, you know the basics are already done and the reviewer can focus on other things.