Was kostet die Entwicklung einer App im Jahr 2026?
Eine App zu bauen kostet 2026 zwischen 15.000 € und 350.000 €+. Die Aufschlüsselung nach Komplexität, die echten Kostentreiber und laufenden Kosten.
Astro gibt es seit 2021. Neu ist es also nicht. Doch 2026 ist es das Framework, zu dem wir bei inhaltsstarken, performancekritischen Marketing-Websites am häufigsten greifen – aus Gründen, die mit der Reife des Frameworks immer deutlicher geworden sind.
Hier ist unsere ehrliche Einschätzung, nachdem wir in den letzten 18 Monaten mehrere Kunden-Websites mit Astro umgesetzt haben.
Astro ist ein Static Site Generator mit Komponentenarchitektur. Sein prägendes Merkmal ist die „Islands“-Architektur: Standardmäßig wird alles zu reinem HTML ohne jegliches JavaScript gerendert. Komponenten, die Interaktivität benötigen, werden explizit freigeschaltet – das sind die „Inseln“ in einem ansonsten statischen Ozean.
Das ist ein grundlegend anderes Modell als bei React/Next.js. In Next.js ist JavaScript standardmäßig überall, und Sie entscheiden sich mit Server Components gezielt für reines Server-Rendering. In Astro ist JavaScript standardmäßig nirgends, und Sie entscheiden sich gezielt für Interaktivität.
Bei einer Marketing-Website, die hauptsächlich aus Text, Bildern und Navigationsstruktur besteht, führt dieser Unterschied zu dramatischen Performance-Unterschieden.
Wir haben LCP- und Lighthouse-Benchmarks für vier vergleichbare Marketing-Websites durchgeführt: zwei mit Next.js (App Router, ISR, sorgfältig optimiert), zwei mit Astro (Content Collections, minimale Interaktivität). Ähnliche Inhalte, ähnliche Designkomplexität.
| Metrik | Next.js (optimiert) | Astro |
|---|---|---|
| LCP (mobil, 4G) | 1,4–2,1 s | 0,7–1,1 s |
| INP (Desktop) | 60–120 ms | 25–55 ms |
| CLS | 0,01–0,04 | 0,00–0,01 |
| Lighthouse (mobil) | 88–96 | 96–100 |
| JS-Bundle-Größe | 85–180 KB | 0–8 KB |
Der Unterschied bei der Größe des JavaScript-Bundles ist das deutlichste Signal. Eine Next.js-Marketing-Website liefert die React-Runtime plus Hydration plus Komponentenlogik aus. Eine Astro-Website liefert im Grunde nichts aus, solange Sie nicht explizit interaktive Komponenten hinzugefügt haben.
Das ist aus zwei Gründen wichtig:
Mobile Performance. Das Parsen von JavaScript ist CPU-intensiv. Auf Android-Smartphones der Mittelklasse (dem tatsächlichen Median-Mobilgerät, nicht Ihrem iPhone Pro) dauert das Parsen von 150 KB JavaScript beim Kaltstart 3–5 Sekunden. Eine Astro-Website mit 8 KB JavaScript ist mit dem Parsen in Millisekunden fertig.
SEO. Lighthouse-Werte über 95 lassen sich mit Astro durchweg leichter halten. Der Google-Crawler sieht bereits bei der ersten Anfrage vollständig gerendertes HTML, ohne dass Hydration nötig ist. Technisch entspricht das der statischen Generierung in Next.js, jedoch ohne das Risiko eines Rückfalls auf clientseitiges Rendering.
Astros Content Collections sind der Hauptgrund, warum wir bei inhaltsstarken Websites verstärkt darauf setzen.
Mit Content Collections definieren Sie typisierte Schemas für Ihre Markdown-/MDX-Inhalte:
// src/content/config.ts
import { defineCollection, z } from 'astro:content'
const blog = defineCollection({
type: 'content',
schema: z.object({
title: z.string(),
publishedAt: z.coerce.date(),
tags: z.array(z.string()),
category: z.enum(['Technology', 'Process', 'Strategy', 'Design']),
}),
})
Das bietet Ihnen:
Für einen Blog wie unseren, bei dem Dutzende Beiträge ein einheitliches Frontmatter brauchen, ist das deutlich besser, als Markdown-Dateien in Next.js manuell zu importieren und zu parsen.
Der größte Kostenfaktor bei Astro ist die fehlende Vertrautheit. Die meisten Entwickler kennen React. Astro hat eine eigene Komponentensyntax (.astro-Dateien), ein eigenes Denkmodell für Interaktivität und eigene Routing-Konventionen. Für ein Team, das es noch nie genutzt hat, bedeutet das erste Projekt eine Einarbeitungszeit von 1–2 Wochen.
Diese Investition zahlt sich aus, wenn:
Die Website Content-first ist. Wenn Sie eine Website mit über 20 Seiten, einem Blog, Case Studies und Dokumentation bauen, passt Astros Content-first-Architektur wirklich. Die Content Collections, das Routing und die MDX-Unterstützung sind genau für diesen Anwendungsfall ausgelegt.
Performance die wichtigste Anforderung im Briefing ist. Wenn ein Kunde ausdrücklich Lighthouse-Werte über 95, einen LCP unter 1 s und minimales JavaScript benötigt, ist Astro der schnellste Weg dorthin. Um diese Werte mit Next.js zu erreichen, ist deutlich mehr gezielte Optimierung nötig.
Die Website nur wenige dynamische Features hat. Login-Flows, nutzerspezifische Inhalte, Echtzeitdaten und serverseitige API-Aufrufe sind in Astro zwar möglich, aber nicht seine Stärke. Wenn Sie mehr als zwei oder drei interaktive Bereiche haben, prüfen Sie sorgfältig.
Das Team lernbereit ist. Das klingt selbstverständlich, ist aber das eigentliche Kriterium. Ein Team, das die Website nach der Übergabe pflegt, muss mit Astro sicher umgehen können. Arbeitet es ausschließlich mit React, ist Next.js für die Übergabe wahrscheinlich die bessere Wahl – selbst wenn Astro performanter wäre.
In diesen Fällen greifen wir statt zu Astro zu Next.js:
Die Marketing-Website teilt Komponenten mit einem Next.js-Produkt. Ein Designsystem, Authentifizierungslogik oder API-Clients zwischen Marketing-Website und App zu teilen, ist nur möglich, wenn beide im selben Framework laufen.
Dynamische Features sind zentral für das Briefing. Personalisierte Inhalte, authentifizierte Seiten, Echtzeitdaten oder komplexe Formularlogik – in Next.js ist das Standard, in Astro zusätzliche Komplexität.
Das Team des Kunden arbeitet primär mit React. Die Wartung nach dem Launch zählt. Eine Website, die das Team des Kunden pflegen und erweitern kann, ohne eigens jemanden für Astro einzustellen, ist mehr wert als eine geringfügig bessere Performance.
Der Zeitplan ist sehr knapp. Ein erfahrener Next.js-Entwickler liefert eine Marketing-Website schneller aus, als wenn er parallel zum Bauen Astro lernen müsste. Wenn Sie drei Wochen haben, nutzen Sie den Stack, den Sie in- und auswendig kennen.
Astro 5 (erschienen Ende 2025) hat mehrere Features eingeführt, die die Abwägung für einige Anwendungsfälle verändern:
Server Islands. Früher erforderte die Kombination aus servergerenderten und statischen Inhalten eine sorgfältige Architektur. Mit Server Islands können einzelne Komponenten serverseitiges Rendering nutzen, während der Rest der Seite statisch bleibt. Das ist die Lösung für das Problem „überwiegend statisch mit einem dynamischen Bereich“.
Verbessertes Adapter-Ökosystem. Die Adapter für Vercel, Netlify, Cloudflare und Node.js sind deutlich ausgereifter geworden. Das Deployment ist kein zentrales Kriterium mehr – Astro lässt sich überall zuverlässig deployen, wo auch Next.js läuft.
Actions. Astro verfügt nun über ein eigenes System für Formularverarbeitung und API-Actions, wodurch man bei formularlastigen Websites seltener auf Next.js zurückgreifen muss.
Diese Neuerungen haben die sinnvollen Einsatzbereiche von Astro deutlich erweitert. Websites, die für serverseitige Formularverarbeitung oder dynamische Inhalte früher Next.js gebraucht hätten, haben jetzt einen Astro-nativen Weg.
Für reine Marketing-Websites (Blog, Case Studies, statische Inhalte, minimale dynamische Features): Astro ist unsere erste Wahl. Die Performance-Gewinne sind messbar, und das Content-Collection-System ist wirklich überlegen.
Für Marketing-Websites mit dynamischen Features, mit einem Produkt geteilten Komponenten oder Teams, die in React pflegen werden: Next.js. Die Vorteile durch Vertrautheit und Ökosystem überwiegen Astros Performance-Vorsprung.
Für Websites, die wirklich inhaltsstark sind und maximale SEO-Performance brauchen: Astro, ohne zu zögern.
Die Lernkurve ist real, aber kurz. Wenn Performance im Briefing steht, lohnt sie sich.
Sie bauen eine Marketing-Website und fragen sich, ob Astro oder Next.js die richtige Wahl ist? Starten Sie ein Gespräch – wir sagen Ihnen, wofür wir uns bei Ihrem konkreten Briefing entscheiden würden und warum.
Wir nehmen jeden Quartal eine begrenzte Anzahl von Projekten an. Erzählen Sie uns, was Sie bauen.
Eine App zu bauen kostet 2026 zwischen 15.000 € und 350.000 €+. Die Aufschlüsselung nach Komplexität, die echten Kostentreiber und laufenden Kosten.
Der übliche Einwand lautet: „Es ist doch nur eine Broschüren-Website.“ Warum sich TypeScript auf einer Marketing-Website trotzdem auszahlt: durch CMS-Integration, Übergaben im Team und die Wartungsrealität zwölf Monate nach dem Launch.