diff --git a/meeting-notes/2025-03-26-demo-notes.md b/meeting-notes/2025-03-26-demo-notes.md
new file mode 100644
index 0000000..bec2eb1
--- /dev/null
+++ b/meeting-notes/2025-03-26-demo-notes.md
@@ -0,0 +1,26 @@
+​**DEMO:** 2025-03-26 @09:30
+**Present:** Bjorn, Gheorghe Loïs, Kevin, Hans, Eric, Kiara, Koen, Ronny, Valentin, Nicolas, Hans, Robert  
+
+**Demoed behavior**  
+* logged into the panel
+* selected services to deploy, saved configuration
+* clicked deploy button (observed NixOps4 working in the console)
+* accessed pixelfed.fediversity.net and logged in with hard-coded user
+* accessed mastodon.fediversity.net
+* (un-deployed mastodon, still there; not part of the planned demo features)
+
+**Demo notes (todo/actions/preperations)**  
+* Bjorn: from-scratch deployment takes a while (~400s), would need to talk a bit during the demo and explain what's happening at Fediforum
+* Koen: in the final version we may want to display some install-tainment in the web view (in addition to the progress indicator), e.g. what one can do with the various services
+* Progress indicator ideas (cherries on top)
+	* Count down from estimated time it will take
+	* Maybe show the progress log from CLI (advanced option?) 
+* Valentin: Should deploy to <service>.<user>.fediversity.eu (for a hard-coded username for now)
+	* And display the URLs in the panel (#264)
+* Bjorn: Should log payloads sent to NixOps4 so we can explain a bit more of the inner workings
+* Gheorghe: We may want imperative changes to service state or use a Staging Server as alternative for any special situation.
+	* Valentin: This would be purely a UX design issue mapping UI operations to the full-system declaration; the backend will still be declarative. We may need to consider performance/scheduling issues though, Kiara had opened issues regarding that
+* Bjorn: For the demo on 1-2 April: would be great if we can also remove a service.
+	* Nicolas: Currently if we disable a service, NixOps4 is not informed of the existence of this resource and doesn't do anything about it; will rewire the deployment code today to fix that
+	* Eventually we'll need more state than enabled/disabled, e.g. diagnostics mode where a service keeps running but isn't exposed via DNS
+		* Nicolas: This would need to manipulate something different than the actual machine on which the service runs, such as the load balancer; this is currently not mapped out in the architecture so it would be a topic for later
\ No newline at end of file