+
+ $for(include-before)$
+ $include-before$
+ $endfor$
+
+
+ $body$
+
+
+
+
+
diff --git a/website/pitch.org b/website/pitch.org
new file mode 100644
index 0000000..f7fb780
--- /dev/null
+++ b/website/pitch.org
@@ -0,0 +1,53 @@
+#+title: Grimu-R pitch deck
+* Key benefits
+** Rapid prototyping
+- Visual development and debugging
+- Executed directly on dev's machine
+- Immediate feedback
+** Flexibility
+- Not just workflows and dashboards -- anything
+- Embed existing software into a Grimu-R project
+- Embed a Grimu-R project itself into a larger flow
+- No inherent deployment limitations, execute anywhere
+** Clear evolution and hardening path
+- Start with a visual, interactive prototype
+- Decompose into components
+- Add builds and deployments
+- Call Grimu-R components from non Grimu-R components
+- Automate testing
+** Malleability
+- Power users have the same superpowers as developers
+- Can inspect, modify and extend available components in the visual editor
+- Highly adaptable, customizable internal tooling
+** No more "works on my machine"
+- Reproducible environments and builds with Nix
+- Every developer has the same tooling installed automatically
+** Knowledge transfer
+- Visual flow gives a clear overview and facilitates dev onboarding
+- Execution graphs are self-documenting, serving both as code and a diagram for it
+- Easier participation for less technical team members
+** Reusable modules
+- Base library components and integrations
+- An open ecosystem of third-party utilities, open-source and commercial
+- Develop and sell your own modules, or open source and get community support
+** Free as in freedom
+- The Grimu-R platform is open source, can be employed and extended freely
+- Works on your machines, not in some cloud you don't control
+* Caveats
+** Bespoke reactive dataflow graphs and tooling
+- Developers and power users need to get familiar with the mental model and tools
+- General, intuitive concepts but still unorthodox
+- Nifty and precise but alien jargon
+** Nix
+- Steep learning curve for developing your own components
+- Hated by a huge % of devs
+- There are limited ways to opt out
+** Performance overhead
+- Visual/textual scripts are fast to create, slow to execute
+- Compiled binaries can be used at the cost of some convenience
+- Deployable bundles are huge in volume
+- No single "blessed" way to scale (yet)
+** Copyleft licensing
+- The platform can be extended, and contributions are welcome
+- But your contributions must also be open source
+- Only applies to the platform -- not components and modules!