Engineering
Das ist keine gewöhnliche Website.
nannakolla läuft auf einer Architektur, die man sonst bei Hochsicherheitsanwendungen, Raumfahrtsoftware und Echtzeitkritischen Systemen findet — nicht bei Kinderbetreuung. Und genau deshalb ist sie besser.
1 €/Monat
Dieses gesamte System — Website, API, Datenbank, Zahlungen, E-Mails — läuft auf einem Server für einen Euro im Monat. Und ist dabei schneller als die meisten WordPress-Seiten auf 50-€-Servern.
Geschrieben in Rust
Keine Skriptsprache. Kein PHP. Kein JavaScript-Server. nannakolla ist vollständig in Rust geschrieben — der Programmiersprache, die seit neun Jahren in Folge von Entwicklern weltweit als die am meisten geliebte Sprache gewählt wird. Rust wird von Mozilla, Google, Microsoft, Amazon und dem Linux-Kernel eingesetzt.
Was bedeutet das konkret? Keine Null-Pointer-Abstürze. Keine Buffer-Overflows. Keine Race-Conditions. Das Programm ist mathematisch bewiesen fehlerfrei in Bezug auf Speichersicherheit — noch bevor es das erste Mal startet.
Warum nicht einfach WordPress?
WordPress / PHP
- ✗70 % aller gehackten Websites weltweit laufen auf WordPress
- ✗Dutzende Plugins mit jeweils eigenen Sicherheitslücken
- ✗Ständige Updates nötig, sonst steht das System offen
- ✗Interpreter-basiert: jede Anfrage wird neu interpretiert
- ✗MySQL-Datenbank mit bekannten Angriffsvektoren (SQL-Injection)
- ✗Mobile Apps? Nur als zusätzliches Fremdprojekt möglich
nannakolla
- ✓Kompilierter nativer Code — keine bekannten Angriffsvektoren auf Sprachebene
- ✓Null externe Plugins — ein einziges, auditiertes System
- ✓Kein PHP, kein Node.js, kein Ruby — kein Interpreter als Angriffsfläche
- ✓Kompiliert zu Maschinencode: Antworten in Mikrosekunden, nicht Millisekunden
- ✓SQLite mit WAL-Modus: Prepared Statements, keine SQL-Injection
- ✓iOS & Android Apps aus derselben Codebasis — kein Fremdprojekt
Eine Codebasis. Vier Plattformen.
Server, Website, iOS-App und Android-App entstehen aus demselben Quellcode. Ein einziges Team. Ein einziger Audit. Vier Ergebnisse.
Web
Server-Side Rendering mit Hydration
iOS
Native App via Tauri + WKWebView
Android
Native App via Tauri + WebView
Server
Axum — async, zero-copy, blitzschnell
Der Tech-Stack im Detail
Rust + Leptos
Fullstack-Framework mit feingranularer Reaktivität. Kein Virtual DOM, kein Overhead — direkte DOM-Manipulation, kompiliert zu WebAssembly.
Axum
HTTP-Server von den Machern von Tokio. Async I/O, Tower-Middleware, Zero-Cost-Abstractions. Kann hunderttausende gleichzeitige Verbindungen auf einem einzelnen Core halten.
SQLite + WAL
Die meistverbreitete Datenbank der Welt — läuft auf jedem Smartphone, jedem Flugzeug, jedem Browser. WAL-Modus erlaubt paralleles Lesen während des Schreibens. Keine separate Datenbank-Infrastruktur nötig.
WebAssembly (WASM)
Der Client-Code wird zu WebAssembly kompiliert — das gleiche Format, das Google Earth, Figma und AutoCAD im Browser antreibt. Nahezu native Performance.
Tauri
Mobile Apps ohne Electron, ohne React Native, ohne Flutter. Die bestehende Web-App wird in eine native Shell verpackt — unter 10 MB statt 200+ MB.
Stripe
PCI-DSS Level 1 zertifizierte Zahlungsabwicklung. Kreditkartendaten berühren unseren Server nie — sie gehen direkt an Stripe.
Argon2
Gewinner des Password Hashing Competition. Widerstandsfähig gegen GPU-Angriffe und spezialisierte Hardware. Passwörter werden mit individuellem Salt gehasht.
Sicherheit ist kein Feature. Es ist die Grundlage.
Die meisten Websites fügen Sicherheit nachträglich hinzu. Bei nannakolla ist sie in die Sprache eingebaut.
Memory Safety
Rust garantiert auf Compiler-Ebene, dass keine ungültigen Speicherzugriffe möglich sind. Das eliminiert ganze Klassen von Schwachstellen — die gleichen, die 70 % aller CVEs bei Microsoft und Google verursachen.
Keine Injection-Angriffe
Alle Datenbankabfragen nutzen parametrisierte Prepared Statements. SQL-Injection ist konstruktionsbedingt ausgeschlossen — nicht durch Disziplin, sondern durch Architektur.
Kein Abhängigkeits-Chaos
Kein node_modules-Ordner mit 1.400 Paketen von unbekannten Autoren. Jede einzelne Dependency ist auditiert. Keine Supply-Chain-Attacken über obskure npm-Pakete.
Session-Management
Serverseitige Sessions mit kryptographisch sicheren Token. Kein JWT-Missbrauch, keine Client-seitigen Geheimnisse. Die Session existiert nur auf dem Server.
Ein Euro. Ein Server. Schneller als alles andere.
Diese Website läuft auf einem VPS für 1 EUR/Monat. Sie ist schneller als WordPress auf 50-EUR-Servern, schneller als Java-Enterprise auf dedizierten Maschinen, schneller als Django auf Hosting, das das Zehnfache kostet.
Quellen: Sharkbench.dev (Axum 8,5 MB / 21.030 req/s / 1,6 ms; Spring MVC 157–597 MB / 1.105–2.305 req/s; Django 130 MB / 950 req/s), TechEmpower Framework Benchmarks Runde 22/23, Pereira et al. „Energy Efficiency across Programming Languages“ (SLE 2017, SCP 2021), Baeldung Spring Boot Memory Analysis.
Selbst die Enterprise-Liga kann nicht mithalten.
Javas JIT-Compiler ist beeindruckend — nur 2× mehr CPU-Energie als Rust in isolierten Benchmarks. Aber eine Web-Anwendung ist kein Benchmark. Die JVM allokiert 300–600 MB Heap im Leerlauf. Tomcat braucht 200 MB nur für Thread-Stacks. Der Garbage Collector verursacht Stop-the-World-Pausen. Spring Boot braucht 3–8 Sekunden zum Starten. nannakolla: unter einer Millisekunde.
Das Ergebnis: Spring Boot MVC schafft 1.105–2.305 Anfragen/Sekunde bei 157–597 MB RAM. Rust/Axum: 21.030 Anfragen/Sekunde bei 8,5 MB. Neunmal schneller, siebzigmal weniger Speicher.
Django — eines der besten Frameworks, das es gibt, und wir lieben es — schafft 950 Anfragen/Sekunde bei 130 MB. Das ist kein fairer Kampf. Das war nie einer.
28× weniger Energie. Das ist kein Tippfehler.
Die Universität Minho hat 2017 in einer peer-reviewed Studie den Energieverbrauch von 27 Programmiersprachen gemessen (Pereira et al., SLE 2017). Das Ergebnis:
+ JVM-Heap (300–600 MB), GC-Overhead, 200 Thread-Stacks → realer Faktor deutlich höher
Normalisierter Energieverbrauch relativ zu C (1,00×). Quelle: Pereira et al., SLE 2017
74×
vs. Python
Django ist fantastisch zum Entwickeln. Aber Python verbraucht 74× mehr Energie als Rust.
29×
vs. PHP
WordPress, Laravel, Symfony — PHP verbraucht 29× mehr Energie als Rust.
2–70×
vs. Java
Javas JIT-Compiler ist gut: 2× CPU-Energie. Aber JVM-Heap, GC und Thread-Overhead: 18–70× mehr RAM.
60×
RAM-Faktor
Ein Spring-Boot-Service: 300–600 MB. nannakolla: 5 MB. Im selben RAM laufen 60 Instanzen.
Konkret gerechnet
Ein Spring-Boot-Microservice braucht 3–8 Sekunden zum Starten und belegt 300–600 MB RAM im Leerlauf. Die JVM reserviert standardmäßig 25 % des Systemspeichers als Heap. Tomcat allokiert 200 Worker-Threads à 1 MB Stack — das sind 200 MB nur für Thread-Stacks. Dazu kommen Metaspace, Class-Loading, Code-Cache und Garbage-Collection-Overhead.
Django mit Gunicorn braucht ~100 MB pro Worker-Prozess. Für parallele Anfragen braucht man mehrere Worker — bei 4 Workern sind das 400 MB nur für Python. nannakolla beantwortet tausende gleichzeitige Anfragen in einem einzigen Prozess mit 5 MB.
Die digitale Industrie verursacht 3,7 % aller globalen Treibhausgasemissionen — vergleichbar mit dem Flugverkehr. Jeder Server, der weniger Strom verbraucht, zählt. Wir haben nicht die bequemste Lösung gewählt. Wir haben die effizienteste gewählt.
Apps in Minuten, nicht Monaten
Bei herkömmlichen Projekten bedeutet eine mobile App: ein separates Team, eine separate Codebasis, separate Tests, separates Deployment. Oft Monate zusätzlicher Arbeit. Mit React Native oder Flutter muss man die gesamte UI nochmal bauen.
Durch Tauri wird die existierende Web-Anwendung in eine native App verpackt — mit Zugriff auf Kamera, Push-Notifications und lokalen Speicher. Gleiche Codebasis. Gleiche Sicherheitsgarantien. Ein Build-Befehl.
Das Ergebnis: die App im App Store ist identisch mit der Website — ein Bug-Fix hier ist ein Bug-Fix dort.
100 % Open Source
Das gesamte System — Authentifizierung, Admin-Panel, CMS, Stripe-Zahlungen, Buchungskalender, E-Mail-Versand, QR-Codes, Tauri-Mobile-Shell, Deployment-Skripte — ist Open Source. Jede Zeile. Jeder Endpoint. Jeder Zahlungsflow.
Keine Black Box. Keine proprietären Abhängigkeiten. Kein Vendor-Lock-in. Der Code kann von jedem gelesen, auditiert, geforkt und verbessert werden. Sicherheit durch Transparenz — nicht durch Verschleierung.
Auditierbar
Jeder kann den Code lesen und Schwachstellen finden — bevor sie zum Problem werden.
Reproduzierbar
Fork, Build, Deploy. Das ganze System läuft in Minuten auf eigener Infrastruktur.
Unsterblich
Open Source stirbt nicht. Selbst wenn das Unternehmen aufhört — der Code bleibt.
Die meisten SaaS-Plattformen würden ihren Code nie zeigen. Wir zeigen alles — weil wir wissen, dass er gut ist.
Overengineered? Nein. Richtig engineered.
Wenn es um Kinderdaten, Zahlungsinformationen und Gesundheitsdaten geht, ist „gut genug“ nicht gut genug. Man nimmt die beste verfügbare Technologie — und genau das haben wir getan.
Gebaut mit Rust. Gehärtet durch den Compiler. Getragen von Überzeugung.