diff --git a/content/day1/07_devex.md b/content/day1/07_devex.md
new file mode 100644
index 0000000..a91babb
--- /dev/null
+++ b/content/day1/07_devex.md
@@ -0,0 +1,78 @@
+---
+title: What going cloud native taught us about developer experience
+weight: 7
+tags:
+ - devex
+---
+
+<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
+<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}} -->
+
+## History/Base on-prem
+
+- Monolith
+- High autonomy regarding releases into prod (auto gen)
+- Comfort features -> It just works™
+
+## Goals
+
+- Microservices
+- Accelerated processes
+- Better dev experiences
+
+## The road
+
+### Expectations
+
+- Expected new work for developers: CI/CD, GitOps, Monitoring, Security, Resilience, Connect to other services
+- New for developers: Kubernetes with a bunch of surrounding tech
+
+### Journey
+
+1. Start of jurney: Usually a transition towards the cloud with some kubernetes and deployment templates and less legacy stuff
+2. Result:
+    - Implementation: Gigantic base manifests with maybe sume overlay abstraction (kustomize or helm)
+    - Expectation: Works in all environments
+3. Considerations:
+    - Developers will change config (its only a question of when and not if)
+    - The migration from an env file to kubernetes compliant yaml can be a hard one
+4. Iteration: The developer friendly config is our new goal
+
+### The developer friendly config
+
+> e.g. in a helm values file
+
+- Easy to understand and configure
+- Think about the dev experience (sane defaults)
+- Allow templating
+- Provide documentation
+
+## Developer centric approach to cloud native
+
+> There are not many technical problems in cloud native, most are experience related
+
+### Remember
+
+- Your users won't react the way you expect them to
+- The plattform sould serve the need of your users, not the other way around
+- Users will come to you, if you build a nice environment for them
+
+### What do your users need
+
+- Every service is like it's own area -> What connections does it need to the outside and how do i ensure it's health
+- Reduced cognitive load: Avoid developers being occupied with foundational work instead of delivering value
+- The new env needs to be as nice or nicer than the old env
+
+### How to help them
+
+- Bootstrapping: Define blueprints (including dependency services line databases) and automate stuff with defined goals (my service should be deployed 5 mins after bootstrapping)
+- Tooling: Backstage (yay)
+- Establish training programms and communities
+
+## Wrap up
+
+- Interfaces are important
+- Ensure roads to your service are well maintained and documented
+- Build standards and contracts to ensure that others can rely on your service
+- Build a example project that is not too big, but tackels real-world challenges
+- Remember that developers are used to the old way of working which has a bunch of creature comforts