# Projekte — vollständige Referenz Alle dokumentierten Referenzprojekte mit Auftragsverhältnis, Links und Hintergrund zu Eigentümern und Umfeld. Das Auftragsverhältnis (via) gehört zu jedem Projekt: Die Konzernnamen liefen über Agenturen, nicht als Direktmandate. ## Flashy.chat — On-Chain-Messaging Zeitraum: seit März 2026 Rolle: Konzept, Smart Contracts und Frontend Auftragsverhältnis: Eigenes Produkt Website: https://flashy.chat Dezentrale Messaging-Plattform auf Ethereum und Base, bei der jede Nachricht eine permanente On-Chain-Transaktion ist. Mit Morpho-Flash-Loan-Integration und permanenten Bildnachrichten über IPFS. - Jede Nachricht ist eine permanente Transaktion auf Ethereum oder Base — keine Datenbank, kein Server, der sie löschen könnte - Morpho-Flash-Loan-Integration: pro Nachricht werden rund 5,3 Mrd. USD an verfügbarer Flash-Loan-Liquidität angesprochen (2,7 Mrd. auf Ethereum, 2,6 Mrd. auf Base) - Permanente Bildnachrichten über IPFS statt zentraler Dateiablage - Bisher rund 1'400 On-Chain-Transaktionen abgewickelt Technologien: Solidity, Ethereum, Base, Flash Loans, IPFS, Nuxt ## FairTransform Zeitraum: seit August 2025 Rolle: Technische Umsetzung Auftragsverhältnis: Eigenes Projekt Website: https://fairtransform.ch Plattform für eine faire und nachhaltige Transformation von Wirtschaft und Gesellschaft. Konzeption und technische Umsetzung. Technologien: Nuxt, TypeScript, Tailwind CSS ## Consulting Suisse Zeitraum: seit Juni 2025 Rolle: Konzept und Umsetzung Auftragsverhältnis: Eigenes Projekt Website: https://consultingsuisse.ch Webauftritt für Beratung rund um Gründung, Finanzen und Verwaltung von Schweizer Unternehmen. Technologien: Nuxt, TypeScript, SEO ## Open Source: muse.js, freqgen, exquis-midi & mindpeeker-sdk Zeitraum: laufend Rolle: Autor und Maintainer Auftragsverhältnis: Eigene Arbeit Website: https://github.com/orgs/Polobase/repositories Vier quelloffene TypeScript-Bibliotheken, die ich unter der GitHub-Organisation Polobase betreue — alle MIT-lizenziert und öffentlich einsehbar. Drei davon binden echte Hardware an, die vierte verbindet Zufallszahlen-Technik mit statistischer Auswertung. - muse.js — TypeScript-Bibliothek für Muse-EEG-Stirnbänder mit vollwertiger Unterstützung für Muse S Athena; dekodiert das DRL/REF-Paar, das keine andere Bibliothek ausliest - freqgen — TypeScript-Treiber für USB-serielle Signal-/Frequenzgeneratoren (FeelTech FY, JUNTEK, Koolertron, Spooky2) hinter einer herstellerneutralen Schnittstelle, in Node und im Browser; hervorgegangen aus feeltech - exquis-midi — vollständige Steuerung des Intuitive-Instruments-Exquis-MPE-Controllers (LEDs, Eingaben, mikrotonale Layouts) über die offizielle Developer-Mode-MIDI-API, in Node und im Browser - mindpeeker-sdk — Zero-Dependency-SDK in TypeScript/Bun: Zufallszahlen-Technik nach NIST SP 800-90B mit Extraktoren und VDFs, kombiniert mit statistischen Auswertungsverfahren - Alle vier quelloffen unter MIT-Lizenz und öffentlich nachvollziehbar; muse.js und mindpeeker-sdk mit Playground zum Ausprobieren im Browser Technologien: TypeScript, npm, Bun, Open Source ## Paddle8 Zeitraum: Juni 2023 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Winterthur Medien AG Archivierte Fassung: https://web.archive.org/web/20230603020728/https://paddle8.com/ Kurzmandat für das Online-Auktionshaus Paddle8, umgesetzt im Rahmen der Zusammenarbeit mit der Winterthur Medien AG. Technologien: Frontend, Website, Auktionen Eigentümer: - P8H Inc., New York — die Gesellschaft hinter Paddle8, gegründet im Mai 2011 von Alexander Gilkes (ehemals LVMH, Chefauktionator bei Phillips), Aditya Julka (Baker Scholar der Harvard Business School) und Osman Khan (Goldman Sachs, Perella Weinberg; Harvard MBA) - Mai 2016 bis Februar 2017: Fusion mit der Berliner Auktionsplattform Auctionata, ab September 2016 unter CEO Thomas Hesse. Auctionata meldete im Februar 2017 Insolvenz an, Paddle8 wurde wieder eigenständig - Februar 2017: finanziert durch Lightyear Collective, ein im Januar 2017 in Delaware gegründetes Multi-Family-Office, dessen Gesellschafter nicht offengelegt wurden — bekannt ist Christopher Hsu von Kilometre Capital Management, Hongkong - Dezember 2017: P8H Inc. wird von einem Syndikat Schweizer Investoren übernommen, die Izabela Depczyk als Interims-CEO und Change Managerin einsetzen - Januar 2018: The Native SA, Lausanne (SIX: NTIV), unter Chairman Sergey Skaterschikov kauft 15 % für 8,8 Mio. USD, mit einer Option auf weitere 36 % für rund 25,6 Mio. USD. The Native SA hielt zudem 51 % an der asknet AG und 100 % an der Blockchain Lab AG - August 2019: Pulse Evolution Group Inc. übernimmt die Schweizer Facebank AG, benennt sich in Facebank Group Inc. um und wird darüber grösste Aktionärin der P8H Inc. Im November 2019 wird Valentine Uhovski CEO Umfeld: - Founder Collective und Mousse Partners — führten die Series A über 4 Mio. USD an. Mousse Partners ist das Family Office von Alain und Gérard Wertheimer, den Eigentümern von Chanel, 1991 von Charles Heilbronn gegründet — kein Vehikel der Familie Agnelli, wie in Sekundärquellen mitunter behauptet - Juni 2013, 6 Mio. USD: Damien Hirst, Prinz Alexander von Fürstenberg, der russische Unternehmer Vladimir Yevtushenkov, Matthew Mellon und Jay Jopling von White Cube - Oktober 2015, Series C über 34 Mio. USD: David Zwirner (der in den Verwaltungsrat eintrat), Rolf Sachs, Eric Fellner von Working Title Films, Edgar Berger von Sony Music Entertainment International, dazu Mousse Partners, Damien Hirst, Jay Jopling und Stavros Niarchos. Bis dahin insgesamt 44 Mio. USD eingeworben - Cameron und Tyler Winklevoss — Berater für die 2018 geplanten Blockchain-Auktionen - Über 300 Non-Profit-Institutionen, vom LACMA über das Guggenheim bis zur Brooklyn Academy of Music, deren Benefizauktionen über die Plattform liefen Verwandte Projekte: garage-italia-nft, winterthur-medien, youngtimers, phygify Hinweis: Zwei Stränge dieses Aktionariats treffen sich an anderer Stelle dieser Liste wieder. Vladimir Yevtushenkov, Investor der Runde von 2013, kontrolliert Sistema, deren MTS Group Sergey Skaterschikov von 2006 bis 2008 als VP M&A beschäftigte; Skaterschikov wurde später Chairman der The Native SA, die 2018 bei Paddle8 einstieg. Unabhängig davon wurde im Februar 2023 berichtet, dass die Familie Wertheimer über Mousse Partners zu den Investoren gehörte, die Rothschild & Co von der Börse nahmen. Paddle8 meldete im März 2020 Chapter 11 im Southern District of New York an, eine Woche nachdem die New American Cinema Group wegen mutmasslich zweckentfremdeter Mittel aus einer Benefizauktion geklagt hatte; unter den Gläubigern standen Justin und Hailey Bieber mit rund 73'000 USD und die Shawn Carter Foundation von Jay-Z mit rund 65'000 USD. Das Mandat vom Juni 2023 fiel damit deutlich nach der Insolvenz, im Auftrag der Winterthur Medien AG. paddle8.com löst zwar noch auf, zeigt aber eine Parkseite — deshalb verweist dieser Eintrag auf eine datierte Archivkopie. ## No Bias Media Zeitraum: Oktober – November 2022 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Winterthur Medien AG Archivierte Fassung: https://web.archive.org/web/20241008080602/https://www.nobias.media/ Website für No Bias Media, umgesetzt im Auftrag der Winterthur Medien AG. Technologien: Frontend, Website, Medien Eigentümer: - Nobias Media SA, Luxembourg — parent of Jakota Capital AG, the entity that traded as Winterthur Medien AG Umfeld: - Winterthur Medien AG — described itself in its own footer as “a Nobias Media company” Verwandte Projekte: winterthur-medien, youngtimers, paddle8 Hinweis: nobias.media löst nicht mehr auf. Dieser Eintrag verweist auf eine Archivkopie; aus der Mandatszeit Oktober/November 2022 existiert keine Aufnahme, die archivierte Seite ist daher jünger. ## Garage Italia — NFT-Collection Zeitraum: September – Oktober 2022 Rolle: Blockchain Developer Auftragsverhältnis: im Auftrag der Winterthur Medien AG Archivierte Fassung: https://web.archive.org/web/20221103170649/https://gic.xyz/ NFT-Collection für Garage Italia, gestaltet vom Garage Italia Studio. Technische Umsetzung von Contracts und Mint-Prozess. Technologien: Solidity, NFT, EVM Eigentümer: - Garage Italia — founded by Lapo Elkann (Agnelli family; his brother John Elkann chairs EXOR) - Youngtimers AG, chaired by Sergey Skaterschikov — acquired Garage Italia in July 2021 - Lapo Elkann became the largest Youngtimers AG shareholder at 23.04% through L Holding; Clive Ng held the same 23.04% Umfeld: - IndexAtlas AG, Basel — Skaterschikov's holding vehicle, in liquidation since 2025 - L Holding S.r.l. — Elkann's vehicle, listed among Youngtimers AG shareholders Verwandte Projekte: youngtimers, paddle8, winterthur-medien Hinweis: Elkann trat im Oktober 2021 als Chairman von Garage Italia zurück, drei Monate nach dem Verkauf, unter Verweis auf Differenzen mit den neuen Eigentümern; Youngtimers AG stieg 2022 wieder aus. Die NFT-Kollektion auf gic.xyz entstand im September/Oktober 2022, also nach diesem Ausstieg. gic.xyz ist heute eine Parkseite — das LinkedIn-Profil verlinkt sie weiterhin, als wäre sie aktiv. ## Winterthur Medien AG — Website Zeitraum: Juli – August 2022 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Winterthur Medien AG Archivierte Fassung: https://web.archive.org/web/20240420233141/https://winterthur-medien.ch/ Website der Winterthur Medien AG — der Auftraggeberin, über die mehrere der übrigen Mandate dieser Zeit liefen. Technologien: Frontend, Website Eigentümer: - Winterthur Medien AG and Jakota Capital AG (Winterthur, UID CHE-450.591.835) are the same legal entity under successive names: The Skate AG → Youngtimers Sports → Winterthur Medien → Jakota Capital - Parent: Nobias Media SA, Luxembourg - Management: Ariane Gschwind - Acquired in March 2025 by Kingkey Financial Holdings, Hong Kong Umfeld: - Alti Wine Exchange - Alvernia Planet - Digital Domain - Garage Italia - Gremi Media - Moonkey - Petrolicious - Youngtimers AG Verwandte Projekte: youngtimers, paddle8, garage-italia-nft, no-bias-media, phygify Hinweis: Die acht auf der Website gezeigten Partner sind die Beteiligungen der Youngtimers AG, keine unabhängigen Kunden der Agentur. Die Winterthur Medien AG ist auch bei Paddle8, Phygify, No Bias Media und Youngtimers das Auftragsverhältnis — diese fünf Mandate haben also dieselbe Gegenpartei unter verschiedenen Markennamen. ## Youngtimers AG — Investor Relations Zeitraum: Juni – Juli 2022 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Winterthur Medien AG Archivierte Fassung: https://web.archive.org/web/20220705221951/https://ir.youngtimers.com/ Investor-Relations-Website für die börsenkotierte Schweizer Beteiligungsgesellschaft Youngtimers AG: Ad-hoc-Meldungen, Finanzberichte, Beteiligungen und Organe, gespeist aus einer bestehenden WordPress-REST-API. - Ad-hoc-Publizität und Finanzberichte aus der bestehenden WordPress-REST-API von ir.youngtimers.com übernommen, statt die Redaktion auf ein zweites System umzustellen - Rund 40 regulatorische PDF-Dokumente — Jahres- und Halbjahresberichte, GV-Einladungen, Meldungen zu Beteiligungsveränderungen — als eigener Dokumentenbereich erschlossen - Storyblok-Blöcke für Aktien, Anleihen, Aktionariat, Verwaltungsrat und Beteiligungen, damit die IR-Seite ohne Entwickler aktuell gehalten werden kann Technologien: Nuxt, Storyblok, Frontend, Investor Relations Eigentümer: - Youngtimers AG — börsenkotierte Schweizer Beteiligungsgesellschaft, Chairman und Investor Sergey Skaterschikov - Später umbenannt in Jakota Capital AG; die Tickerhistorie der regulatorischen Dokumente läuft von NTIV auf YTME - Grössere Aktionäre zur Mandatszeit: Lapo Elkann über L Holding mit 23,04 %, Clive Ng mit ebenfalls 23,04 %, Adrian Cheng mit 10 %, dazu IndexAtlas AG (Basel) und Digital Knight Finance S.à r.l. Umfeld: - Beteiligungen laut der eigenen Publikation: ASBIS, Facebank (Ausstieg 2019), Pininfarina (2021), Alti Exchange (2022), Petrolicious (2022), Garage Italia (2022), Talenthouse (2023), Gremi Media (2023) - Winterthur Medien AG — Umsetzungspartner und selbst Teil derselben Firmenkette - C Capital Group — 2024 von Youngtimers AG übernommen Verwandte Projekte: winterthur-medien, garage-italia-nft, paddle8, phygify, no-bias-media Hinweis: Dieselbe Gruppe steht hinter fünf weiteren Einträgen dieser Liste. Die acht Partnerlogos auf der Website der Winterthur Medien AG sind genau die Beteiligungen dieser Holding. ir.youngtimers.com ist nicht mehr erreichbar; verlinkt ist eine Aufnahme vom 5. Juli 2022, also aus der Mandatszeit. ## PHYGIFY — Multichain-NFT-Plattform Zeitraum: Februar 2022 – August 2023 Rolle: Chief Blockchain Developer Auftragsverhältnis: im Auftrag der Winterthur Medien AG Archivierte Fassung: https://web.archive.org/web/20220323101616/http://phygify.com/ Die erste Multichain-Plattform zur Monetarisierung von NFTs. Als Chief Blockchain Developer verantwortlich für Smart Contracts, Chain-Anbindung und technische Architektur. - Technische Gesamtverantwortung für den Blockchain-Teil der Plattform - Smart Contracts in Solidity, entwickelt und getestet mit Hardhat, deployed über ethers.js - Anbindung mehrerer EVM-Chains an eine gemeinsame Anwendung Technologien: Solidity, Hardhat, ethers.js, NFT, Multichain Eigentümer: - Phygify — founded 2021, seat in Zurich, a platform for “phygital” collectibles (physical item plus NFT) - Part of the Skaterschikov / Youngtimers orbit; the company is recorded as deadpooled Umfeld: - Winterthur Medien AG — the delivery route for this engagement - Youngtimers AG — the collectible-car holding the phygital thesis was built around Verwandte Projekte: winterthur-medien, youngtimers, garage-italia-nft, paddle8 Hinweis: phygify.com antwortet zwar noch, zeigt aber eine Parkseite — dieser Eintrag verweist deshalb auf eine Aufnahme vom März 2022 aus der Mandatszeit. ## The Detective's Guild Zeitraum: Februar 2022 – März 2023 Rolle: Konzept, Smart Contracts, Frontend und Backend Auftragsverhältnis: Eigenes Projekt Archivierte Fassung: https://web.archive.org/web/20220928165549/https://thedetectivesguild.com/ Web3-Plattform auf Avalanche für Community-Bewertungen von Krypto-Projekten und bezahlte Recherche-Aufträge: Wer eine Untersuchung will, hinterlegt die Prämie im Smart Contract, wer sie liefert, wird daraus bezahlt. - Escrow-Vertrag PrivateEyes.sol in Solidity 0.8.13 auf der Avalanche C-Chain, mit Rollenverwaltung über OpenZeppelin AccessControl und 1 % Plattformgebühr - Prämien wahlweise in nativem AVAX oder in ERC-20-Token, inklusive USDC - Bewertungs- und Kommentarsystem mit Red-Flag-Metriken und einem Know-Your-Developer-Verfahren - Nuxt-3-Frontend mit ethers.js und WalletConnect, Strapi-4-Backend auf PostgreSQL, Governance über Snapshot Technologien: Solidity, Avalanche, Nuxt, Strapi, Web3 Eigentümer: - Rugpull Prevention — die Community-Marke, unter der die Plattform lief; The Detective's Guild war deren Produktarm Umfeld: - Avalanche C-Chain (Chain-ID 43114) für den produktiven Betrieb, Fuji-Testnetz (43113) für Vorabversionen - Snapshot Labs — Off-Chain-Abstimmungen - Umfeld auf Twitter/X als AvaxDyor, dazu Telegram- und Discord-Kanäle Verwandte Projekte: decentralex, moonmug, flashy-chat Hinweis: thedetectivesguild.com löst nicht mehr auf; verlinkt ist eine Aufnahme vom 28. September 2022 — einen Tag vor dem Mainnet-Deployment des Escrow-Vertrags. Die Verträge selbst bleiben on-chain nachprüfbar: Listing-Vertrag 0xf08bf9A09f4a7B34dd253e3796CF560Bc32C245b auf der Avalanche C-Chain. ## MoonMug Zeitraum: November 2021 – März 2022 Rolle: Konzept und Umsetzung Auftragsverhältnis: Eigenes Projekt NFT-Projekt mit eigener Illustrationswelt, von der Konzeption bis zur Umsetzung. Technologien: NFT, Web3, Frontend ## Arcondis — Website Zeitraum: September – Oktober 2020 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.arcondis.com Website für die Beratungsgruppe Arcondis, die auf Life Sciences und Gesundheitswesen spezialisiert ist. Technologien: Frontend, Website, Life Sciences ## BakerHicks — Redesign Zeitraum: Februar 2020 Rolle: Frontend-Support Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.bakerhicks.com Frontend-Support beim Redesign des Webauftritts von BakerHicks, einem Planungs- und Engineeringbüro. Technologien: Frontend, Redesign, Engineering ## Swiss Digital Initiative Zeitraum: Januar 2020 Rolle: Frontend-Support Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Archivierte Fassung: https://web.archive.org/web/20200812151939/https://www.swiss-digital-initiative.org/ Frontend-Support für die Swiss Digital Initiative, eine Genfer Stiftung für ethische Standards in der Digitalisierung. Technologien: Frontend, Website, Stiftung ## Basler Kantonalbank — interne App Zeitraum: Dezember 2019 – Februar 2020 Rolle: Frontend Developer Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.bkb.ch Interne Applikation für die Basler Kantonalbank. Frontend-Entwicklung unter den Sicherheits- und Freigabeanforderungen einer Schweizer Kantonalbank. Technologien: Vue.js, Interne App, Finanzwesen ## Sympany — Chatbot-Styling Zeitraum: Ende 2019 Rolle: Frontend Developer Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.sympany.ch Styling und Frontend-Anpassung des Kunden-Chatbots für den Schweizer Krankenversicherer Sympany, umgesetzt auf der Chatbot-Plattform von aiaibot. - Anpassung des Chatbot-Erscheinungsbilds an das Corporate Design von Sympany - Umsetzung auf der Chatbot-Plattform von aiaibot Technologien: Frontend, CSS, Chatbot, Corporate Design ## Integra Biosciences — Applikationsbereich Zeitraum: Oktober – November 2019 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.integra-biosciences.com Applikationsbereich im Webauftritt von Integra Biosciences, einem Hersteller von Laborinstrumenten. Technologien: Frontend, Website, Laborinstrumente ## CVP — Website-Redesign Zeitraum: Juli – August 2019 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://die-mitte.ch Archivierte Fassung: https://web.archive.org/web/20190202072859/https://www.cvp.ch/ Redesign des Webauftritts der CVP Schweiz. Die Partei trägt seit 2021 den Namen Die Mitte; das Mandat lief unter dem damaligen Namen. Technologien: Frontend, Redesign, Politik ## Leap Partners Zeitraum: Mai – Juni 2019 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.leap-partners.com Webauftritt für Leap Partners, umgesetzt im Auftrag der Digitalagentur WONDROUS. Technologien: Frontend, Website ## Daimler — Leadership-Apps Zeitraum: Dezember 2018 – Dezember 2019 Rolle: Frontend Developer Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://group.mercedes-benz.com Zwei interne Führungskräfte-Anwendungen für die Daimler AG: die Leadership 2020 App und der Leadership 20X Compass. Frontend-Entwicklung für den internen Einsatz in einem Grosskonzern. - Leadership 2020 App (Dez. 2018 – Mai 2019) - Leadership 20X Compass App (Nov. – Dez. 2019) Technologien: Vue.js, Interne App, Designsystem ## Roche — ForPatients, Medinfo & IEEPO Zeitraum: Februar 2018 – September 2021 Rolle: Frontend Developer Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.roche.com Vier Plattformprojekte für Roche über vier Jahre: die Patientenplattform ForPatients, zwei Generationen des Medinfo-Portals und die IEEPO-Plattform 2021. Frontend-Entwicklung auf Enterprise-Niveau im regulierten Pharma-Umfeld. - ForPatients Platform (2018) — Patientenplattform - Medinfo V3 (2020) und Medinfo V4 (2021) — zwei Generationen des Medizininformations-Portals - IEEPO 2021 (Dez. 2020 – Juni 2021) - Vue.js und Nuxt mit serverseitigem Rendering, CMS-Anbindung über Drupal und Storyblok Technologien: Vue.js, Nuxt, Drupal, Storyblok, Pharma ## Decentralex Zeitraum: Dezember 2017 – September 2018 Rolle: Konzept und Frontend Auftragsverhältnis: Eigenes Projekt Archivierte Fassung: https://web.archive.org/web/20180806090510/http://decentralex.com/ Frühes Blockchain-Projekt aus der Zeit vor dem Schwerpunkt auf Smart Contracts. Technologien: Blockchain, Frontend ## Hudson Group Investors — Website Zeitraum: Oktober – Dezember 2017 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Webauftritt für Hudson Group Investors, umgesetzt im Auftrag der Digitalagentur WONDROUS. Technologien: Frontend, Website, Investment ## MTIP AG — Website Zeitraum: Januar – April 2017 Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.mtip.ch Webauftritt für MTIP, einen Schweizer Investor im Bereich Health Technology. Technologien: Frontend, Website, Health Tech ## Novartis, Sandoz & Alcon Zeitraum: Januar 2017 – Juli 2019 Rolle: Frontend Developer, UX-Support Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.novartis.com Über zwei Jahre Design-, UX- und Frontend-Support für Novartis International AG sowie die Konzerngesellschaften Sandoz und Alcon — inklusive Aufbau wiederverwendbarer Designsysteme und Styleguides. Dazu die PathAI-Landingpage für Novartis. - Design, UX und Frontend-Support für Novartis, Sandoz und Alcon (2017–2019) - PathAI Landingpage für Novartis (Jan. – März 2018) - Entwicklung von Styleguides und wiederverwendbaren Designsystemen Technologien: Vue.js, Designsystem, Styleguide, Pharma ## DigitalBasel Zeitraum: im Rahmen der WONDROUS-Zusammenarbeit Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Archivierte Fassung: https://web.archive.org/web/20200923025849/http://www.digitalbasel.ch/ Webauftritt für DigitalBasel. Der Zeitraum ist in den Projektunterlagen nicht festgehalten. Technologien: Frontend, Website, Basel ## Morgan Sindall Professional Services — Website Zeitraum: im Rahmen der WONDROUS-Zusammenarbeit Rolle: Frontend-Deployment Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Website: https://www.morgansindall.com Webauftritt für Morgan Sindall Professional Services. Der Zeitraum ist in den Projektunterlagen nicht festgehalten. Technologien: Frontend, Website, Engineering ## Simplexity Group — Eisenhower-App Zeitraum: im Rahmen der WONDROUS-Zusammenarbeit Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Anwendung zur Aufgabenpriorisierung nach der Eisenhower-Matrix. Der Zeitraum ist in den Projektunterlagen nicht festgehalten. Technologien: Frontend, App, Produktivität ## WONDROUS — Website Zeitraum: im Rahmen der WONDROUS-Zusammenarbeit Rolle: Frontend-Entwicklung Auftragsverhältnis: im Auftrag der Digitalagentur WONDROUS Archivierte Fassung: https://web.archive.org/web/20190718142602/https://www.wearewondrous.com/ Webauftritt der Digitalagentur, über die die meisten Grosskundenmandate dieser Jahre liefen. Der Zeitraum ist in den Projektunterlagen nicht festgehalten. Technologien: Frontend, Website, Agentur # Projects — full reference Every documented reference project with how it was delivered, its links, and background on owners and surrounding companies. The delivery relationship (via) belongs to each project: the enterprise names ran through agencies, not as direct mandates. ## Flashy.chat — on-chain messaging Period: since March 2026 Role: Concept, smart contracts and frontend Delivered: Own product Website: https://flashy.chat A decentralised messaging platform on Ethereum and Base where every message is a permanent on-chain transaction. With Morpho flash loan integration and permanent image messaging via IPFS. - Every message is a permanent transaction on Ethereum or Base — no database, no server that could delete it - Morpho flash loan integration: each message addresses roughly USD 5.3B of available flash loan liquidity (2.7B on Ethereum, 2.6B on Base) - Permanent image messaging via IPFS instead of centralised file storage - Around 1,400 on-chain transactions settled so far Technologies: Solidity, Ethereum, Base, Flash Loans, IPFS, Nuxt ## FairTransform Period: since August 2025 Role: Technical delivery Delivered: Own project Website: https://fairtransform.ch A platform for the fair and sustainable transformation of the economy and society. Concept and technical delivery. Technologies: Nuxt, TypeScript, Tailwind CSS ## Consulting Suisse Period: since June 2025 Role: Concept and delivery Delivered: Own project Website: https://consultingsuisse.ch Web presence for advisory services around company formation, finance and administration in Switzerland. Technologies: Nuxt, TypeScript, SEO ## Open source: muse.js, freqgen, exquis-midi & mindpeeker-sdk Period: ongoing Role: Author and maintainer Delivered: Own work Website: https://github.com/orgs/Polobase/repositories Four open-source TypeScript libraries I maintain under the Polobase GitHub organisation — all MIT licensed and publicly inspectable. Three of them drive real hardware; the fourth pairs randomness engineering with statistical analysis. - muse.js — TypeScript library for Muse EEG headbands with first-class Muse S Athena support; decodes the DRL/REF pair no other library reads - freqgen — TypeScript drivers for USB-serial signal/frequency generators (FeelTech FY, JUNTEK, Koolertron, Spooky2) behind one vendor-neutral interface, in Node and the browser; grown out of feeltech - exquis-midi — full control of the Intuitive Instruments Exquis MPE controller (LEDs, input, microtonal layouts) over its official Developer Mode MIDI API, in Node and in the browser - mindpeeker-sdk — zero-dependency TypeScript/Bun SDK: randomness engineering to NIST SP 800-90B with extractors and VDFs, paired with statistical analysis methods - All four open source under an MIT licence and publicly verifiable; muse.js and mindpeeker-sdk ship a browser playground Technologies: TypeScript, npm, Bun, Open source ## Paddle8 Period: June 2023 Role: Frontend development Delivered: on behalf of Winterthur Medien AG Archived version: https://web.archive.org/web/20230603020728/https://paddle8.com/ Short engagement for the online auction house Paddle8, delivered through the collaboration with Winterthur Medien AG. Technologies: Frontend, Website, Auctions Owners: - P8H Inc., New York — the legal entity behind Paddle8, founded May 2011 by Alexander Gilkes (a former LVMH executive and chief auctioneer at Phillips), Aditya Julka (Harvard Business School Baker Scholar) and Osman Khan (Goldman Sachs, Perella Weinberg; Harvard MBA) - May 2016 – February 2017: merged with the Berlin auction platform Auctionata; Thomas Hesse appointed CEO of the combined company in September 2016. Auctionata declared insolvency in February 2017 and Paddle8 became independent again - February 2017: backed by Lightyear Collective, a multi-family office incorporated in Delaware in January 2017 whose members were not disclosed, but are known to include Christopher Hsu of Kilometre Capital Management, Hong Kong - December 2017: P8H Inc. taken over by a syndicate of Swiss investors, who installed Izabela Depczyk as interim CEO and change manager - January 2018: The Native SA, Lausanne (SIX: NTIV), chaired by Sergey Skaterschikov, bought 15% for USD 8.8m with an option on a further 36% for about USD 25.6m. The Native SA also held 51% of asknet AG and 100% of Blockchain Lab AG - August 2019: Pulse Evolution Group Inc. acquired Facebank AG of Switzerland and renamed itself Facebank Group Inc., becoming the largest shareholder of P8H Inc. through that holding. Valentine Uhovski appointed CEO in November 2019 Partners: - Founder Collective and Mousse Partners — led the USD 4m Series A. Mousse Partners is the family office of Alain and Gérard Wertheimer, the owners of Chanel, founded 1991 by Charles Heilbronn; it is not an Agnelli vehicle, a misattribution that circulates in secondary sources - June 2013, USD 6m: Damien Hirst, Prince Alexander von Fürstenberg, the Russian mogul Vladimir Yevtushenkov, Matthew Mellon, and Jay Jopling of White Cube - October 2015, USD 34m Series C: David Zwirner (who joined the board), Rolf Sachs, Eric Fellner of Working Title Films, Edgar Berger of Sony Music Entertainment International, with Mousse Partners, Damien Hirst, Jay Jopling and Stavros Niarchos following on. USD 44m raised in total by that point - Cameron and Tyler Winklevoss — advisers on the 2018 plans for blockchain-settled auctions - Over 300 non-profit institutions, from LACMA to the Guggenheim and the Brooklyn Academy of Music, whose benefit auctions ran on the platform Related projects: garage-italia-nft, winterthur-medien, youngtimers, phygify Note: Two threads of this cap table meet elsewhere in this list. Vladimir Yevtushenkov, an investor in the 2013 round, controls Sistema, whose MTS Group employed Sergey Skaterschikov as VP M&A in 2006–2008; Skaterschikov went on to chair The Native SA, which bought into Paddle8 in 2018. Separately, Mousse Partners was reported in February 2023 as one of the investors taking Rothschild & Co private. Paddle8 filed for Chapter 11 in the Southern District of New York in March 2020, a week after the New American Cinema Group sued it over allegedly misappropriated charity-auction funds; listed creditors included Justin and Hailey Bieber (about USD 73,000) and Jay-Z's Shawn Carter Foundation (about USD 65,000). The June 2023 engagement therefore fell well after the insolvency, under Winterthur Medien AG. paddle8.com still resolves but serves a parking page, which is why this entry links a dated capture instead. ## No Bias Media Period: October – November 2022 Role: Frontend development Delivered: on behalf of Winterthur Medien AG Archived version: https://web.archive.org/web/20241008080602/https://www.nobias.media/ Website for No Bias Media, delivered on behalf of Winterthur Medien AG. Technologies: Frontend, Website, Media Owners: - Nobias Media SA, Luxembourg — parent of Jakota Capital AG, the entity that traded as Winterthur Medien AG Partners: - Winterthur Medien AG — described itself in its own footer as “a Nobias Media company” Related projects: winterthur-medien, youngtimers, paddle8 Note: nobias.media no longer resolves. This entry is linked to a Wayback capture; no capture exists from the October–November 2022 engagement itself, so the archived page is a later one. ## Garage Italia — NFT collection Period: September – October 2022 Role: Blockchain Developer Delivered: on behalf of Winterthur Medien AG Archived version: https://web.archive.org/web/20221103170649/https://gic.xyz/ NFT collection for Garage Italia, designed by Garage Italia Studio. Technical delivery of contracts and the mint process. Technologies: Solidity, NFT, EVM Owners: - Garage Italia — founded by Lapo Elkann (Agnelli family; his brother John Elkann chairs EXOR) - Youngtimers AG, chaired by Sergey Skaterschikov — acquired Garage Italia in July 2021 - Lapo Elkann became the largest Youngtimers AG shareholder at 23.04% through L Holding; Clive Ng held the same 23.04% Partners: - IndexAtlas AG, Basel — Skaterschikov's holding vehicle, in liquidation since 2025 - L Holding S.r.l. — Elkann's vehicle, listed among Youngtimers AG shareholders Related projects: youngtimers, paddle8, winterthur-medien Note: Elkann resigned as chairman of Garage Italia in October 2021, three months after the sale, citing differences with the new owners; Youngtimers AG exited the holding in 2022. The NFT collection at gic.xyz was built in September–October 2022, after that exit. gic.xyz is now a parking page — the LinkedIn profile still links it as if it were live. ## Winterthur Medien AG — website Period: July – August 2022 Role: Frontend development Delivered: on behalf of Winterthur Medien AG Archived version: https://web.archive.org/web/20240420233141/https://winterthur-medien.ch/ Website for Winterthur Medien AG — the client through which several of the other engagements from this period ran. Technologies: Frontend, Website Owners: - Winterthur Medien AG and Jakota Capital AG (Winterthur, UID CHE-450.591.835) are the same legal entity under successive names: The Skate AG → Youngtimers Sports → Winterthur Medien → Jakota Capital - Parent: Nobias Media SA, Luxembourg - Management: Ariane Gschwind - Acquired in March 2025 by Kingkey Financial Holdings, Hong Kong Partners: - Alti Wine Exchange - Alvernia Planet - Digital Domain - Garage Italia - Gremi Media - Moonkey - Petrolicious - Youngtimers AG Related projects: youngtimers, paddle8, garage-italia-nft, no-bias-media, phygify Note: The eight partners shown on the site are the portfolio companies of Youngtimers AG, not independent clients of the agency. Winterthur Medien AG is the `via` on Paddle8, Phygify, No Bias Media and Youngtimers as well as on this entry, so those five engagements share one counterparty under different brand names. ## Youngtimers AG — investor relations Period: June – July 2022 Role: Frontend development Delivered: on behalf of Winterthur Medien AG Archived version: https://web.archive.org/web/20220705221951/https://ir.youngtimers.com/ Investor relations website for Youngtimers AG, a listed Swiss investment holding: ad-hoc announcements, financial reports, portfolio companies and officers, fed from an existing WordPress REST API. - Ad-hoc disclosures and financial reports taken from the existing WordPress REST API at ir.youngtimers.com, rather than moving the editorial team onto a second system - Around 40 regulatory PDFs — annual and half-year reports, AGM notices, shareholding change disclosures — opened up as their own document section - Storyblok blocks for shares, bonds, shareholders, directors and portfolio companies, so the IR site could be kept current without a developer Technologies: Nuxt, Storyblok, Frontend, Investor relations Owners: - Youngtimers AG — listed Swiss investment holding, chaired by and invested in by Sergey Skaterschikov - Later renamed Jakota Capital AG; the ticker history across the regulatory documents runs from NTIV to YTME - Larger shareholders at the time of the engagement: Lapo Elkann through L Holding at 23.04%, Clive Ng at the same 23.04%, Adrian Cheng at 10%, alongside IndexAtlas AG (Basel) and Digital Knight Finance S.à r.l. Partners: - Portfolio companies per its own disclosures: ASBIS, Facebank (exited 2019), Pininfarina (2021), Alti Exchange (2022), Petrolicious (2022), Garage Italia (2022), Talenthouse (2023), Gremi Media (2023) - Winterthur Medien AG — the delivery partner, and itself part of the same chain of companies - C Capital Group — acquired by Youngtimers AG in 2024 Related projects: winterthur-medien, garage-italia-nft, paddle8, phygify, no-bias-media Note: The same group sits behind five other entries in this list. The eight partner logos on the Winterthur Medien AG site are exactly this holding's portfolio companies. ir.youngtimers.com no longer resolves; the link is a capture from 5 July 2022, inside the engagement. ## PHYGIFY — multichain NFT platform Period: February 2022 – August 2023 Role: Chief Blockchain Developer Delivered: on behalf of Winterthur Medien AG Archived version: https://web.archive.org/web/20220323101616/http://phygify.com/ The first multichain platform for monetising NFTs. As Chief Blockchain Developer, responsible for smart contracts, chain integration and technical architecture. - Overall technical ownership of the platform's blockchain layer - Smart contracts in Solidity, developed and tested with Hardhat, deployed via ethers.js - Integration of several EVM chains into a single application Technologies: Solidity, Hardhat, ethers.js, NFT, Multichain Owners: - Phygify — founded 2021, seat in Zurich, a platform for “phygital” collectibles (physical item plus NFT) - Part of the Skaterschikov / Youngtimers orbit; the company is recorded as deadpooled Partners: - Winterthur Medien AG — the delivery route for this engagement - Youngtimers AG — the collectible-car holding the phygital thesis was built around Related projects: winterthur-medien, youngtimers, garage-italia-nft, paddle8 Note: phygify.com still answers but serves a parking page, so this entry links a March 2022 capture from inside the engagement instead. ## The Detective's Guild Period: February 2022 – March 2023 Role: Concept, smart contracts, frontend and backend Delivered: Own project Archived version: https://web.archive.org/web/20220928165549/https://thedetectivesguild.com/ Web3 platform on Avalanche for community reviews of crypto projects and paid investigation bounties: whoever wants an investigation locks the reward in the smart contract, whoever delivers it gets paid out of that. - PrivateEyes.sol escrow contract in Solidity 0.8.13 on the Avalanche C-Chain, with role management through OpenZeppelin AccessControl and a 1% platform fee - Rewards payable in native AVAX or in ERC-20 tokens, including USDC - Rating and comment system with red-flag metrics and a know-your-developer process - Nuxt 3 frontend with ethers.js and WalletConnect, Strapi 4 backend on PostgreSQL, governance through Snapshot Technologies: Solidity, Avalanche, Nuxt, Strapi, Web3 Owners: - Rugpull Prevention — the community brand the platform ran under; The Detective's Guild was its product arm Partners: - Avalanche C-Chain (chain ID 43114) in production, Fuji testnet (43113) for preview builds - Snapshot Labs — off-chain voting - Surrounding community on Twitter/X as AvaxDyor, plus Telegram and Discord channels Related projects: decentralex, moonmug, flashy-chat Note: thedetectivesguild.com no longer resolves; the link is a capture from 28 September 2022, the day before the escrow contract went to mainnet. The contracts themselves stay checkable on-chain: listing contract 0xf08bf9A09f4a7B34dd253e3796CF560Bc32C245b on the Avalanche C-Chain. ## MoonMug Period: November 2021 – March 2022 Role: Concept and build Delivered: Own project NFT project with its own illustrated world, from concept through to build. Technologies: NFT, Web3, Frontend ## Arcondis — website Period: September – October 2020 Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Website: https://www.arcondis.com Website for Arcondis, a consulting group specialising in life sciences and healthcare. Technologies: Frontend, Website, Life sciences ## BakerHicks — redesign Period: February 2020 Role: Frontend support Delivered: on behalf of the digital agency WONDROUS Website: https://www.bakerhicks.com Frontend support on the website redesign for BakerHicks, a design and engineering consultancy. Technologies: Frontend, Redesign, Engineering ## Swiss Digital Initiative Period: January 2020 Role: Frontend support Delivered: on behalf of the digital agency WONDROUS Archived version: https://web.archive.org/web/20200812151939/https://www.swiss-digital-initiative.org/ Frontend support for the Swiss Digital Initiative, a Geneva foundation for ethical standards in digitalisation. Technologies: Frontend, Website, Foundation ## Basler Kantonalbank — internal app Period: December 2019 – February 2020 Role: Frontend Developer Delivered: on behalf of the digital agency WONDROUS Website: https://www.bkb.ch Internal application for Basler Kantonalbank. Frontend engineering under the security and approval requirements of a Swiss cantonal bank. Technologies: Vue.js, Internal app, Finance ## Sympany — chatbot styling Period: late 2019 Role: Frontend Developer Delivered: on behalf of the digital agency WONDROUS Website: https://www.sympany.ch Styling and frontend adaptation of the customer chatbot for the Swiss health insurer Sympany, delivered on the aiaibot chatbot platform. - Adapted the chatbot's appearance to Sympany's corporate design - Delivered on the aiaibot chatbot platform Technologies: Frontend, CSS, Chatbot, Corporate design ## Integra Biosciences — application section Period: October – November 2019 Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Website: https://www.integra-biosciences.com Application section of the website for Integra Biosciences, a manufacturer of laboratory instruments. Technologies: Frontend, Website, Lab instruments ## CVP — website redesign Period: July – August 2019 Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Website: https://die-mitte.ch Archived version: https://web.archive.org/web/20190202072859/https://www.cvp.ch/ Website redesign for the Swiss CVP. The party has been called Die Mitte since 2021; the engagement ran under the name it had at the time. Technologies: Frontend, Redesign, Politics ## Leap Partners Period: May – June 2019 Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Website: https://www.leap-partners.com Website for Leap Partners, delivered on behalf of the digital agency WONDROUS. Technologies: Frontend, Website ## Daimler — leadership apps Period: December 2018 – December 2019 Role: Frontend Developer Delivered: on behalf of the digital agency WONDROUS Website: https://group.mercedes-benz.com Two internal leadership applications for Daimler AG: the Leadership 2020 app and the Leadership 20X Compass. Frontend engineering for internal use inside a large corporate group. - Leadership 2020 App (Dec 2018 – May 2019) - Leadership 20X Compass App (Nov – Dec 2019) Technologies: Vue.js, Internal app, Design system ## Roche — ForPatients, Medinfo & IEEPO Period: February 2018 – September 2021 Role: Frontend Developer Delivered: on behalf of the digital agency WONDROUS Website: https://www.roche.com Four platform projects for Roche across four years: the ForPatients patient platform, two generations of the Medinfo portal, and the IEEPO 2021 platform. Enterprise-grade frontend engineering in a regulated pharmaceutical environment. - ForPatients Platform (2018) — patient-facing platform - Medinfo V3 (2020) and Medinfo V4 (2021) — two generations of the medical information portal - IEEPO 2021 (Dec 2020 – June 2021) - Vue.js and Nuxt with server-side rendering, CMS integration via Drupal and Storyblok Technologies: Vue.js, Nuxt, Drupal, Storyblok, Pharma ## Decentralex Period: December 2017 – September 2018 Role: Concept and frontend Delivered: Own project Archived version: https://web.archive.org/web/20180806090510/http://decentralex.com/ An early blockchain project, from before the focus shifted to smart contracts. Technologies: Blockchain, Frontend ## Hudson Group Investors — website Period: October – December 2017 Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Website for Hudson Group Investors, delivered on behalf of the digital agency WONDROUS. Technologies: Frontend, Website, Investment ## MTIP AG — website Period: January – April 2017 Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Website: https://www.mtip.ch Website for MTIP, a Swiss health technology investor. Technologies: Frontend, Website, Health tech ## Novartis, Sandoz & Alcon Period: January 2017 – July 2019 Role: Frontend Developer, UX support Delivered: on behalf of the digital agency WONDROUS Website: https://www.novartis.com More than two years of design, UX and frontend support for Novartis International AG and the group companies Sandoz and Alcon — including building reusable design systems and styleguides. Plus the PathAI landing page for Novartis. - Design, UX and frontend support for Novartis, Sandoz and Alcon (2017–2019) - PathAI landing page for Novartis (Jan – March 2018) - Development of styleguides and reusable design systems Technologies: Vue.js, Design system, Styleguide, Pharma ## DigitalBasel Period: part of the WONDROUS engagement Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Archived version: https://web.archive.org/web/20200923025849/http://www.digitalbasel.ch/ Website for DigitalBasel. The dates are not recorded in the project notes. Technologies: Frontend, Website, Basel ## Morgan Sindall Professional Services — website Period: part of the WONDROUS engagement Role: Frontend deployment Delivered: on behalf of the digital agency WONDROUS Website: https://www.morgansindall.com Website for Morgan Sindall Professional Services. The dates are not recorded in the project notes. Technologies: Frontend, Website, Engineering ## Simplexity Group — Eisenhower app Period: part of the WONDROUS engagement Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Task prioritisation application built on the Eisenhower matrix. The dates are not recorded in the project notes. Technologies: Frontend, App, Productivity ## WONDROUS — website Period: part of the WONDROUS engagement Role: Frontend development Delivered: on behalf of the digital agency WONDROUS Archived version: https://web.archive.org/web/20190718142602/https://www.wearewondrous.com/ Website for the digital agency through which most of the enterprise work of those years was delivered. The dates are not recorded in the project notes. Technologies: Frontend, Website, Agency # 100 KI-Automationen in Betrieben — 20 Branchen, je fünf konkrete Beispiele Die häufigste Frage in einem Erstgespräch zu KI lautet nicht „geht das?“, sondern „wo fange ich an?“. Und die häufigste Fehlannahme dahinter ist, dass ein KI-Projekt gross sein muss, um sich zu lohnen. Diese Liste ist die Gegenthese. Jeder der hundert Punkte richtet sich auf einen **wiederkehrenden Informationsprozess**: E-Mails, Anfragen, PDFs, Rapporte, Produktdaten, Fotos, Gespräche, interne Dokumente. Für einen ersten Schritt ist das fast immer besser geeignet als autonome Agenten, ein Systemwechsel oder eine KI, die verbindliche Fachentscheide trifft. ## Die Regel, nach der ein Pilot zugeschnitten wird ::flow-diagram --- steps: - label: Ein Eingang note: eine einzige Anfrageart, ein Dokumenttyp, eine Formularart — nicht „alle E-Mails“ tone: primary - label: Eine klare KI-Aufgabe note: strukturieren, zusammenfassen, Lücken finden, zuordnen — eine davon, nicht alle - label: Eine menschliche Prüfstufe note: eine benannte Person sieht das Ergebnis, bevor es weitergeht tone: primary branches: - label: Ohne diese Stufe kein Pilot note: Nicht aus Vorsicht, sondern weil hier gelernt wird, was das System systematisch falsch macht. tone: warn - label: Eine Ausgabe note: in das Werkzeug, mit dem ohnehin gearbeitet wird — CRM, Ticketsystem, Ordner, Tabelle tone: secondary caption: Klingt bescheiden und ist genau deshalb erfolgreich. Ein Pilot, der zwei Eingänge und drei Aufgaben gleichzeitig abdeckt, lässt sich nicht mehr beurteilen — wenn das Ergebnis schlecht ist, weiss niemand, an welcher Stelle. label: PILOTREGEL title: Ein Eingang, eine Aufgabe, eine Prüfung, eine Ausgabe --- :: Ein Beispiel in einem Satz: E-Mail-Anfrage kommt herein → die KI gliedert sie in Gewerk, Ort, Leistung, Dringlichkeit und fehlende Angaben → eine Mitarbeiterin prüft → ein Offertentwurf liegt im CRM. ## Fünf Muster, zwanzig Branchen So verschieden die Branchen unten aussehen: Praktisch jedes gute Einstiegsprojekt ist eine Ausprägung von einem dieser fünf Muster. ::compare-table --- columns: - label: Muster - label: Typischer Eingang - label: Aufgabe der KI - label: Menschliche Ausgabe rows: - - Anfrage-Copilot - E-Mail, Formular, Telefonnotiz, PDF - Thema, Felder, Dringlichkeit, fehlende Angaben und Zuständigkeit erkennen - Antwort-, Ticket- oder Offertentwurf prüfen - - Dokumenten-Copilot - PDF, Scan, Lieferantendokument, Rapport - Dokumenttyp, Kernfelder, Fristen, Lücken und Zusammenfassung extrahieren - Prüfliste, Aufgabe oder Datenentwurf freigeben - - Wissens-Copilot - Freigegebene interne Dateien - quellenbasiert suchen und mit Fundstelle antworten - Fachperson bewertet die Antwort und ergänzt die Wissensbasis - - Produkt- und Content-Copilot - Produktdaten, Assets, Datenblatt, Briefing - Datenlücken erkennen, Text- und Metadatenentwürfe erstellen - fachliche und markenseitige Freigabe - - Projekt- und Service-Copilot - Protokoll, Foto, Rapport, Ticket - Aufgaben, Status, Mängel und nächste Schritte strukturieren - verantwortliche Person steuert und schliesst den Vorgang ab caption: Wenn Sie unten eine Branche lesen, die nicht Ihre ist, lohnt sich der Blick trotzdem — die Muster übertragen sich, die Vokabeln ändern sich. label: MUSTER title: Die fünf Prozessarten, die sich fast überall wiederholen --- :: ## A. Branchen mit dem einfachsten Einstieg Viele digitale Informationen, klar wiederkehrende Abläufe, und der Nutzen ist für die Leitung sofort sichtbar. ### 1. Handwerk und Bau 1. **Anfragen strukturieren** — Eine Anfrage mit Fotos und E-Mail-Text wird in Gewerk, Ort, gewünschte Leistung, Dringlichkeit, fehlende Angaben und Zuständigkeit gegliedert. 2. **Offertvorbereitung** — Aus Anfrage, Besichtigungsnotiz und früheren Vorlagen entsteht eine interne Offert-Checkliste; der Fachverantwortliche ergänzt Preise und gibt frei. 3. **Rapporte auswerten** — Tages-, Bau- oder Servicerapporte werden aus Freitext und Fotos in Leistung, Material, Arbeitszeit, offene Punkte und nächsten Termin zerlegt. 4. **Mängel- und Aufgabentriage** — Eine Meldung mit Bild wird als Ticket zusammengefasst, nach Gewerk kategorisiert und einem Verantwortlichen vorgeschlagen. 5. **Kundenkommunikation vorbereiten** — Nach einem Einsatz entsteht ein Entwurf für eine verständliche Statusmail mit erledigten Arbeiten, offenen Punkten und nächstem Schritt. **Bester erster Schritt:** ein Anfrage-zu-Offerte-Copilot für eine einzige Anfrageart — etwa Sanitärreparatur oder Umbauofferte. ### 2. Technische Dienstleister, Elektro, HLKS und Wartung 1. **Störungsmeldungen klassifizieren** — E-Mails, Webformulare und Telefonnotizen werden nach Anlage, Fehlerbild, Standort, Dringlichkeit und nötigen Rückfragen strukturiert. 2. **Technische Dokumente finden** — Ein interner Assistent sucht in freigegebenen Handbüchern, Schemata und Wartungsanweisungen und zeigt die Fundstelle. 3. **Serviceeinsatz vorbereiten** — Aus Ticket und Anlagenhistorie entsteht eine Checkliste: Gerät, letzte Massnahmen, bekannte Fehler, mitzunehmendes Material. 4. **Arbeitsberichte standardisieren** — Der Techniker diktiert kurz, was er gemacht hat; daraus entsteht ein strukturierter Servicebericht zur Prüfung. 5. **Wartungsfälligkeiten vorbereiten** — Aus Wartungsverträgen und letzten Einsätzen entsteht eine Liste der anstehenden Kundenkontakte. **Bester erster Schritt:** Service-Triage und Rapport-Copilot für eine wiederkehrende Störungsmeldungsart. ### 3. Architektur-, Planungs- und Ingenieurbüros 1. **Sitzungsprotokolle in Aufgaben übersetzen** — Entscheide, Pendenzen, Verantwortliche und Fristen werden als Entwurf extrahiert. 2. **Projektunterlagen zusammenfassen** — Umfangreiche PDFs werden in Projektziel, Termine, Anforderungen, offene Fragen und relevante Anlagen gegliedert. 3. **Mängelberichte vorbereiten** — Fotos und Stichworte aus einer Begehung werden in nummerierte Mängelpunkte und eine nachvollziehbare Aufgabenliste überführt. 4. **Ausschreibungen vorprüfen** — Anforderungen, Abgabefristen, fehlende Informationen und Prüfpunkte werden sichtbar gemacht. 5. **Projektstatus kommunizieren** — Aus freigegebenen Projektinformationen entsteht ein Entwurf für eine Bauherrschafts- oder Teamstatusmeldung. **Bester erster Schritt:** ein Protokoll-zu-Pendenzen-Copilot mit Freigabe durch die Projektleitung. ### 4. Immobilienverwaltung und Facility Management 1. **Mieteranfragen routen** — Eine Meldung wird als Schaden, Reparaturwunsch, Vertragsfrage oder allgemeine Anfrage erkannt und zugeordnet. 2. **Schadenfälle strukturieren** — Ort, betroffene Einheit, Beschreibung, Bildanhänge, Dringlichkeit und mögliche Zuständigkeit werden herausgezogen. 3. **Handwerkeraufträge vorbereiten** — Aus einer geprüften Meldung entsteht ein klarer Auftrag mit Objekt, Problem, Zugangshinweisen und Anhängen. 4. **Objektdokumente durchsuchbar machen** — Hausordnungen, Protokolle und Übergabedokumente werden intern mit Quellenangabe durchsuchbar. 5. **Übergabeprotokolle vorbereiten** — Notizen und Fotos werden in eine strukturierte Checkliste bzw. einen Protokollentwurf überführt. **Bester erster Schritt:** Mieteranfrage- und Schadentriage für ein klar abgegrenztes Portfolio. ### 5. Handel und Grosshandel 1. **Produktdaten vervollständigen** — Lieferanten-PDFs werden nach technischen Daten, Einheiten, Varianten, Bildern und fehlenden Pflichtfeldern ausgewertet. 2. **Angebotsanfragen vorqualifizieren** — Eine B2B-Anfrage wird nach Produkt, Menge, Termin, Lieferort und fehlenden Angaben strukturiert. 3. **Kundenfragen vorbereiten** — Häufige Fragen zu Varianten, Verfügbarkeit oder Ersatzartikeln werden als Antwortentwurf mit Quellen vorbereitet. 4. **Lieferantendokumente prüfen** — Preislisten, Datenblätter und Neuheitenlisten werden in strukturierte Änderungslisten überführt. 5. **Mehrsprachigen Produktcontent vorbereiten** — Auf Basis freigegebener Fakten entstehen Entwürfe für Beschreibung, Kurzdaten, Metadaten und Übersetzungen. **Bester erster Schritt:** ein Produktdaten-Check für 20 bis 30 wichtige Artikel, mit Prüfung vor jeder Veröffentlichung. ### 6. E-Commerce und Onlinehandel 1. **Katalogqualität prüfen** — Fehlende Bilder, Attribute, Varianten, Beschreibungen, SEO-Felder oder widersprüchliche Angaben werden gemeldet. 2. **Support-Anfragen triagieren** — Bestell-, Versand-, Retouren- und Produktfragen werden erkannt, zusammengefasst und mit Bestellkontext weitergeleitet. 3. **Retourengründe analysieren** — Texte aus Rücksendungen werden gruppiert: Grösse, Qualität, falsche Erwartung, Transportschaden. 4. **Produktcontent variieren** — Aus bestätigten Produktfakten entstehen kanalpassende Kurztexte, Newsletter-Bausteine und Social-Entwürfe. 5. **Bewertungen auswerten** — Rezensionen werden in wiederkehrende positive Aspekte, Kritikpunkte und Verbesserungshinweise zusammengefasst. **Bester erster Schritt:** Support-Triage für drei häufige Anfragearten oder ein Katalogqualitäts-Check für eine Kategorie. ### 7. Professionelle Dienstleistungen und Beratung 1. **Neue Anfragen qualifizieren** — E-Mails und Kontaktformulare werden nach Thema, Team, Umfang, Dringlichkeit und fehlenden Angaben strukturiert. 2. **Offerten vorbereiten** — Aus Gesprächsnotizen, Leistungsbausteinen und Vorlagen entsteht eine Angebotsgliederung mit offenen Fragen. 3. **Projektwissen finden** — Vergangene Ergebnisse, Methoden, Checklisten und Vorlagen werden intern mit Quellen durchsuchbar. 4. **Sitzungsnachbereitung** — Entscheide, Aufgaben, Risiken und Kundenfragen werden aus Notizen herausgezogen. 5. **Berichtsentwürfe erstellen** — Freigegebene Projektdaten werden nach einer festen Vorlage strukturiert; der Berater verantwortet den Inhalt. **Bester erster Schritt:** ein Projektwissens- und Offert-Copilot für ein einzelnes Team. ### 8. Kreativ-, Marketing- und Digitalagenturen 1. **Briefings vereinheitlichen** — Unvollständige Kundenanfragen werden in Ziel, Zielgruppe, Kanal, Material, Deadline, Freigabe und offene Fragen überführt. 2. **Asset-Metadaten erstellen** — Bilder, Videos und Dokumente erhalten Tagvorschläge, Projektzuordnung, Verwendungszweck und Rechtehinweise zur Prüfung. 3. **Contentproduktion vorbereiten** — Aus freigegebenem Briefing und Markenregeln entstehen erste Varianten für Website, Newsletter, Social und Ads. 4. **Feedback bündeln** — Kommentare aus E-Mails, PDFs und Meetings werden nach Änderungswunsch, Verantwortlichkeit und Freigabestatus zusammengefasst. 5. **Kampagnenreporting zusammenfassen** — Plattformdaten und Teamnotizen werden in eine kundenverständliche Berichtsvorlage überführt. **Bester erster Schritt:** ein Briefing-zu-Content-Workflow für einen einzigen Kanal. ## B. Hoher Nutzen, etwas mehr Integrationsaufwand Der Nutzen ist gleich gross, aber die Systemlandschaft ist heterogener und die Anforderungen an Daten und Freigaben sind höher. ### 9. Produzierende Industrie und Zulieferer 1. **Technische Anfragen vorprüfen** — Ein Kunden-PDF wird nach Spezifikation, Stückzahl, Termin, Normen und fehlenden Angaben strukturiert. 2. **Technisches Wissen erschliessen** — Arbeitsanweisungen, Datenblätter und Handbücher werden intern durchsuchbar; Antworten zeigen die Fundstelle. 3. **Abweichungsberichte aufbereiten** — Qualitäts- und Fehlerberichte werden nach Produkt, Fehlerbild, Ursache, Massnahme und offenem Punkt gegliedert. 4. **Mehrsprachige Dokumentation vorbereiten** — Freigegebene technische Inhalte werden als Entwurf für weitere Sprachen und Formate vorbereitet. 5. **Lieferantenkommunikation strukturieren** — E-Mails zu Lieferverzug, Qualität oder Rückfragen werden zusammengefasst und in Aufgaben überführt. **Bester erster Schritt:** ein technischer Anfrage- und Dokumenten-Copilot für ein Produktsegment. ### 10. Maschinenservice, Anlagenbau und Ersatzteile 1. **Servicefälle einordnen** — Fehlerbeschreibung, Bild, Maschinentyp und Standort werden aus einer Anfrage herausgezogen und kategorisiert. 2. **Ersatzteilsuche vorbereiten** — Aus freigegebenen Teilelisten und Handbüchern entsteht eine Liste möglicher Teile samt Quellen. 3. **Technikerbriefings erstellen** — Maschinenhistorie, letzte Massnahmen, bekannte Fehler und offene Rückfragen werden vor dem Einsatz zusammengefasst. 4. **Serviceberichte strukturieren** — Freitext aus dem Feld wird in Fehlerbild, Diagnose, ausgeführte Arbeit, verwendete Teile und nächste Schritte gegliedert. 5. **Kundenberichte vorbereiten** — Nach fachlicher Prüfung entsteht ein verständlicher Bericht über Arbeiten, Beobachtungen und Empfehlungen. **Bester erster Schritt:** eine Service- und Ersatzteilanfrage-Triage mit technisch verantwortlicher Prüfung. ### 11. Transport, Logistik und Lager 1. **Transportanfragen extrahieren** — Abholort, Lieferort, Termin, Gewicht, Masse, besondere Anforderungen und fehlende Angaben werden aus E-Mails erkannt. 2. **Versanddokumente prüfen** — Lieferscheine, Frachtbriefe und Auftragsunterlagen werden auf Vollständigkeit und Abweichungen geprüft. 3. **Ausnahmen priorisieren** — Meldungen zu Verspätung, Schaden, Fehllieferung oder fehlenden Papieren werden kategorisiert und zugewiesen. 4. **Kundenstatus vorbereiten** — Aus zugelassenen Auftragsdaten entsteht ein prüfbarer Statusentwurf für die Kundenkommunikation. 5. **Lagerabweichungen zusammenfassen** — Notizen zu Fehlmengen, Beschädigung oder falscher Einlagerung werden geordnet und als Aufgabenliste vorbereitet. **Bester erster Schritt:** ein Transportanfrage- und Dokumenten-Check für eine standardisierte Sendungsart. ### 12. Treuhand, Buchhaltung und administrative Büros 1. **Dokumenteneingang triagieren** — Belege und Mandatsunterlagen werden nach Dokumenttyp, Mandat, Zeitraum und fehlenden Unterlagen strukturiert. 2. **Vollständigkeit prüfen** — Die Liste erwarteter Unterlagen wird mit den vorhandenen Dateien abgeglichen und als Rückfrageentwurf vorbereitet. 3. **Internes Wissen auffindbar machen** — Arbeitsanweisungen, Vorlagen und Checklisten werden quellenbasiert durchsuchbar. 4. **Mandatskommunikation vorbereiten** — Wiederkehrende, nicht fachentscheidende Rückfragen werden als Entwurf vorbereitet und geprüft. 5. **Fristen und Aufgaben extrahieren** — Aus E-Mails und Dokumenten werden Termine, fehlende Informationen und Wiedervorlagen als Aufgaben erkannt. **Bester erster Schritt:** eine Mandatsdokumenten-Triage für eine risikoarme Dokumentenklasse. > **Grenze:** Keine automatische Steuer-, Buchungs-, Zahlungs- oder Rechtsentscheidung. Die KI unterstützt Vorbereitung und Vollständigkeit; Fachpersonen prüfen und verantworten jede Entscheidung. ### 13. Druckereien, Verpackung und Publishing 1. **Auftragsbriefings auswerten** — Kundenmails und PDFs werden nach Format, Auflage, Papier, Farbe, Veredelung, Termin und offenen Fragen strukturiert. 2. **Offertanfragen vorbereiten** — Es entsteht eine Kalkulations-Checkliste, damit fehlende Produktionsangaben rasch auffallen. 3. **Produktionsübergabe standardisieren** — Freigegebene Auftragsdaten werden in einen klaren Job-Ticket-Entwurf überführt. 4. **Korrekturschleifen bündeln** — Kundenfeedback zu Layouts und Proofs wird nach Seite, Element und Änderungswunsch zusammengefasst. 5. **Leistungsbeschreibungen erstellen** — Aus echten Produktionsdaten entstehen Entwürfe für Servicebeschreibungen und Musterangebote. **Bester erster Schritt:** ein Anfrage-zu-Job-Ticket-Workflow für ein häufiges Produkt. ### 14. Food-Produktion und Lebensmittel-Grosshandel 1. **Lieferantendokumente erfassen** — Spezifikationen, Zutatenlisten, Zertifikate und Preislisten werden nach festem Schema vorbereitet. 2. **Produktdaten vervollständigen** — Verpackungsgrösse, Inhaltsstoffe, Lagerhinweise, Bilder und Verkaufstexte werden auf Lücken geprüft. 3. **B2B-Anfragen qualifizieren** — Händler- und Gastronomieanfragen werden nach Produkt, Menge, Lieferort, Termin und Kondition strukturiert. 4. **Kundenfeedback auswerten** — Rückmeldungen werden nach Geschmack, Verpackung, Lieferung, Preis und Verfügbarkeit gruppiert. 5. **Saisonale Kommunikation vorbereiten** — Aus freigegebenen Produktfakten entstehen Entwürfe für Händlerinfos, Newsletter und Kampagnen. **Bester erster Schritt:** ein Produktdaten- und Lieferantendokumenten-Check für eine Produktlinie. > **Grenze:** Allergene, Deklarationen, Haltbarkeit, Preise und rechtliche Aussagen werden nie automatisch erzeugt oder freigegeben. ### 15. Hotellerie, Gastronomie und Eventlocations 1. **Eventanfragen strukturieren** — Personenzahl, Datum, Raum, Verpflegung, Budgethinweise und Spezialwünsche werden extrahiert. 2. **Reservierungsrückfragen vorbereiten** — Wiederkehrende Fragen zu Verfügbarkeit, Anreise, Menü, Allergien oder Räumen werden als Entwurf vorbereitet. 3. **Gästefeedback analysieren** — Bewertungen werden nach Service, Zimmer, Essen, Sauberkeit und Preis-Leistung zusammengefasst. 4. **Tagesbriefings erstellen** — Aus Reservierungen, Events und internen Notizen entsteht eine übersichtliche Schichtinformation. 5. **Marketinginhalte vorbereiten** — Freigegebene Angebote, Menüs und Veranstaltungen werden in Contententwürfe überführt. **Bester erster Schritt:** Eventanfrage- und Offertvorbereitung für Gruppen, Seminare oder Hochzeiten. ### 16. Detailhandel, Fachgeschäfte und Filialbetriebe 1. **Sortimentswissen finden** — Verkaufsmitarbeitende suchen in freigegebenen Produktinformationen nach Eigenschaften, Varianten und Zubehör. 2. **Kundenanfragen vorbereiten** — Fragen nach Verfügbarkeit, Reservierung, Reparatur oder Ersatzprodukt werden strukturiert. 3. **Lieferanteninformationen aufbereiten** — Neuheiten, Preise, Aktionsunterlagen und Datenblätter werden in eine prüfbare Sortimentsliste überführt. 4. **Filialfeedback bündeln** — Rückmeldungen werden nach Nachfrage, Reklamation, fehlendem Produkt und Prozessproblem gruppiert. 5. **Lokale Kampagnen vorbereiten** — Aus genehmigten Aktionen entstehen Texte und Bildbriefings für Newsletter, Website und Social Media. **Bester erster Schritt:** ein Produktwissens- und Kundenanfrage-Copilot für eine Warengruppe. ## C. Gute Chancen, aber klare Schutzgrenzen Sinnvolle administrative Anwendungsfälle — bei sensiblen Daten oder branchenspezifischen Regeln aber mit engeren Grenzen. ### 17. Agrarwirtschaft, Landhandel und agrarnahe Dienstleister 1. **Kundenanfragen sortieren** — Anfragen zu Produkten, Lieferterminen, Service oder Ersatzteilen werden nach Thema und Zuständigkeit strukturiert. 2. **Produkt- und Lieferantendaten erfassen** — Sicherheitsblätter, Produktinformationen und saisonale Angebotslisten werden nach definierten Feldern vorbereitet. 3. **Saisonale Kommunikation vorbereiten** — Aus freigegebenen Aktionen und Terminen entstehen Entwürfe für Kundeninfos und Einladungen. 4. **Service- und Werkstattberichte strukturieren** — Freitext zu Maschinenservice wird in Auftrag, Maschine, Arbeit, Material und offene Punkte gegliedert. 5. **Internes Wissen erschliessen** — Bedienungsanleitungen, Produktunterlagen und Prozessinformationen werden schneller auffindbar. **Bester erster Schritt:** eine Produkt- und Serviceanfrage-Triage für einen klar abgegrenzten Geschäftsbereich. > **Grenze:** Keine autonome agronomische Beratung, keine Dosierungsempfehlung, keine sicherheitsrelevante Entscheidung. ### 18. Personalvermittlung und Recruiting 1. **Kundenanfragen strukturieren** — Eine Vakanz wird nach Rolle, Standort, Pensum, Muss-Kriterien, Starttermin und offenen Punkten zusammengefasst. 2. **Stelleninserate vorbereiten** — Aus freigegebenen Anforderungen entstehen kanalangepasste Entwürfe, die der Recruiter prüft. 3. **Interviewkoordination vereinfachen** — E-Mails zur Terminsuche werden zu Terminvorschlägen, Aufgaben und Erinnerungen aufbereitet. 4. **Unterlagen administrativ ordnen** — Dokumente werden dem richtigen Vorgang zugeordnet und auf fehlende Nachweise geprüft. 5. **Onboarding-Dokumente vorbereiten** — Für erfolgreiche Vermittlungen entstehen Checklisten, Informationsmails und interne Aufgaben. **Bester erster Schritt:** ein Vakanzauftrags- und Interviewkoordinations-Copilot. > **Grenze:** Keine automatisierte Kandidatenbewertung, keine Rangliste, keine Einstellungsentscheidung. KI unterstützt die Administration, nicht die Personalauswahl. ### 19. Weiterbildung, Kursorganisation und Schulung 1. **Kursanfragen bearbeiten** — Interessentenanfragen werden nach Thema, Niveau, Teilnehmerzahl, Termin und Format strukturiert. 2. **Materialentwürfe erstellen** — Aus freigegebenem Fachmaterial entstehen Übungen, Zusammenfassungen und Präsentationsentwürfe zur didaktischen Prüfung. 3. **Teilnehmeradministration vereinfachen** — Anmeldungen, Abmeldungen, fehlende Angaben und Bescheinigungswünsche werden als Aufgaben sortiert. 4. **Feedback auswerten** — Kursevaluationen werden nach Inhalt, Dozent, Organisation und Verbesserungsvorschlag zusammengefasst. 5. **Wissensdatenbank aufbauen** — Abläufe, Vorlagen, Raum- und Technikinformationen werden schneller auffindbar. **Bester erster Schritt:** ein Kursanfrage- und Teilnehmeradministrations-Copilot. ### 20. Gesundheits-, Therapie- und Gruppenpraxen — ausschliesslich Administration 1. **Administrativen Dokumenteneingang sortieren** — Nicht-klinische Formulare und allgemeine Anfragen werden nach Zuständigkeit und Vollständigkeit geordnet. 2. **Terminrückfragen vorbereiten** — Allgemeine Fragen zu Öffnungszeiten, Ablauf oder erforderlichen Unterlagen werden als Entwurf vorbereitet. 3. **Teamhandbuch durchsuchbar machen** — Interne, nicht-klinische Prozessdokumente werden für autorisierte Mitarbeitende mit Quellen auffindbar. 4. **Administratives Reporting vorbereiten** — Nicht-medizinische Kennzahlen und Teamnotizen werden für die interne Prozessverbesserung zusammengefasst. 5. **Onboarding-Aufgaben organisieren** — Neue Teammitglieder erhalten Aufgabenlisten und Zugangschecklisten aus freigegebenen Vorlagen. **Bester erster Schritt:** eine nicht-klinische Dokumenten- und Anfragentriage mit restriktiven Zugriffsrechten. > **Grenze:** Keine Diagnosen, keine Triage medizinischer Notfälle, keine Therapieempfehlungen, keine klinische Entscheidungsunterstützung. Der Datenschutz- und Sicherheitsaufwand ist hier deutlich höher als in jedem anderen Fall auf dieser Liste. ## Was Sie nicht als erstes Projekt angehen sollten ::compare-table --- columns: - label: Nicht als erster Pilot - label: Weshalb rows: - - Vollautonome E-Mail- oder Social-Media-Kommunikation - Hoher Reputations-, Rechts- und Qualitätsverlust bei Fehlern — und Fehler sind bei Sprachmodellen normal, nicht aussergewöhnlich - - Vollständiger ERP-, CRM- oder PIM-Ersatz - Lange Projekte, viele Beteiligte, kein schnell sichtbarer Nutzen - - Zahlungs-, Rechnungs- oder Lohnfreigaben - Finanzielle und rechtliche Risiken ohne Gegenwert - - Klinische, rechtliche, steuerliche oder personalrechtliche Entscheidungen - Fach- und Haftungsrisiko; die menschliche Fachentscheidung ist zwingend - - Predictive Maintenance oder Computer Vision ohne Datenbasis - Braucht saubere historische Daten, Sensorik, Fachvalidierung und eine lange Integration caption: Keines davon ist unmöglich. Sie sind nur die falsche Wahl für das erste Projekt — weil Risiko, Datenbedarf oder Projektdauer den sichtbaren Nutzen auffressen, bevor er entsteht. label: ABGRENZUNG title: Fünf Vorhaben, die als Einstieg regelmässig scheitern --- :: ## Was ich aus diesen hundert Beispielen mitnehme Zwanzig Branchen sehen aus wie zwanzig verschiedene Probleme. Sie sind es nicht. Es sind fünf Muster in zwanzig Vokabularen. Das ist die praktisch nützlichste Erkenntnis dieser Liste, und sie hat eine unmittelbare Konsequenz: Wer anfangen will, sucht nicht nach der eindrucksvollsten KI-Idee, sondern nach dem **langweiligsten wiederkehrenden Informationsprozess im eigenen Betrieb** — dem, über den sich jede Woche jemand ärgert, ohne dass es je auf einer Traktandenliste stünde. Wenn Sie den gefunden haben, ist der Rest Handwerk: ein Eingang, eine Aufgabe, eine Prüfstufe, eine Ausgabe. # Welches CMS taugt für KI-gestützte Entwicklung? Fast jedes CMS wirbt inzwischen mit KI. Meistens ist damit ein Knopf gemeint, der einen Produkttext schreibt. Das ist nett und für die Auswahl eines Systems fast bedeutungslos. Die Frage, die zählt, ist eine andere: **Kann eine KI in diesem System verlässlich mitarbeiten, ohne dass jemand hinterherräumt?** Und das entscheidet sich nicht am Editor, sondern an drei unspektakulären Eigenschaften. ## Was ein CMS für KI-Arbeit tauglich macht **Das Datenmodell liegt als Code vor.** Wenn die Struktur — welche Inhaltstypen es gibt, welche Felder sie haben, was Pflicht ist — im Repository steht statt nur in einer Weboberfläche, kann ein Modell sie lesen, prüfen und ändern. Eine Änderung wird zu einem nachvollziehbaren Vorschlag, den ein Mensch anschaut, bevor er wirkt. **Die Schnittstelle ist typisiert.** Sanity erzeugt Typen aus Schema und Abfragen [3], Payload und Keystone definieren das Modell ohnehin in TypeScript [4] [5], Hygraph und Prismic generieren Typen aus GraphQL. Der Effekt ist derselbe: Ein Feldname, den es nicht gibt, fällt sofort auf — nicht drei Wochen später auf der Live-Seite. **Schreibrechte lassen sich eng begrenzen.** Directus und Strapi bieten inzwischen native Agentenanbindung über MCP, mit eigenen Nutzern, bestehenden Berechtigungsgrenzen und Protokollierung. [1] [2] Das ist die Grundlage — nicht die fertige Lösung, dazu unten mehr. ::plain-words Der Unterschied lässt sich ohne Fachsprache sagen. Ein CMS mit Schema im Code gibt der KI einen **Bauplan**. Ein CMS ohne gibt ihr ein **Foto vom fertigen Haus** und die Bitte, einen Anbau zu planen. Im ersten Fall kann sie rechnen. Im zweiten rät sie — und Raten sieht bei Sprachmodellen genauso überzeugend aus wie Wissen. :: ## Die Rangliste ::bar-compare --- groups: self: Self-Hosting möglich saas: SaaS / Hybrid items: - label: Sanity value: 4.45 group: saas - label: Payload value: 4.35 group: self - label: Strapi value: 4.2 group: self - label: Directus value: 4.15 group: self - label: Builder.io value: 4.05 group: saas - label: Storyblok value: 3.85 group: saas - label: TinaCMS value: 3.85 group: self - label: Keystone value: 3.85 group: self - label: Hygraph value: 3.8 group: saas - label: Plasmic value: 3.75 group: saas - label: DatoCMS value: 3.75 group: saas - label: Kontent.ai value: 3.3 group: saas - label: Contentful value: 3.3 group: saas - label: Prismic value: 3.2 group: saas - label: Drupal value: 3.1 group: self - label: Ghost value: 2.65 group: self - label: WordPress value: 2.55 group: self max: 5 caption: "Gesamtwert aus acht gewichteten Kriterien: Schema im Code, API-Typisierung, Storybook-Eignung, visuelles Editieren, Agentenanbindung, Redaktionstauglichkeit, Betriebsaufwand und Lock-in-Risiko. Eine Expertenbewertung, keine Messung — die Reihenfolge ist belastbarer als die zweite Nachkommastelle." label: BEWERTUNG title: Eignung für KI-gestützte Entwicklung unit: /5 --- :: Vier Systeme setzen sich ab, und zwar aus vier verschiedenen Gründen. **Sanity** führt, weil Typisierung und Abfragen aussergewöhnlich gut zusammenspielen und generierte Typen bis in die Abfrage hinein reichen. [3] Der Preis ist SaaS: Die Inhalte liegen beim Anbieter, und die Rechnung wächst mit Redakteuren und Datenvolumen. **Payload** ist die Antwort für Teams, die das Datenmodell im Repository reviewen wollen. Das Schema ist TypeScript, eine Modelländerung ist ein Pull Request. [4] Wer ohnehin TypeScript-nah arbeitet, bekommt hier die grösste Kontrolle. **Strapi** und **Directus** liegen dicht dahinter und sind die beiden, die ich für Schweizer KMU-Projekte am häufigsten wähle: Self-Hosting ist echtes Self-Hosting, die Redaktionsoberfläche ist ohne Schulung benutzbar, und beide haben eine dokumentierte Agentenanbindung. [1] [2] [5] Directus setzt auf SQL und lässt sich über eine bestehende Datenbank legen; Strapi ist der klassischere Weg mit einem eigenen Modell. Am anderen Ende steht **WordPress** — und das ist kein Werturteil über WordPress als Publikationssystem. Für die Frage dieses Artikels fehlt schlicht das, worauf es ankommt: Das Modell lebt in der Datenbank, die Schnittstelle ist untypisiert, und die Rechteverwaltung ist nicht dafür gebaut, einem automatisierten Zugang einen engen Ausschnitt zu geben. ## Die Bewertung im Detail ::compare-table --- columns: - label: Plattform - label: Betrieb - label: Schema im Code numeric: true - label: API-Typisierung numeric: true - label: KI-Agenten numeric: true - label: Betriebsaufwand (1 = gering) numeric: true - label: Lock-in (1 = gering) numeric: true - label: Gesamt numeric: true max: 5 rows: - - Sanity - SaaS - 5 - 5 - 3 - 1 - 3 - 4.45 - - Payload - Self-hosted / Cloud - 5 - 5 - 3 - 2 - 1 - 4.35 - - Strapi - Self-hosted / Cloud - 4 - 4 - 5 - 3 - 2 - 4.2 - - Directus - Self-hosted / Cloud - 3 - 4 - 5 - 3 - 1 - 4.15 - - Builder.io - SaaS - 3 - 3 - 5 - 1 - 4 - 4.05 - - Storyblok - SaaS - 3 - 4 - 2 - 1 - 3 - 3.85 - - TinaCMS - Self-hosted / Cloud - 5 - 4 - 2 - 4 - 1 - 3.85 - - Keystone - Self-hosted - 5 - 5 - 2 - 3 - 1 - 3.85 - - Hygraph - SaaS - 4 - 5 - 2 - 1 - 3 - 3.8 - - Plasmic - SaaS / Hybrid - 4 - 3 - 3 - 2 - 3 - 3.75 - - DatoCMS - SaaS - 4 - 5 - 2 - 1 - 3 - 3.75 - - Kontent.ai - SaaS - 3 - 4 - 2 - 1 - 4 - 3.3 - - Contentful - SaaS - 3 - 4 - 2 - 1 - 4 - 3.3 - - Prismic - SaaS - 4 - 3 - 1 - 1 - 3 - 3.2 - - Drupal - Self-hosted / Managed - 3 - 3 - 2 - 4 - 1 - 3.1 - - Ghost - Self-hosted / Managed - 2 - 3 - 1 - 2 - 1 - 2.65 - - WordPress - Self-hosted / Managed - 2 - 2 - 1 - 3 - 2 - 2.55 caption: "Alle Einzelkriterien 1–5. Achtung bei den letzten beiden Spalten: Dort ist ein niedriger Wert der bessere. Sie tragen deshalb bewusst keinen Balken — ein Balken, der bei „schlechter“ voller wird, führt in die Irre." label: KRITERIEN title: Wie die Werte zustande kommen --- :: ## Wie ich Agenten an ein CMS lasse Dass ein System eine Agentenanbindung mitbringt, heisst nicht, dass man sie so verwenden sollte, wie sie ausgeliefert wird. Directus dokumentiert für MCP eigene Nutzer, bestehende Berechtigungen, ein Audit-Protokoll und einen globalen Löschschutz. [1] Strapi liefert MCP standardmässig deaktiviert aus und bindet Tokens an die Rechte des Besitzers. [2] Beides sind gute Fundamente — und Fundamente sind kein Haus. Ich arbeite mit einer festen Rechtestufung, unabhängig vom System: ::compare-table --- columns: - label: Umgebung - label: Rechte des Agenten - label: Erlaubte Aktionen rows: - - Lokal - Voll — auf Test- und Beispieldaten - Modell erkunden, Testdaten erzeugen, Tests ausführen - - Vorschau / Staging - Lesen und Entwürfe schreiben, im festgelegten Ausschnitt - Entwürfe anlegen, Felder prüfen, Vorschau kontrollieren - - Produktion - Standardmässig nur Lesen - Auf Anfrage eng begrenzte, protokollierte Korrektur nach Freigabe - - Produktion — ausgeschlossen - Keine - Löschen, Massenänderungen, Rollen und Zugangsdaten, Schema-Migrationen, Veröffentlichen ohne Review caption: "Die letzte Zeile ist die wichtigste und die unbequemste: Sie schliesst genau die Automatisierungen aus, die im Verkaufsgespräch am meisten Eindruck machen." label: SICHERHEIT title: Was ein Agent wo darf --- :: Dazu vier Regeln, die ich für nicht verhandelbar halte: **Kleine, prüfbare Änderungen statt direkter Eingriffe.** Eine KI erzeugt einen Vorschlag mit Schema-, Typ- und Komponentenänderung in einem Zweig. Sie ändert nichts direkt am laufenden System. **Vorschau statt Veröffentlichung.** Agenten schreiben in Entwürfe. Was öffentlich wird, entscheidet ein Mensch — immer. **Tests als Grenze.** Kein Zusammenführen ohne Typprüfung, Komponententests und Barrierefreiheitsprüfung. Das ist keine Bürokratie, sondern die Stelle, an der die typisierte Schnittstelle ihren Nutzen tatsächlich auszahlt. **Nachvollziehbarkeit.** Jede Änderung trägt, wer sie ausgelöst hat, wann, und auf welchen Auftrag hin. Wenn niemand rekonstruieren kann, warum ein Preis sich geändert hat, ist die Automatisierung ein Risiko und kein Werkzeug. ## Der Ablauf, den ich dafür verwende ::flow-diagram --- steps: - label: Ein Mensch schreibt eine kurze Spezifikation note: Zweck, erlaubte Varianten, Pflichtfelder, Grenzen für Textlängen, Anforderungen an die Barrierefreiheit tone: primary - label: Der Agent baut in einem eigenen Zweig note: Schema, Typen, Mapper, Komponente, Beispieldaten und mehrere Komponentenzustände - label: Automatische Prüfung note: Typen, Linting, Komponententests, Barrierefreiheit, visuelle Abweichungen branches: - label: Prüfung fehlgeschlagen note: Der Vorschlag geht zurück, bevor ihn ein Mensch überhaupt anschaut. tone: warn - label: Ein Mensch prüft Vorschau und Inhaltsmodell note: nicht nur, ob es funktioniert — auch, ob das Modell in einem Jahr noch trägt tone: primary - label: Übernahme in Staging - label: Veröffentlichung durch einen Menschen note: der Agent kann Entwürfe und Beispieldaten anlegen, nicht veröffentlichen tone: secondary caption: Die menschlichen Prüfstufen sind bewusst zwei — eine für den Code, eine für das Inhaltsmodell. Die zweite wird gerne vergessen, und genau dort entstehen die Modellfehler, die man ein Jahr später nicht mehr los wird. label: ARBEITSWEISE title: Ein neuer Inhaltstyp, von der Idee bis zur Produktion --- :: ## Was ich damit nicht mache Ich lasse keine KI eigenständig Inhalte veröffentlichen. Nicht, weil das technisch schwierig wäre, sondern weil es dieselbe Klasse Fehler produziert wie ein unbeaufsichtigter Praktikant mit Vollzugriff — nur schneller und überzeugender formuliert. Ich lasse auch keine KI Schema-Migrationen in der Produktion fahren. Ein Modellfehler ist die teuerste Sorte Fehler in einem CMS, weil er sich still in die Daten einschreibt und erst auffällt, wenn schon tausend Einträge damit angelegt wurden. Und ich baue keinen Prompt-to-UI-Aufbau ohne eine feste Komponentenbibliothek dahinter. Builder.io und Plasmic können generierte Abschnitte an registrierte Komponenten binden [6] — genau darin liegt der Nutzen. Ohne diese Registrierung entsteht kein Designsystem, sondern eine wachsende Sammlung ähnlich aussehender Einzelstücke, die niemand mehr zentral ändern kann. Der ehrliche Schluss: KI beschleunigt die Arbeit an einem CMS erheblich — aber nur dort, wo die Struktur schon stimmt. Sie ersetzt nicht die Entscheidung, wie das Inhaltsmodell aussehen soll. Sie macht diese Entscheidung wichtiger, weil sie schneller in viel mehr Datensätze hineinwächst. # Headless CMS oder klassisches CMS — was der Unterschied wirklich ist „Headless“ klingt nach einer Technologieentscheidung, die man Entwicklern überlässt. Das ist sie nicht. Sie entscheidet, wie schnell Ihre Website ist, was ihr Betrieb monatlich kostet, wie angreifbar sie ist und wie eine Textänderung bei Ihnen im Alltag abläuft. Das sind vier Fragen, die Sie beantworten können müssen, auch wenn Sie nie eine Zeile Code schreiben werden. Dieser Artikel beantwortet sie an vier konkreten Architekturen. Sie brauchen dafür kein Vorwissen — der einzige Begriff, den Sie mitnehmen müssen, steht im nächsten Abschnitt. ## Der eine Unterschied, auf den es ankommt Jede Website muss zwei Dinge tun: Inhalte verwalten und Seiten ausliefern. Der ganze Unterschied zwischen den Architekturen liegt darin, **wann** die Seite entsteht. Bei einem klassischen CMS entsteht sie **beim Aufruf**. Jemand tippt Ihre Adresse ein, ein Server startet ein Programm, das Programm fragt eine Datenbank nach Texten und Bildern, setzt daraus eine Seite zusammen und schickt sie zurück. Das passiert bei jedem Aufruf erneut, solange kein Zwischenspeicher einspringt. Bei einem Headless-Aufbau entsteht sie **vorher**. Alle Seiten werden einmal fertig gebaut und als Dateien abgelegt. Ein Besucher bekommt eine fertige Datei — es gibt in diesem Moment kein Programm, das etwas berechnet, und keine Datenbank, die etwas nachschlagen muss. ::plain-words Ein klassisches CMS ist ein Restaurant: Sie bestellen, dann wird gekocht. Ein statischer Aufbau ist eine Bäckerei am Morgen: Es ist schon alles da, Sie nehmen es mit. Das Restaurant kann mehr — es kocht auf Ihre Wünsche hin. Die Bäckerei ist schneller, günstiger im Betrieb und fällt nicht aus, wenn der Herd streikt. :: Daraus folgt fast alles Weitere. Was beim Aufruf nichts berechnet, braucht keinen Server, der dauerhaft läuft, keine Datenbank, die gesichert werden muss, und kein Plugin, das am Dienstag ein Sicherheitsupdate braucht. ## Vier Architekturen In der Praxis begegnen mir vier Aufbauten. Drei davon liefern fertige Seiten aus und unterscheiden sich nur darin, **wo die Redaktion arbeitet**. Der vierte ist der klassische Weg. ### A — Inhalte als Dateien im Projekt ::flow-diagram --- steps: - label: Redaktion oder Entwickler note: bearbeitet Texte und Daten als Dateien tone: primary - label: Git-Repository note: Website-Code und Inhalte liegen zusammen und sind versioniert - label: Automatischer Build note: aus Dateien und Vorlagen entstehen fertige HTML-, CSS- und JS-Dateien - label: Edge-Auslieferung note: der Besucher bekommt fertige Dateien vom nächstgelegenen Rechenzentrum tone: secondary branches: - label: Kein Backend im Normalbetrieb note: Zwischen Besucher und Website steht keine Datenbank und kein Programm, das erst rechnen muss. tone: muted caption: Kein öffentliches CMS-Backend, keine Datenbank beim Seitenaufruf. Der Nachteil steht im letzten Schritt der Redaktion — es gibt keine gewohnte Redaktionsoberfläche. label: ARCHITEKTUR A title: Vollständig statisch, ohne separates CMS --- :: Inhalte liegen als Textdateien im selben Projekt wie die Website. Das ist der einfachste denkbare Aufbau: nichts läuft dauerhaft, alles ist versioniert, jede Änderung ist nachvollziehbar wie eine Codeänderung — inklusive der Möglichkeit, sie zurückzunehmen. Der Preis: Es gibt keine Redaktionsoberfläche. Wer Texte ändert, arbeitet in Dateien. Für einen Onepager, eine Kampagnenseite oder eine Dokumentation mit seltenen Änderungen ist das kein Problem. Für eine Redaktion, die täglich publiziert, ist es eines. ### B — Dieselbe Basis, dazu ein visueller Editor ::flow-diagram --- steps: - label: Redaktion note: bearbeitet Texte und Bilder visuell im Browser tone: primary - label: Editor mit Login note: läuft serverseitig, mit OAuth und Freigabeliste branches: - label: Kein reines Static-Hosting mehr note: Der Login-Teil braucht eine Plattform, die serverseitigen Code ausführen kann. Das ist der Punkt, den ein Angebot separat ausweisen muss. tone: warn - label: Commit ins Repository note: aus der visuellen Änderung wird eine versionierte Dateiänderung - label: Automatischer Build note: die Seiten werden neu gebaut - label: Edge-Auslieferung note: normale Seitenaufrufe bleiben statisch tone: secondary caption: "Die Inhalte bleiben Dateien im Repository — der Editor schreibt sie nur, statt dass jemand sie von Hand bearbeitet. Wichtig fürs Angebot: Für den Editor-Login braucht es eine serverseitige Route, also mehr als reines Datei-Hosting." label: ARCHITEKTUR B title: Statisch vorne, visueller Editor hinten --- :: Diese Variante behält alle Vorteile von A und nimmt ihren einzigen echten Nachteil weg: Die Redaktion arbeitet visuell im Browser, aber gespeichert wird weiterhin als versionierte Datei. Sie sehen diese Architektur gerade — die Seite, auf der Sie lesen, wird genau so betrieben. Der Haken ist klein, aber er gehört genannt, weil er in Offerten regelmässig untergeht: Der Login des Editors läuft serverseitig. „Statische Website“ und „visueller Editor“ schliessen sich nicht aus, aber die Kombination ist nicht mehr reines Datei-Hosting. [3] ### C — Ein echtes Headless CMS dahinter ::flow-diagram --- steps: - label: Redaktion note: arbeitet im CMS — mit Rollen, Entwürfen, Freigaben und Medienverwaltung tone: primary - label: CMS mit Datenbank und Medienspeicher note: das System of Record für alle Inhalte - label: Publish-Webhook note: eine Freigabe startet den Bau der Website branches: - label: Entwürfe lösen nichts aus note: Unfertige Inhalte bleiben intern und erscheinen nirgends öffentlich. tone: muted - label: Build liest nur Freigegebenes note: über die API des CMS - label: Edge-Auslieferung note: fertige Seiten, ohne CMS-Aufruf beim Besuch tone: secondary caption: Die Redaktion arbeitet in einer vollwertigen Oberfläche mit Rollen, Entwürfen und Medienverwaltung. Besucher erreichen dieses System im Normalfall nie. label: ARCHITEKTUR C title: Statisch vorne, strukturiertes Backend hinten --- :: Sobald mehrere Menschen redaktionell arbeiten, Rollen und Freigaben nötig werden oder Inhalte strukturiert sind — News, Produkte, Standorte, mehrere Sprachen — ist das der richtige Aufbau. Das CMS ist eine vollwertige Redaktionsumgebung. Die Website davor bleibt trotzdem statisch. Entscheidend ist dabei die Dimensionierung: Der Server hinter dem CMS muss die Redaktion und den Bau tragen, nicht den Besucherverkehr. Ein Beitrag, der in die Tagesschau kommt, erhöht die Last auf dem CMS-Server um nichts. ### D — Der klassische Weg ::flow-diagram --- steps: - label: Redaktion note: arbeitet direkt im laufenden System tone: primary - label: Besucher ruft eine Seite auf - label: CDN oder Cache note: beantwortet, was zwischengespeichert ist tone: secondary branches: - label: Cache-Miss, Login oder dynamische Funktion note: Der Aufruf geht weiter an den Server — und dort wird gerechnet. tone: warn - label: PHP-Anwendung mit Theme und Plugins note: setzt die Seite zusammen - label: Datenbank note: liefert die Inhalte dazu branches: - label: Muss dauerhaft laufen note: PHP, Datenbank, Plugins und Admin bleiben notwendig — auch wenn ein CDN sehr viel abfängt. tone: warn caption: Ein CDN entlastet die öffentlichen, cachebaren Seiten erheblich. Es ersetzt aber weder PHP noch Datenbank noch Admin-Oberfläche — die müssen weiterlaufen. label: ARCHITEKTUR D title: Klassisches Drupal oder WordPress --- :: Ein klassisches CMS ist nicht veraltet, und es gehört nicht schlechtgeredet. Drupal etwa bringt einen ausgereiften Seiten-Cache mit, der auch für eingeloggte Nutzer greift. [4] Das verbessert die Leistung erheblich — es ändert aber die Grundarchitektur nicht: Ein PHP- und Datenbank-Ursprung bleibt für das System nötig, mit den Anforderungen, die der Hersteller selbst nennt: PHP 8.3+, MySQL 8.0+ oder MariaDB 10.11+ und ein Webserver. [2] ## Die Kurzform ohne Fachsprache ::compare-table --- columns: - label: Frage - label: Statisch (A–C) - label: Klassisch (D) rows: - - Muss ein Server für jeden Besucher die Seite zusammenbauen? - Nein - Häufig ja, wenn kein Cache-Treffer vorliegt - - Braucht ein normaler Seitenbesuch eine Datenbank? - Nein - Ja - - Kann die Redaktion ohne Entwickler Inhalte ändern? - Ab Variante B ja - Ja - - Wo entsteht laufender Serveraufwand? - Beim Bauen und Ausliefern - CMS, PHP, Datenbank, Plugins, Cache und Besucherverkehr - - Was passiert bei einem Fehler in der Veröffentlichung? - Die bisherige Version bleibt online - Die Änderung wirkt sofort im laufenden System - - Was muss regelmässig aktualisiert werden? - Der Website-Code - CMS-Kern, Theme, Plugins, PHP und Datenbank caption: „Statisch“ meint hier die Architekturen A bis C. Sie unterscheiden sich in der Redaktion, nicht in der Auslieferung. label: ENTSCHEIDUNGSHILFE title: Die vier Fragen, die den Unterschied ausmachen --- :: Die vorletzte Zeile ist die, die im Alltag am meisten wert ist und in Vergleichen am seltensten auftaucht. Bei den statischen Varianten wird eine neue Version erst dann öffentlich, wenn sie **vollständig und fehlerfrei gebaut** wurde. Geht beim Bauen etwas schief, bleibt die alte Website online und das Team bekommt eine Fehlermeldung. Beim klassischen CMS verändert eine Veröffentlichung direkt das laufende System. ## Cloudflare oder eigener Server? Meistens beides Ein Missverständnis, das ich oft höre: Man müsse sich zwischen einem Edge-Anbieter wie Cloudflare und einem eigenen Server entscheiden. Bei den Architekturen B und C ist das keine Entweder-oder-Frage. Cloudflare liefert die öffentliche Website weltweit aus. Der kleine eigene Server trägt nur CMS, Redaktion, Medien und Builds. Der Backend-Server muss dadurch **nicht mit dem Besucherverkehr wachsen** — er ist für eine Handvoll Redakteure dimensioniert, nicht für Zehntausende Leser. Für statische Dateien berechnet Cloudflare Pages nach eigener Dokumentation weder auf dem kostenlosen noch auf dem bezahlten Plan Request-Gebühren; erst dynamische Ausführung fällt in ein Nutzungsmodell. [1] Bei einem klassischen CMS lässt sich dasselbe CDN davorstellen, und das lohnt sich auch. Nur bleibt darunter ein Ursprung, der weiterlaufen muss. ## Warum ich Headless vorziehe Ich komme aus dem Frontend. Das prägt die Antwort, und ich sage sie deshalb als Position, nicht als Naturgesetz. **Ich bekomme die Kontrolle über das, wofür ich geradestehe.** Bei einem klassischen CMS gibt das System die Struktur der Seite vor, und ein Theme arbeitet dagegen an. Bei Headless bestimme ich das Markup vollständig. Ladezeit, Zugänglichkeit und Verhalten auf dem Handy sind dann tatsächlich meine Verantwortung — und nicht die eines Plugins, das jemand vor sechs Jahren geschrieben hat. **Die Angriffsfläche schrumpft auf fast nichts.** Was beim Aufruf nichts ausführt, kann beim Aufruf auch nicht kompromittiert werden. Es gibt keine Login-Maske auf der öffentlichen Website, keine Plugin-Kette und keine Datenbank, die von aussen erreichbar wäre. **Inhalte werden überprüfbar.** Jede Änderung ist eine nachvollziehbare Version mit Autor und Zeitpunkt. „Wer hat den Preis geändert, und wann?“ ist keine Ermittlungsarbeit mehr. **Der Betrieb wird langweilig** — und das ist bei Infrastruktur das grösste Kompliment. Es gibt kein Wartungsfenster, in dem der Kern aktualisiert wird und die Seite eine Viertelstunde nicht erreichbar ist. ## Wann ich trotzdem zum klassischen CMS rate Wenn eine Organisation seit Jahren mit Drupal oder WordPress arbeitet, dort Prozesse, Schulungen und Erweiterungen hat, dann ist eine Migration ein Projekt mit Risiko und ohne unmittelbaren Nutzen für die Nutzer. Der ehrliche Rat ist dann: nicht migrieren. Ein CDN davorstellen, die Ladezeit messen, und erst dann etwas ändern, wenn eine konkrete Grenze tatsächlich blockiert. Ebenso, wenn eine Website stark dynamisch ist — Nutzerkonten, personalisierte Ansichten, ein Shop mit Live-Beständen. Dann muss beim Aufruf etwas gerechnet werden, und ein Aufbau, der genau das vermeidet, ist die falsche Wahl. Der Punkt ist nicht, dass Headless immer gewinnt. Der Punkt ist, dass die Frage „muss bei jedem Besuch etwas laufen?“ vor der Werkzeugwahl kommt — und dass sie sich ohne Fachwissen beantworten lässt. # Was „statisch“ wirklich bedeutet — und warum ein Bauschritt dazwischen gehört Wenn ich in einem Erstgespräch sage, dass die Website statisch ausgeliefert wird, kommt fast immer dieselbe Rückfrage: „Dann kann ich also nichts mehr ändern?“ Doch. Sie können alles ändern, jederzeit, selbst. Das Wort ist nur unglücklich gewählt. ## Was „statisch“ tatsächlich meint Es beschreibt nicht, wie oft sich Inhalte ändern. Es beschreibt, **wann die Seite entsteht**. Bei einer dynamischen Website entsteht jede Seite in dem Moment, in dem sie jemand aufruft. Ein Programm läuft an, fragt eine Datenbank, setzt Text, Bilder und Menü zusammen, schickt das Ergebnis zurück. Bei einer statischen Website ist die Seite bereits fertig, bevor der erste Besucher davon weiss. Sie wird ausgeliefert wie ein Bild oder ein PDF — es gibt nichts mehr zu berechnen. ::plain-words Stellen Sie sich zwei Bäckereien vor. In der einen wird jedes Brot erst gebacken, wenn jemand es bestellt — dann muss der Ofen immer heiss sein, jemand muss ständig da sein, und bei zwanzig Kunden gleichzeitig wird es eng. In der anderen wird morgens gebacken, und danach wird nur noch verkauft. Zwanzig Kunden gleichzeitig sind kein Problem, weil niemand mehr backen muss. Statisch heisst: morgens backen. Nicht: nie wieder backen. :: ## Was passiert, wenn Sie einen Text ändern? Genau hier sitzt der Unterschied, und es lohnt sich, ihn einmal Schritt für Schritt zu sehen. ::flow-diagram --- steps: - label: Sie ändern einen Text note: im Editor, so wie Sie es aus jedem anderen Redaktionssystem kennen tone: primary - label: Sie klicken auf „Veröffentlichen“ branches: - label: Solange Sie nicht klicken, passiert nichts note: Ein Entwurf bleibt intern. Er löst keinen Bau aus und ist öffentlich nirgends sichtbar. tone: muted - label: Der Bauauftrag startet automatisch note: ausgelöst durch die Freigabe, nicht durch einen Menschen - label: Die Website wird komplett neu gebaut note: aus Vorlagen und freigegebenen Inhalten entstehen alle Seiten als fertige Dateien branches: - label: Geht beim Bauen etwas schief note: Die bisherige Website bleibt unverändert online. Es geht nichts kaputt, und Sie bekommen eine Fehlermeldung. tone: warn - label: Die neue Version geht live note: sie wird weltweit an die Auslieferungspunkte verteilt tone: secondary - label: Besucher sehen den neuen Stand caption: Der Ablauf ist bei jeder Änderung derselbe, ob Sie ein Komma korrigieren oder eine neue Seite anlegen. Zwischen Klick und Live-Version liegen typischerweise ein bis drei Minuten. label: VERÖFFENTLICHUNG title: Von der Änderung zur Live-Version --- :: Zwei Dinge an diesem Ablauf sind ungewohnt, und beide sind Vorteile. **Erstens gibt es eine Wartezeit.** Ein bis drei Minuten, bis eine Änderung sichtbar ist. Bei einem klassischen CMS ist sie sofort da. Das klingt nach einem Nachteil, und in genau einem Fall ist es einer: wenn Sie eine Falschmeldung in Sekunden vom Netz nehmen müssen. **Zweitens wird nie eine halbfertige Version öffentlich.** Eine neue Version geht erst live, wenn sie **vollständig und fehlerfrei** gebaut wurde. Bricht der Bau ab — ein defektes Bild, eine kaputte Verknüpfung, ein Syntaxfehler in einer Vorlage —, dann bleibt schlicht die alte Website online. Bei einem dynamischen System wirkt eine problematische Änderung direkt im laufenden Betrieb. Das ist der Unterschied zwischen „ich habe die Website kaputtgemacht“ und „meine Änderung ist nicht durchgekommen, ich schaue nochmal“. ## Was das konkret einbringt ::compare-table --- columns: - label: Bereich - label: Dynamisch - label: Statisch rows: - - Antwortzeit - Server muss rechnen, Datenbank antworten - Fertige Datei, direkt vom nächstgelegenen Standort - - Lastspitze - Mehr Besucher heisst mehr Rechenlast - Mehr Besucher heisst mehr Dateiauslieferung - - Angriffsfläche - Login, Datenbank und Erweiterungen sind öffentlich erreichbar - Es gibt öffentlich nichts, was Code ausführt - - Laufende Kosten - Server, Datenbank, Backups, Wartung - Auslieferung, oft im Gratiskontingent - - Wartungsaufwand - Systemkern, Erweiterungen, Sprachversion, Datenbank - Der Website-Code - - Fehler beim Veröffentlichen - Wirkt sofort im laufenden System - Die alte Version bleibt online caption: Die letzte Zeile ist die, die im Alltag am meisten wert ist und in Vergleichen am seltensten steht. label: WIRKUNG title: Was sich durch den Bauschritt tatsächlich ändert --- :: Die Kostenzeile verdient eine ehrliche Einordnung, weil sie oft übertrieben wird. Für statische Dateien berechnet Cloudflare Pages nach eigener Dokumentation weder auf dem kostenlosen noch auf dem bezahlten Plan Request-Gebühren; erst dynamische Ausführung fällt in ein Nutzungsmodell. [1] Das heisst aber nicht „Website für null Franken“ — Domain, E-Mail, allfälliges CMS-Backend und Wartung fallen weiter an. Es heisst, dass der Posten „Server, der Ihre Website ausliefert“ bei kleineren Auftritten realistisch gegen null geht. Die Wartungszeile ist die, die ich für die wichtigere halte. Ein klassisches System braucht dauerhaft eine aktuelle Sprachversion, eine aktuelle Datenbank und einen Webserver [3] — plus Erweiterungen, die alle ihren eigenen Aktualisierungsrhythmus haben. Jede dieser Komponenten ist eine Stelle, an der eine ungepatchte Lücke Monate unbemerkt offen stehen kann. ## Der eine echte Stolperstein Damit niemand mit einer falschen Vorstellung aus diesem Artikel geht: Es gibt eine Sache, die bei statischen Websites tatsächlich anders gehandhabt werden muss. Der Build muss **wissen, welche Seiten er bauen soll**. Bei einer festen Seitenstruktur ist das kein Thema. Sobald aber Inhalte aus einem CMS neue Adressen erzeugen — ein neuer Blogbeitrag, eine neue Produktseite, ein neuer Standort —, muss der Bauprozess diese Adressen ermitteln können. [2] In der Praxis wird das einmal eingerichtet und läuft dann. Es ist trotzdem der Punkt, an dem schlecht gebaute Projekte auffallen: Wenn eine neue Seite im CMS erscheint, aber unter ihrer Adresse eine Fehlerseite steht, ist genau das die Ursache. ::plain-words Übersetzt: Die Bäckerei muss wissen, welche Brotsorten sie morgens backen soll. Nimmt jemand eine neue Sorte ins Sortiment, ohne es der Backstube zu sagen, steht sie zwar auf der Karte, liegt aber nicht im Regal. Das ist ein Einrichtungsfehler, kein grundsätzliches Problem — aber Sie sollten wissen, dass es diese Stelle gibt, damit Sie danach fragen können. :: ## Wann ich davon abrate Statisch ist kein Selbstzweck. Sobald jede Seite für jeden Besucher anders aussehen muss, kippt die Rechnung. Konkret: Nutzerkonten mit persönlichen Daten, ein Warenkorb mit Live-Beständen, ein Buchungskalender mit sekundenaktueller Verfügbarkeit, eine interne Anwendung hinter einem Login. Da muss beim Aufruf gerechnet werden, und dann ist ein Aufbau, der genau das vermeiden will, das falsche Werkzeug. Der praktisch häufigste Fall ist allerdings ein gemischter: eine statische Website, in der ein einzelner dynamischer Teil steckt — ein Kontaktformular, eine Suche, ein Chat. Das ist kein Widerspruch. Es bedeutet nur, dass ein kleiner, klar abgegrenzter Teil serverseitig läuft, während die anderen 95 Prozent der Seiten fertig ausgeliefert werden. Diese Website ist genau so gebaut. # 100 AI automations in businesses — 20 industries, five concrete examples each The most common question in a first conversation about AI is not “is it possible?” but “where do I start?”. And the most common misconception behind it is that an AI project has to be big to be worthwhile. This list is the counter-thesis. Each of the hundred items targets a **recurring information process**: e-mails, enquiries, PDFs, reports, product data, photos, conversations, internal documents. For a first step that is almost always better suited than autonomous agents, a system change or an AI that makes binding expert decisions. ## The rule by which a pilot is cut to size ::flow-diagram --- steps: - label: One input note: a single kind of enquiry, one document type, one kind of form — not “all e-mails” tone: primary - label: One clear AI task note: structure, summarise, find gaps, assign — one of them, not all - label: One human review stage note: a named person sees the result before it moves on tone: primary branches: - label: No pilot without this stage note: Not out of caution, but because this is where you learn what the system gets systematically wrong. tone: warn - label: One output note: into the tool that is used anyway — CRM, ticket system, folder, spreadsheet tone: secondary caption: Sounds modest and is successful precisely for that reason. A pilot that covers two inputs and three tasks at once can no longer be judged — if the result is poor, nobody knows at which point. label: PILOT RULE title: One input, one task, one review, one output --- :: An example in one sentence: an e-mail enquiry comes in → the AI breaks it down into trade, location, requested service, urgency and missing details → an employee checks → a draft quote sits in the CRM. ## Five patterns, twenty industries However different the industries below look: practically every good entry project is a variant of one of these five patterns. ::compare-table --- columns: - label: Pattern - label: Typical input - label: The AI’s task - label: Human output rows: - - Enquiry copilot - E-mail, form, phone note, PDF - Recognise topic, fields, urgency, missing details and responsibility - Review a reply, ticket or quote draft - - Document copilot - PDF, scan, supplier document, report - Extract document type, key fields, deadlines, gaps and a summary - Approve a checklist, task or data draft - - Knowledge copilot - Approved internal files - Search source-based and answer with the reference - Expert assesses the answer and extends the knowledge base - - Product and content copilot - Product data, assets, data sheet, brief - Spot data gaps, draft texts and metadata - Subject-matter and brand approval - - Project and service copilot - Minutes, photo, report, ticket - Structure tasks, status, defects and next steps - Responsible person steers and closes the case caption: If you read an industry below that is not yours, the look is still worthwhile — the patterns transfer, the vocabulary changes. label: PATTERNS title: The five kinds of process that repeat almost everywhere --- :: ## A. Industries with the easiest entry Plenty of digital information, clearly recurring workflows, and the benefit is immediately visible to management. ### 1. Trades and construction 1. **Structure enquiries** — An enquiry with photos and e-mail text is broken down into trade, location, requested service, urgency, missing details and responsibility. 2. **Quote preparation** — From the enquiry, the site-visit note and earlier templates, an internal quote checklist emerges; the person in charge adds prices and approves. 3. **Evaluate reports** — Daily, site or service reports are broken down from free text and photos into work done, material, working time, open items and next appointment. 4. **Defect and task triage** — A report with a picture is summarised as a ticket, categorised by trade and assigned to a suggested owner. 5. **Prepare customer communication** — After a job, a draft for a plain-language status e-mail emerges with completed work, open items and next step. **Best first step:** an enquiry-to-quote copilot for a single kind of enquiry — say, plumbing repairs or renovation quotes. ### 2. Technical service providers, electrical, HVAC and maintenance 1. **Classify fault reports** — E-mails, web forms and phone notes are structured by installation, fault pattern, location, urgency and required follow-up questions. 2. **Find technical documents** — An internal assistant searches approved manuals, schematics and maintenance instructions and shows the reference. 3. **Prepare service calls** — From ticket and installation history, a checklist emerges: device, last measures, known faults, material to bring. 4. **Standardise work reports** — The technician briefly dictates what was done; a structured service report emerges for review. 5. **Prepare maintenance due dates** — From maintenance contracts and last visits, a list of upcoming customer contacts emerges. **Best first step:** service triage and a report copilot for one recurring kind of fault report. ### 3. Architecture, planning and engineering firms 1. **Turn meeting minutes into tasks** — Decisions, open items, owners and deadlines are extracted as a draft. 2. **Summarise project documents** — Extensive PDFs are broken down into project goal, dates, requirements, open questions and relevant attachments. 3. **Prepare defect reports** — Photos and keywords from a site walk are turned into numbered defect items and a traceable task list. 4. **Pre-check tenders** — Requirements, submission deadlines, missing information and checkpoints are made visible. 5. **Communicate project status** — From approved project information, a draft for a client or team status update emerges. **Best first step:** a minutes-to-open-items copilot with approval by the project lead. ### 4. Property management and facility management 1. **Route tenant enquiries** — A report is recognised as damage, repair request, contract question or general enquiry and assigned. 2. **Structure damage cases** — Location, affected unit, description, image attachments, urgency and likely responsibility are extracted. 3. **Prepare contractor orders** — From a reviewed report, a clear order emerges with property, problem, access notes and attachments. 4. **Make property documents searchable** — House rules, minutes and handover documents become searchable internally with source references. 5. **Prepare handover reports** — Notes and photos are turned into a structured checklist or a draft report. **Best first step:** tenant enquiry and damage triage for a clearly delimited portfolio. ### 5. Trade and wholesale 1. **Complete product data** — Supplier PDFs are evaluated for technical data, units, variants, images and missing mandatory fields. 2. **Pre-qualify requests for quotation** — A B2B enquiry is structured by product, quantity, date, delivery location and missing details. 3. **Prepare customer questions** — Frequent questions about variants, availability or substitute items are prepared as reply drafts with sources. 4. **Check supplier documents** — Price lists, data sheets and new-product lists are turned into structured change lists. 5. **Prepare multilingual product content** — Based on approved facts, drafts for description, key data, metadata and translations emerge. **Best first step:** a product data check for 20 to 30 important items, with a review before every publication. ### 6. E-commerce and online retail 1. **Check catalogue quality** — Missing images, attributes, variants, descriptions, SEO fields or contradictory details are reported. 2. **Triage support enquiries** — Order, shipping, return and product questions are recognised, summarised and forwarded with order context. 3. **Analyse return reasons** — Texts from returns are grouped: size, quality, wrong expectation, transport damage. 4. **Vary product content** — From confirmed product facts, channel-appropriate short texts, newsletter modules and social drafts emerge. 5. **Evaluate reviews** — Reviews are summarised into recurring positives, criticisms and improvement hints. **Best first step:** support triage for three frequent kinds of enquiry, or a catalogue quality check for one category. ### 7. Professional services and consulting 1. **Qualify new enquiries** — E-mails and contact forms are structured by topic, team, scope, urgency and missing details. 2. **Prepare quotes** — From conversation notes, service modules and templates, a proposal outline with open questions emerges. 3. **Find project knowledge** — Past results, methods, checklists and templates become searchable internally with sources. 4. **Meeting follow-up** — Decisions, tasks, risks and client questions are extracted from notes. 5. **Create report drafts** — Approved project data is structured according to a fixed template; the consultant is responsible for the content. **Best first step:** a project knowledge and quote copilot for a single team. ### 8. Creative, marketing and digital agencies 1. **Standardise briefs** — Incomplete client requests are turned into goal, target group, channel, material, deadline, approval and open questions. 2. **Create asset metadata** — Images, videos and documents receive tag suggestions, project assignment, intended use and rights notes for review. 3. **Prepare content production** — From an approved brief and brand rules, first variants for website, newsletter, social and ads emerge. 4. **Bundle feedback** — Comments from e-mails, PDFs and meetings are summarised by change request, responsibility and approval status. 5. **Summarise campaign reporting** — Platform data and team notes are turned into a client-friendly report template. **Best first step:** a brief-to-content workflow for a single channel. ## B. High value, somewhat more integration effort The benefit is just as big, but the system landscape is more heterogeneous and the demands on data and approvals are higher. ### 9. Manufacturing industry and suppliers 1. **Pre-check technical enquiries** — A customer PDF is structured by specification, quantity, date, standards and missing details. 2. **Unlock technical knowledge** — Work instructions, data sheets and manuals become searchable internally; answers show the reference. 3. **Prepare deviation reports** — Quality and defect reports are broken down by product, fault pattern, cause, measure and open item. 4. **Prepare multilingual documentation** — Approved technical content is prepared as a draft for further languages and formats. 5. **Structure supplier communication** — E-mails about delivery delays, quality or queries are summarised and turned into tasks. **Best first step:** a technical enquiry and document copilot for one product segment. ### 10. Machine service, plant engineering and spare parts 1. **Classify service cases** — Fault description, picture, machine type and location are extracted from an enquiry and categorised. 2. **Prepare spare-part searches** — From approved parts lists and manuals, a list of possible parts with sources emerges. 3. **Create technician briefings** — Machine history, last measures, known faults and open queries are summarised before the visit. 4. **Structure service reports** — Free text from the field is broken down into fault pattern, diagnosis, work done, parts used and next steps. 5. **Prepare customer reports** — After technical review, a plain-language report about work, observations and recommendations emerges. **Best first step:** a service and spare-part enquiry triage with review by the technically responsible person. ### 11. Transport, logistics and warehousing 1. **Extract transport enquiries** — Pickup location, delivery location, date, weight, dimensions, special requirements and missing details are recognised from e-mails. 2. **Check shipping documents** — Delivery notes, waybills and order documents are checked for completeness and deviations. 3. **Prioritise exceptions** — Reports about delay, damage, wrong delivery or missing papers are categorised and assigned. 4. **Prepare customer status** — From permitted order data, a verifiable status draft for customer communication emerges. 5. **Summarise warehouse deviations** — Notes about shortages, damage or wrong storage are ordered and prepared as a task list. **Best first step:** a transport enquiry and document check for one standardised kind of shipment. ### 12. Fiduciaries, accounting and administrative offices 1. **Triage incoming documents** — Receipts and client documents are structured by document type, client, period and missing documents. 2. **Check completeness** — The list of expected documents is compared with the files on hand and prepared as a draft query. 3. **Make internal knowledge findable** — Work instructions, templates and checklists become searchable with sources. 4. **Prepare client communication** — Recurring queries that do not involve expert decisions are prepared as a draft and reviewed. 5. **Extract deadlines and tasks** — From e-mails and documents, dates, missing information and follow-ups are recognised as tasks. **Best first step:** a client document triage for one low-risk class of documents. > **Limit:** No automatic tax, booking, payment or legal decisions. The AI supports preparation and completeness; professionals review and are responsible for every decision. ### 13. Printing, packaging and publishing 1. **Evaluate job briefs** — Customer e-mails and PDFs are structured by format, print run, paper, colour, finishing, date and open questions. 2. **Prepare requests for quotation** — A costing checklist emerges so that missing production details are noticed quickly. 3. **Standardise the production handover** — Approved job data is turned into a clear job ticket draft. 4. **Bundle correction rounds** — Customer feedback on layouts and proofs is summarised by page, element and change request. 5. **Create service descriptions** — From real production data, drafts for service descriptions and sample offers emerge. **Best first step:** an enquiry-to-job-ticket workflow for one frequent product. ### 14. Food production and food wholesale 1. **Capture supplier documents** — Specifications, ingredient lists, certificates and price lists are prepared according to a fixed schema. 2. **Complete product data** — Package size, ingredients, storage notes, images and sales texts are checked for gaps. 3. **Qualify B2B enquiries** — Retailer and restaurant enquiries are structured by product, quantity, delivery location, date and terms. 4. **Evaluate customer feedback** — Feedback is grouped by taste, packaging, delivery, price and availability. 5. **Prepare seasonal communication** — From approved product facts, drafts for retailer information, newsletters and campaigns emerge. **Best first step:** a product data and supplier document check for one product line. > **Limit:** Allergens, declarations, shelf life, prices and legal statements are never generated or approved automatically. ### 15. Hotels, restaurants and event venues 1. **Structure event enquiries** — Number of guests, date, room, catering, budget hints and special wishes are extracted. 2. **Prepare reservation queries** — Recurring questions about availability, directions, menu, allergies or rooms are prepared as drafts. 3. **Analyse guest feedback** — Reviews are summarised by service, room, food, cleanliness and value for money. 4. **Create daily briefings** — From reservations, events and internal notes, a clear shift briefing emerges. 5. **Prepare marketing content** — Approved offers, menus and events are turned into content drafts. **Best first step:** event enquiry and quote preparation for groups, seminars or weddings. ### 16. Retail, specialist shops and store chains 1. **Find range knowledge** — Sales staff search approved product information for properties, variants and accessories. 2. **Prepare customer enquiries** — Questions about availability, reservation, repair or substitute products are structured. 3. **Process supplier information** — New products, prices, promotion documents and data sheets are turned into a verifiable range list. 4. **Bundle store feedback** — Feedback is grouped by demand, complaint, missing product and process problem. 5. **Prepare local campaigns** — From approved promotions, texts and image briefs for newsletter, website and social media emerge. **Best first step:** a product knowledge and customer enquiry copilot for one product group. ## C. Good opportunities, but clear protective limits Sensible administrative use cases — but with tighter limits where data is sensitive or industry-specific rules apply. ### 17. Agriculture, agricultural trade and related services 1. **Sort customer enquiries** — Enquiries about products, delivery dates, service or spare parts are structured by topic and responsibility. 2. **Capture product and supplier data** — Safety data sheets, product information and seasonal offer lists are prepared according to defined fields. 3. **Prepare seasonal communication** — From approved promotions and dates, drafts for customer information and invitations emerge. 4. **Structure service and workshop reports** — Free text about machine service is broken down into order, machine, work, material and open items. 5. **Unlock internal knowledge** — Operating instructions, product documents and process information become easier to find. **Best first step:** a product and service enquiry triage for one clearly delimited business area. > **Limit:** No autonomous agronomic advice, no dosage recommendations, no safety-relevant decisions. ### 18. Staffing and recruiting 1. **Structure client requests** — A vacancy is summarised by role, location, workload, must-have criteria, start date and open items. 2. **Prepare job adverts** — From approved requirements, channel-adapted drafts emerge that the recruiter reviews. 3. **Simplify interview coordination** — E-mails about finding a date are prepared into slot proposals, tasks and reminders. 4. **Organise documents administratively** — Documents are assigned to the right case and checked for missing evidence. 5. **Prepare onboarding documents** — For successful placements, checklists, information e-mails and internal tasks emerge. **Best first step:** a vacancy order and interview coordination copilot. > **Limit:** No automated candidate assessment, no ranking, no hiring decisions. AI supports the administration, not the selection of people. ### 19. Continuing education, course organisation and training 1. **Handle course enquiries** — Prospect enquiries are structured by topic, level, number of participants, date and format. 2. **Create material drafts** — From approved subject material, exercises, summaries and presentation drafts emerge for didactic review. 3. **Simplify participant administration** — Registrations, cancellations, missing details and certificate requests are sorted as tasks. 4. **Evaluate feedback** — Course evaluations are summarised by content, instructor, organisation and improvement suggestions. 5. **Build a knowledge base** — Procedures, templates, room and equipment information become easier to find. **Best first step:** a course enquiry and participant administration copilot. ### 20. Health, therapy and group practices — administration only 1. **Sort incoming administrative documents** — Non-clinical forms and general enquiries are ordered by responsibility and completeness. 2. **Prepare appointment queries** — General questions about opening hours, procedure or required documents are prepared as drafts. 3. **Make the team handbook searchable** — Internal, non-clinical process documents become findable with sources for authorised staff. 4. **Prepare administrative reporting** — Non-medical figures and team notes are summarised for internal process improvement. 5. **Organise onboarding tasks** — New team members receive task lists and access checklists from approved templates. **Best first step:** a non-clinical document and enquiry triage with restrictive access rights. > **Limit:** No diagnoses, no triage of medical emergencies, no therapy recommendations, no clinical decision support. The data protection and security effort here is considerably higher than in any other case on this list. ## What you should not tackle as a first project ::compare-table --- columns: - label: Not as a first pilot - label: Why rows: - - Fully autonomous e-mail or social media communication - High reputational, legal and quality loss on errors — and errors are normal with language models, not exceptional - - Complete ERP, CRM or PIM replacement - Long projects, many stakeholders, no quickly visible benefit - - Payment, invoice or payroll approvals - Financial and legal risks without return - - Clinical, legal, tax or employment-law decisions - Professional and liability risk; the human expert decision is mandatory - - Predictive maintenance or computer vision without a data basis - Needs clean historical data, sensors, expert validation and a long integration caption: None of them is impossible. They are simply the wrong choice for the first project — because risk, data needs or project duration eat up the visible benefit before it arises. label: BOUNDARIES title: Five undertakings that regularly fail as a first step --- :: ## What I take away from these hundred examples Twenty industries look like twenty different problems. They are not. They are five patterns in twenty vocabularies. That is the most practically useful insight of this list, and it has an immediate consequence: whoever wants to start does not look for the most impressive AI idea but for the **most boring recurring information process in their own business** — the one someone gets annoyed about every week without it ever making it onto an agenda. Once you have found that one, the rest is craft: one input, one task, one review stage, one output. # Headless CMS or traditional CMS — what the difference really is “Headless” sounds like a technology decision you leave to developers. It is not. It decides how fast your website is, what its operation costs per month, how vulnerable it is and how a text change plays out in your daily work. Those are four questions you need to be able to answer, even if you will never write a line of code. This article answers them using four concrete architectures. You need no prior knowledge — the only term you have to take with you is in the next section. ## The one difference that matters Every website has to do two things: manage content and deliver pages. The whole difference between the architectures lies in **when** the page comes into being. With a traditional CMS it comes into being **on request**. Someone types in your address, a server starts a program, the program asks a database for texts and images, assembles a page from them and sends it back. That happens again on every request, unless a cache steps in. With a headless setup it comes into being **beforehand**. All pages are built once, completely, and stored as files. A visitor receives a finished file — at that moment there is no program computing anything and no database that has to look anything up. ::plain-words A traditional CMS is a restaurant: you order, then the cooking starts. A static setup is a bakery in the morning: everything is already there, you take it with you. The restaurant can do more — it cooks to your wishes. The bakery is faster, cheaper to run and does not fail when the stove gives out. :: Almost everything else follows from that. What computes nothing on request needs no server that runs permanently, no database that has to be backed up, and no plugin that needs a security update on Tuesday. ## Four architectures In practice I meet four setups. Three of them deliver finished pages and differ only in **where the editors work**. The fourth is the traditional route. ### A — Content as files in the project ::flow-diagram --- steps: - label: Editor or developer note: edits texts and data as files tone: primary - label: Git repository note: website code and content live together and are versioned - label: Automatic build note: files and templates become finished HTML, CSS and JS files - label: Edge delivery note: the visitor receives finished files from the nearest data centre tone: secondary branches: - label: No backend in normal operation note: Between visitor and website there is no database and no program that has to compute first. tone: muted caption: No public CMS backend, no database on page request. The drawback sits in the last editorial step — there is no familiar editing interface. label: ARCHITECTURE A title: Fully static, without a separate CMS --- :: Content lives as text files in the same project as the website. It is the simplest conceivable setup: nothing runs permanently, everything is versioned, every change is traceable like a code change — including the option of taking it back. The price: there is no editing interface. Whoever changes texts works in files. For a one-pager, a campaign page or documentation with rare changes that is no problem. For an editorial team that publishes daily, it is one. ### B — The same basis, plus a visual editor ::flow-diagram --- steps: - label: Editors note: edit texts and images visually in the browser tone: primary - label: Editor with login note: runs server-side, with OAuth and an allow list branches: - label: No longer pure static hosting note: The login part needs a platform that can run server-side code. That is the point a quote has to list separately. tone: warn - label: Commit to the repository note: the visual change becomes a versioned file change - label: Automatic build note: the pages are rebuilt - label: Edge delivery note: normal page visits stay static tone: secondary caption: "The content stays as files in the repository — the editor just writes them instead of someone editing them by hand. Important for the quote: the editor login needs a server-side route, so it is more than pure file hosting." label: ARCHITECTURE B title: Static in front, visual editor behind --- :: This variant keeps all the advantages of A and removes its only real drawback: the editors work visually in the browser, but saving still happens as a versioned file. You are looking at this architecture right now — the page you are reading is run exactly this way. The catch is small, but it deserves mention because it regularly gets lost in quotes: the editor’s login runs server-side. “Static website” and “visual editor” do not exclude each other, but the combination is no longer pure file hosting. [3] ### C — A real headless CMS behind it ::flow-diagram --- steps: - label: Editors note: work in the CMS — with roles, drafts, approvals and media management tone: primary - label: CMS with database and media storage note: the system of record for all content - label: Publish webhook note: an approval starts the website build branches: - label: Drafts trigger nothing note: Unfinished content stays internal and appears nowhere publicly. tone: muted - label: Build reads only approved content note: through the CMS API - label: Edge delivery note: finished pages, without a CMS call on visit tone: secondary caption: The editors work in a full interface with roles, drafts and media management. Visitors normally never reach this system. label: ARCHITECTURE C title: Static in front, structured backend behind --- :: As soon as several people work editorially, roles and approvals become necessary, or content is structured — news, products, locations, several languages — this is the right setup. The CMS is a full editorial environment. The website in front of it still stays static. What matters here is sizing: the server behind the CMS has to carry the editors and the build, not the visitor traffic. An article that makes the evening news adds nothing to the load on the CMS server. ### D — The traditional route ::flow-diagram --- steps: - label: Editors note: work directly in the running system tone: primary - label: Visitor requests a page - label: CDN or cache note: answers whatever is cached tone: secondary branches: - label: Cache miss, login or dynamic function note: The request goes on to the server — and there, computing happens. tone: warn - label: PHP application with theme and plugins note: assembles the page - label: Database note: supplies the content branches: - label: Has to run permanently note: PHP, database, plugins and admin remain necessary — even if a CDN absorbs a great deal. tone: warn caption: A CDN relieves the public, cacheable pages considerably. But it replaces neither PHP nor the database nor the admin interface — those have to keep running. label: ARCHITECTURE D title: Traditional Drupal or WordPress --- :: A traditional CMS is not outdated, and it does not deserve to be talked down. Drupal, for instance, ships a mature page cache that also works for logged-in users. [4] That improves performance considerably — but it does not change the basic architecture: a PHP and database origin remains necessary for the system, with the requirements the vendor itself names: PHP 8.3+, MySQL 8.0+ or MariaDB 10.11+ and a web server. [2] ## The short version without jargon ::compare-table --- columns: - label: Question - label: Static (A–C) - label: Traditional (D) rows: - - Does a server have to assemble the page for every visitor? - No - Often yes, when there is no cache hit - - Does a normal page visit need a database? - No - Yes - - Can editors change content without a developer? - From variant B on, yes - Yes - - Where does ongoing server effort arise? - Building and delivering - CMS, PHP, database, plugins, cache and visitor traffic - - What happens on an error while publishing? - The current version stays online - The change takes effect immediately in the running system - - What has to be updated regularly? - The website code - CMS core, theme, plugins, PHP and database caption: “Static” here means architectures A to C. They differ in the editing, not in the delivery. label: DECISION AID title: The four questions that make the difference --- :: The second-to-last row is the one that is worth the most in everyday work and appears least often in comparisons. With the static variants, a new version only becomes public once it has been **built completely and without errors**. If something goes wrong during the build, the old website stays online and the team gets an error message. With a traditional CMS, publishing changes the running system directly. ## Cloudflare or your own server? Usually both A misunderstanding I hear often: that you have to choose between an edge provider such as Cloudflare and a server of your own. With architectures B and C that is not an either-or question. Cloudflare delivers the public website worldwide. The small server of your own carries only the CMS, the editors, media and builds. As a result the backend server **does not have to grow with the visitor traffic** — it is sized for a handful of editors, not for tens of thousands of readers. For static files, Cloudflare Pages charges no request fees on either the free or the paid plan, according to its own documentation; only dynamic execution falls under a usage model. [1] With a traditional CMS the same CDN can be placed in front, and that pays off too. Only, underneath it an origin remains that has to keep running. ## Why I prefer headless I come from the frontend. That shapes the answer, which is why I state it as a position, not as a law of nature. **I get control over what I stand for.** With a traditional CMS the system dictates the structure of the page, and a theme works against it. With headless I determine the markup completely. Load time, accessibility and behaviour on a phone are then genuinely my responsibility — and not that of a plugin someone wrote six years ago. **The attack surface shrinks to almost nothing.** What executes nothing on request cannot be compromised on request either. There is no login form on the public website, no plugin chain and no database reachable from outside. **Content becomes auditable.** Every change is a traceable version with author and timestamp. “Who changed the price, and when?” is no longer detective work. **Operations become boring** — and for infrastructure that is the greatest compliment. There is no maintenance window in which the core is updated and the site is unreachable for a quarter of an hour. ## When I still recommend a traditional CMS When an organisation has worked with Drupal or WordPress for years and has processes, training and extensions there, a migration is a project with risk and without immediate benefit for the users. The honest advice then is: do not migrate. Put a CDN in front, measure the load time, and only change something when a concrete limit actually blocks you. Likewise when a website is heavily dynamic — user accounts, personalised views, a shop with live stock. Then something has to be computed on request, and an architecture that avoids exactly that is the wrong choice. The point is not that headless always wins. The point is that the question “does something have to run on every visit?” comes before the choice of tool — and that it can be answered without expert knowledge. # What “static” really means — and why a build step belongs in between When I say in a first conversation that the website will be delivered statically, the same question almost always follows: “So I can’t change anything any more?” You can. You can change everything, at any time, yourself. The word is simply badly chosen. ## What “static” actually means It does not describe how often the content changes. It describes **when the page comes into being**. On a dynamic website, every page is created at the moment someone requests it. A program starts, queries a database, assembles text, images and menu, and sends the result back. On a static website the page is already finished before the first visitor knows about it. It is delivered like an image or a PDF — there is nothing left to compute. ::plain-words Picture two bakeries. In the first, every loaf is baked only when someone orders it — so the oven has to be hot all the time, someone has to be there constantly, and twenty customers at once make things tight. In the second, the baking happens in the morning, and after that there is only selling. Twenty customers at once are no problem, because nobody has to bake any more. Static means: bake in the morning. Not: never bake again. :: ## What happens when you change a text? This is exactly where the difference sits, and it is worth seeing it once, step by step. ::flow-diagram --- steps: - label: You change a text note: in the editor, the way you know it from any other editorial system tone: primary - label: You click “Publish” branches: - label: As long as you do not click, nothing happens note: A draft stays internal. It triggers no build and is not visible publicly anywhere. tone: muted - label: The build job starts automatically note: triggered by the approval, not by a person - label: The website is rebuilt completely note: templates and approved content become every page as a finished file branches: - label: If something goes wrong during the build note: The current website stays online unchanged. Nothing breaks, and you get an error message. tone: warn - label: The new version goes live note: it is distributed worldwide to the delivery points tone: secondary - label: Visitors see the new state caption: The sequence is the same for every change, whether you correct a comma or create a new page. Between the click and the live version there are typically one to three minutes. label: PUBLISHING title: From the change to the live version --- :: Two things about this sequence are unfamiliar, and both are advantages. **First, there is a wait.** One to three minutes until a change is visible. With a traditional CMS it is there immediately. That sounds like a disadvantage, and in exactly one case it is one: when you have to take a false statement off the web within seconds. **Second, a half-finished version is never made public.** A new version only goes live once it has been built **completely and without errors**. If the build breaks — a broken image, a dead link, a syntax error in a template — the old website simply stays online. On a dynamic system a problematic change takes effect directly in live operation. That is the difference between “I broke the website” and “my change didn’t go through, let me look again”. ## What this concretely buys ::compare-table --- columns: - label: Area - label: Dynamic - label: Static rows: - - Response time - Server has to compute, database has to answer - Finished file, straight from the nearest location - - Traffic peaks - More visitors means more computing load - More visitors means more file delivery - - Attack surface - Login, database and extensions are publicly reachable - There is nothing public that executes code - - Running costs - Server, database, backups, maintenance - Delivery, often within the free tier - - Maintenance effort - System core, extensions, language version, database - The website code - - Error while publishing - Takes effect immediately in the running system - The old version stays online caption: The last row is the one that is worth the most in everyday work and appears least often in comparisons. label: EFFECT title: What the build step actually changes --- :: The cost row deserves an honest framing, because it is often exaggerated. For static files, Cloudflare Pages charges no request fees on either the free or the paid plan, according to its own documentation; only dynamic execution falls under a usage model. [1] That does not mean “a website for zero francs” — domain, e-mail, a possible CMS backend and maintenance still cost money. It means that the line item “server that delivers your website” realistically approaches zero for smaller sites. The maintenance row is the one I consider more important. A traditional system permanently needs a current language version, a current database and a web server [3] — plus extensions, each with its own update rhythm. Every one of these components is a place where an unpatched vulnerability can stand open unnoticed for months. ## The one real stumbling block So that nobody leaves this article with a wrong impression: there is one thing that genuinely has to be handled differently with static websites. The build has to **know which pages to build**. With a fixed page structure that is a non-issue. But as soon as content from a CMS creates new addresses — a new blog post, a new product page, a new location — the build process has to be able to determine those addresses. [2] In practice this is set up once and then runs. It is still the point where badly built projects show: when a new page appears in the CMS but an error page sits under its address, that is precisely the cause. ::plain-words Translated: the bakery has to know which kinds of bread to bake in the morning. If someone adds a new kind to the range without telling the bakehouse, it is on the menu but not on the shelf. That is a setup mistake, not a fundamental problem — but you should know this spot exists, so that you can ask about it. :: ## When I advise against it Static is not an end in itself. As soon as every page has to look different for every visitor, the calculation tips. Concretely: user accounts with personal data, a shopping cart with live stock, a booking calendar with availability accurate to the second, an internal application behind a login. There, something has to be computed on request, and then an architecture designed to avoid exactly that is the wrong tool. The most common case in practice, though, is a mixed one: a static website with a single dynamic part inside it — a contact form, a search, a chat. That is no contradiction. It only means that a small, clearly delimited part runs on the server, while the other 95 percent of the pages are delivered ready-made. This website is built exactly that way. # Which CMS is fit for AI-assisted development? Almost every CMS now advertises AI. Mostly that means a button that writes a product text. That is nice and, for choosing a system, almost meaningless. The question that counts is a different one: **Can an AI collaborate reliably in this system without someone cleaning up afterwards?** And that is decided not by the editor but by three unspectacular properties. ## What makes a CMS fit for AI work **The data model exists as code.** When the structure — which content types exist, which fields they have, what is mandatory — sits in the repository instead of only in a web interface, a model can read it, check it and change it. A change becomes a traceable proposal that a person looks at before it takes effect. **The interface is typed.** Sanity generates types from schema and queries [3], Payload and Keystone define the model in TypeScript anyway [4] [5], Hygraph and Prismic generate types from GraphQL. The effect is the same: a field name that does not exist is noticed immediately — not three weeks later on the live site. **Write permissions can be narrowly limited.** Directus and Strapi now offer native agent access via MCP, with dedicated users, existing permission boundaries and logging. [1] [2] That is the foundation — not the finished solution, more on that below. ::plain-words The difference can be put without jargon. A CMS with its schema in code hands the AI a **blueprint**. A CMS without one hands it a **photo of the finished house** and asks it to plan an extension. In the first case it can calculate. In the second it guesses — and with language models, guessing looks just as convincing as knowing. :: ## The ranking ::bar-compare --- groups: self: Self-hosting possible saas: SaaS / hybrid items: - label: Sanity value: 4.45 group: saas - label: Payload value: 4.35 group: self - label: Strapi value: 4.2 group: self - label: Directus value: 4.15 group: self - label: Builder.io value: 4.05 group: saas - label: Storyblok value: 3.85 group: saas - label: TinaCMS value: 3.85 group: self - label: Keystone value: 3.85 group: self - label: Hygraph value: 3.8 group: saas - label: Plasmic value: 3.75 group: saas - label: DatoCMS value: 3.75 group: saas - label: Kontent.ai value: 3.3 group: saas - label: Contentful value: 3.3 group: saas - label: Prismic value: 3.2 group: saas - label: Drupal value: 3.1 group: self - label: Ghost value: 2.65 group: self - label: WordPress value: 2.55 group: self max: 5 caption: "Overall score from eight weighted criteria: schema in code, API typing, Storybook suitability, visual editing, agent access, editorial usability, operating effort and lock-in risk. An expert assessment, not a measurement — the order is more reliable than the second decimal." label: RATING title: Suitability for AI-assisted development unit: /5 --- :: Four systems pull ahead, and for four different reasons. **Sanity** leads because typing and queries work together exceptionally well, and generated types reach all the way into the query. [3] The price is SaaS: the content lives with the vendor, and the bill grows with editors and data volume. **Payload** is the answer for teams that want to review the data model in the repository. The schema is TypeScript, a model change is a pull request. [4] Whoever works close to TypeScript anyway gets the most control here. **Strapi** and **Directus** sit close behind and are the two I choose most often for Swiss SME projects: self-hosting is real self-hosting, the editorial interface is usable without training, and both have documented agent access. [1] [2] [5] Directus builds on SQL and can be laid over an existing database; Strapi is the more classic route with a model of its own. At the other end stands **WordPress** — and that is no verdict on WordPress as a publishing system. For this article’s question it simply lacks what matters: the model lives in the database, the interface is untyped, and the permission management is not built to give an automated access a narrow slice. ## The rating in detail ::compare-table --- columns: - label: Platform - label: Operation - label: Schema in code numeric: true - label: API typing numeric: true - label: AI agents numeric: true - label: Operating effort (1 = low) numeric: true - label: Lock-in (1 = low) numeric: true - label: Overall numeric: true max: 5 rows: - - Sanity - SaaS - 5 - 5 - 3 - 1 - 3 - 4.45 - - Payload - Self-hosted / cloud - 5 - 5 - 3 - 2 - 1 - 4.35 - - Strapi - Self-hosted / cloud - 4 - 4 - 5 - 3 - 2 - 4.2 - - Directus - Self-hosted / cloud - 3 - 4 - 5 - 3 - 1 - 4.15 - - Builder.io - SaaS - 3 - 3 - 5 - 1 - 4 - 4.05 - - Storyblok - SaaS - 3 - 4 - 2 - 1 - 3 - 3.85 - - TinaCMS - Self-hosted / cloud - 5 - 4 - 2 - 4 - 1 - 3.85 - - Keystone - Self-hosted - 5 - 5 - 2 - 3 - 1 - 3.85 - - Hygraph - SaaS - 4 - 5 - 2 - 1 - 3 - 3.8 - - Plasmic - SaaS / hybrid - 4 - 3 - 3 - 2 - 3 - 3.75 - - DatoCMS - SaaS - 4 - 5 - 2 - 1 - 3 - 3.75 - - Kontent.ai - SaaS - 3 - 4 - 2 - 1 - 4 - 3.3 - - Contentful - SaaS - 3 - 4 - 2 - 1 - 4 - 3.3 - - Prismic - SaaS - 4 - 3 - 1 - 1 - 3 - 3.2 - - Drupal - Self-hosted / managed - 3 - 3 - 2 - 4 - 1 - 3.1 - - Ghost - Self-hosted / managed - 2 - 3 - 1 - 2 - 1 - 2.65 - - WordPress - Self-hosted / managed - 2 - 2 - 1 - 3 - 2 - 2.55 caption: "All individual criteria 1–5. Mind the last two columns: there a lower value is the better one. They deliberately carry no bar — a bar that fills up as things get “worse” misleads." label: CRITERIA title: How the scores come about --- :: ## How I let agents near a CMS That a system ships agent access does not mean it should be used the way it is delivered. Directus documents dedicated users, existing permissions, an audit log and a global delete protection for MCP. [1] Strapi ships MCP disabled by default and binds tokens to the owner’s permissions. [2] Both are good foundations — and foundations are not a house. I work with a fixed permission ladder, independent of the system: ::compare-table --- columns: - label: Environment - label: Agent permissions - label: Permitted actions rows: - - Local - Full — on test and sample data - Explore the model, generate test data, run tests - - Preview / staging - Read and write drafts, within a defined slice - Create drafts, check fields, inspect the preview - - Production - Read-only by default - On request a narrowly limited, logged correction after approval - - Production — excluded - None - Deleting, bulk changes, roles and credentials, schema migrations, publishing without review caption: "The last row is the most important and the least comfortable: it excludes precisely the automations that impress most in a sales conversation." label: SECURITY title: What an agent may do where --- :: Plus four rules I consider non-negotiable: **Small, verifiable changes instead of direct interventions.** An AI produces a proposal with schema, type and component changes in a branch. It changes nothing directly in the running system. **Preview instead of publishing.** Agents write into drafts. What becomes public is decided by a person — always. **Tests as the boundary.** No merge without type checking, component tests and accessibility checks. That is not bureaucracy but the place where the typed interface actually pays off. **Traceability.** Every change carries who triggered it, when, and on which instruction. If nobody can reconstruct why a price changed, the automation is a risk, not a tool. ## The workflow I use for it ::flow-diagram --- steps: - label: A person writes a short specification note: purpose, permitted variants, mandatory fields, limits for text lengths, accessibility requirements tone: primary - label: The agent builds in a branch of its own note: schema, types, mappers, component, sample data and several component states - label: Automatic checks note: types, linting, component tests, accessibility, visual differences branches: - label: Check failed note: The proposal goes back before a person even looks at it. tone: warn - label: A person reviews preview and content model note: not only whether it works — also whether the model will still hold in a year tone: primary - label: Promotion to staging - label: Publishing by a person note: the agent can create drafts and sample data, not publish tone: secondary caption: The human review stages are deliberately two — one for the code, one for the content model. The second is easily forgotten, and that is exactly where the model errors arise that you cannot get rid of a year later. label: WAY OF WORKING title: A new content type, from idea to production --- :: ## What I do not do with it I do not let an AI publish content on its own. Not because that would be technically difficult, but because it produces the same class of errors as an unsupervised intern with full access — only faster and more convincingly worded. I also do not let an AI run schema migrations in production. A model error is the most expensive kind of error in a CMS, because it silently writes itself into the data and only shows once a thousand entries have been created with it. And I do not build a prompt-to-UI setup without a fixed component library behind it. Builder.io and Plasmic can bind generated sections to registered components [6] — that is precisely where the value lies. Without that registration, no design system emerges but a growing collection of similar-looking one-offs that nobody can change centrally any more. The honest conclusion: AI speeds up work on a CMS considerably — but only where the structure is already right. It does not replace the decision of what the content model should look like. It makes that decision more important, because it grows into far more records far faster.