Technologie, die Websites und Software schneller, sicherer und langfristig wartbar macht.
Next.js, React und TypeScript im Frontend. .NET und Node im Backend. Azure, CI/CD und Observability im Betrieb. LLM-Integration, RAG und Guardrails für KI. Jede Wahl ist begründet — nicht modisch.
- Next.js · React · TypeScript
- .NET · ASP.NET Core · Node · PostgreSQL
- Azure · Docker · GitHub Actions · Observability
- LLM · RAG · Vector DBs · Evaluation · Guardrails
Stack-Entscheidungen sind Geschäftsentscheidungen — nicht Geschmackssache.
Die Wahl der Technologie bestimmt, wie schnell Ihre Website lädt, wie sicher Ihre Daten liegen, wie einfach Ihr Team das System weiterentwickelt — und wie teuer es in fünf Jahren noch ist. Wir behandeln Stack-Wahl wie eine Architekturfrage: dokumentiert, begründet, reversibel. Diese Seite zeigt, mit welchen Werkzeugen wir Websites, Web-Apps, Desktop- und Mobile-Anwendungen sowie KI-Integrationen bauen — und warum.
Für wen diese Technologie-Seite gedacht ist.
Wir schreiben hier für Leser, die Stack-Entscheidungen bewerten — nicht nur Marketing lesen. Wenn Sie eine der folgenden Rollen tragen, finden Sie hier konkrete Antworten.
CTOs und Tech Leads
Sie bewerten, ob unser Stack zu Ihrem Engineering-Team passt: hinsichtlich Hiring, bestehender Systeme, Build-Pipelines und langfristiger Wartbarkeit. Sie wollen verstehen, warum wir uns wo festgelegt haben.
Head of Digital / Produkt
Sie verantworten ein Produkt oder eine Plattform und brauchen einen Partner, der nicht nur „cool“ baut, sondern in zwei Jahren noch wartbar liefert — mit Pfaden, die Ihr Team übernehmen kann.
Geschäftsführung mit technischem Anspruch
Sie kennen die Folgen schlechter Stack-Entscheidungen: hohe Kosten für Wartung, schwieriges Hiring, fragile Systeme. Sie wollen einen Partner, der diese Kosten ernst nimmt.
Interne Engineering-Teams
Sie wollen, dass externe Module sauber in Ihr Repository passen, dokumentiert sind und Ihrem Coding-Standard folgen. Wir liefern Architektur und Code, der von Ihrem Team weitergetragen werden kann.
Typische Probleme im Stack — und wie wir sie vermeiden.
Die meisten Stack-Probleme entstehen nicht durch falsche Tools, sondern durch fehlende Entscheidungen. Folgendes sehen wir am häufigsten — und so gehen wir damit um.
Logo-Wand statt Architektur
Stacks, die als Sammlung beliebter Logos präsentiert werden, lassen sich später nicht warten. Wir definieren ein klares Architektur-Zentrum (Next.js + TypeScript + .NET oder Node + PostgreSQL) und ergänzen nur, was wirklich nötig ist.
Versteckte Lock-ins
Plattformen, die einfach starten, werden teuer, sobald man wachsen will (Custom-CMS, proprietäre Builder, undurchsichtige Hosting-Plattformen). Wir bevorzugen Stack-Bausteine mit klarer Exit-Strategie.
Hiring-Sackgassen
Exotische Sprachen oder Frameworks führen dazu, dass das Projekt nach Launch personell stillsteht. Wir wählen Technologien (Next.js, React, TypeScript, .NET, Node, PostgreSQL), für die Sie problemlos jemand neuen einstellen können.
Sicherheits- und Compliance-Fragen werden zu spät gestellt
DSGVO, Datenresidenz, Rollen- und Rechtemodell, Audit-Trails — wir klären diese Themen in der Architekturphase, nicht im Audit kurz vor Launch.
KI ohne Datenstrategie
LLMs werden eingebaut, ohne dass jemand sagt, welche Daten reingehen, was rausdarf, wie evaluiert wird und wer haftet. Wir bauen KI-Integrationen mit Datenklassifikation, Evaluation und Guardrails — nicht als Tech-Demo.
Performance- und SEO-Probleme nach Launch
Schlechte Hydration, fehlende Bildoptimierung, riesige Bundles — meistens das Resultat fehlender Architekturentscheidungen. Wir setzen Performance- und SEO-Budgets von Anfang an und prüfen sie in CI.
Der p24.co-Stack im Überblick.
Sechs Bausteine, die zusammenpassen. Jeder Block ist austauschbar, sobald ein begründeter Grund dafür existiert — aber nicht aus Mode.
Web-Frontend · Next.js, React, TypeScript
Next.js (App Router) mit React und TypeScript als Standard für Websites und Frontends von Web-Apps. SSR/SSG für SEO, semantisches HTML, WCAG-AA-orientierte Komponenten, klar definierte Tokens und ein Designsystem. Performance-Budgets gegen Core Web Vitals, Bilder über next/image, klare Caching-Strategie. Optional Astro, wenn Inhalte überwiegen und JS-Last minimal sein muss.
Backend · .NET / Node, APIs, DB, Auth, Rollen
.NET / ASP.NET Core, wenn Domänenlogik, Langlebigkeit und Windows-/Enterprise-Integration zählen. Node (TypeScript), wenn Frontend und Backend nahe zusammen leben oder ein schlanker Service reicht. PostgreSQL als Standard-DB, Migrations im Repo, REST oder GraphQL je nach Konsumenten. Auth über etablierte Provider (z. B. Azure AD, Auth0, eigene OIDC), Rollen- und Rechtemodell explizit modelliert.
Cloud & DevOps · Azure, Docker, CI/CD, Observability
Azure als Standard-Cloud (mit klarem EU-Region-Setup), Docker für reproduzierbare Container, GitHub Actions für CI/CD mit Quality Gates (Tests, Linting, Typecheck, Bundle-Größe). Mehrere Environments (dev/stage/prod), Infrastructure-as-Code wo sinnvoll, Logs/Metriken/Tracing über etablierte Werkzeuge, dokumentierte Backup- und Restore-Strategie.
KI-Stack · LLM-Integration, RAG, Evaluation, Guardrails
OpenAI- und kompatible LLM-APIs als Standardpfad, lokale/EU-Optionen für sensible Daten. RAG mit Vector-DBs (z. B. pgvector, Qdrant) für Firmenwissen. Evaluation-Suite (Goldset, Regression, Fehlerklassen) statt Bauchgefühl. Guardrails (Prompt-Filter, Output-Validierung, Rate-Limits, Logging) und klare Datenflüsse: was geht raus, was bleibt drin.
Mobile & Desktop · PWA, React Native, .NET / WPF
PWA für Web-Apps, die sich „App-like“ anfühlen sollen, ohne App-Store-Aufwand. React Native, wenn echte Native-Funktionen oder Store-Präsenz nötig sind. .NET / WPF für Windows-Desktop-Software in Enterprise-Kontexten oder Spezialanwendungen. Wir wählen den Kanal nach Use-Case, nicht nach Trend.
Architekturprinzipien · Wartbarkeit, Sicherheit, Kosten
Domain-orientierte Modularisierung, klare Schichten zwischen UI, Anwendungslogik und Persistenz. Tests als Vertrag (Unit für Logik, Integrations- und E2E-Tests für kritische Pfade). Sicherheitsmodell explizit dokumentiert (Auth, Rollen, Secrets, Backups). Kosten als Architektur-Faktor: wir vermeiden Setups, die im Erfolgsfall überproportional teuer werden.
Begleitende Artefakte
Architecture Decision Records (ADRs), Diagramme zu Datenflüssen und Auth, dokumentierte Deployments, Performance- und SEO-Budgets, Test- und Backup-Strategie. Nach Launch übergebbar an Ihr Team oder an einen anderen Partner — Stack-Wahl ohne Lock-in.
So entscheiden wir Stack- und Architekturfragen.
Wir folgen einer Reihe von Entscheidungskriterien, damit Stack-Entscheidungen nicht aus Mode entstehen, sondern aus Ihrem Geschäftskontext.
- 01
1. Use-Case und Lebensdauer klären
DiscoveryBevor wir über Tools sprechen: Wie lange soll dieses System leben? Wer wartet es nach Launch? Welche Lasten und Datenmengen erwarten wir? Diese Fragen bestimmen mehr als jeder Stack-Trend.
output → Anforderungs- und Lebensdauer-Profil - 02
2. Hiring- und Team-Realität prüfen
ArchitekturphaseWelche Sprachen und Frameworks kennt Ihr internes Team? Wie schwer ist es, jemand neuen zu finden? Wir bevorzugen Stack-Bausteine, für die ein großer Talentpool existiert — nicht Exoten ohne Hiring-Pfad.
output → Hiring- und Maintenance-Risiko-Bewertung - 03
3. Sicherheits- und Compliance-Rahmen setzen
ArchitekturphaseDSGVO, Datenresidenz, Rollen- und Rechtemodell, Audit-Trails, Backups, Secrets-Management — bevor wir Code schreiben. Wir definieren einen Sicherheits- und Datenfluss-Plan, der die Architektur prägt.
output → Sicherheits- und Datenfluss-Plan - 04
4. Performance- und SEO-Budget setzen
Designsystem & BuildWir definieren Core-Web-Vitals-Ziele, Bundle-Größen, Antwortzeiten und SEO-Annahmen. Diese Budgets werden in CI überwacht — nicht erst im Audit gemessen.
output → Performance- & SEO-Budget - 05
5. Architecture Decision Record je signifikanter Wahl
LaufendJede wesentliche Stack-Wahl wird kurz schriftlich dokumentiert: Kontext, Alternativen, Entscheidung, Konsequenzen. So bleibt nachvollziehbar, warum etwas so ist — auch zwei Jahre später, auch wenn p24.co nicht mehr im Projekt ist.
output → ADRs im Repository - 06
6. KI-Integration mit Datenklassifikation und Evaluation
KI-ArchitekturVor dem ersten LLM-Call: Welche Daten dürfen rein? Welche Antworten sind akzeptabel? Wie evaluieren wir Qualität? Wir bauen Goldset, Guardrails und Logging-Pfade — nicht nur Prompts.
output → KI-Datenflussplan · Evaluations-Suite - 07
7. Operations- und Übergabe-Plan
Vor LaunchBevor wir live gehen: Wer betreibt das System? Wer rotiert Secrets? Wer wacht über Logs und Backups? Wir liefern einen Operations-Plan und einen Hand-off-Plan, damit Stack-Verantwortung eindeutig zugeordnet ist.
output → Operations- und Hand-off-Plan
Architekturprinzipien, die wir konsequent anwenden.
Diese Prinzipien sind keine Folien — sie zeigen sich in Repos, Architekturdiagrammen und CI-Konfigurationen unserer Projekte.
Wartbarkeit vor Cleverness
Lesbarer, etablierter Code schlägt elegante Tricks. Wir bauen so, dass eine Entwicklerin in drei Jahren ohne uns weitermachen kann.
Modularität mit klaren Grenzen
Domain-orientierte Module mit expliziten Schnittstellen. Frontend, Anwendungslogik und Persistenz bleiben sauber getrennt — Tests werden dadurch tragfähig.
Sicherheit als Default, nicht Add-on
Auth-Flows, Secrets-Management, Datenfluss-Klassifikation, Logging und Backups gehören zur Mindestlieferung. Wer Sicherheit erst nach Launch denkt, kommt zu spät.
Performance und SEO als Engineering-Disziplin
Core Web Vitals, semantisches HTML, technische SEO, Accessibility (WCAG AA) — wir behandeln diese Themen wie funktionale Anforderungen, nicht wie Marketing-Beigaben.
Hiring-Pfad als Architekturkriterium
Wir wählen Stack-Bausteine, für die ein großer Talentpool existiert. So bleibt Ihr Projekt unabhängig von einzelnen Personen.
Kosten als Architektur-Faktor
Wir bauen Setups, die im Erfolgsfall skalieren, ohne überproportional teuer zu werden. Cloud-Auswahl, Caching-Strategie und Datenmodell werden gemeinsam mit dem Budget gedacht.
Wie wir mit Technologie-Verantwortung umgehen.
Sie arbeiten direkt mit dem Gründer und einer kleinen Engineering-Crew — keine Architektur-Schicht, die Folien malt, während andere Code schreiben. Wir nennen Risiken früh, schreiben Entscheidungen schriftlich nieder und liefern einen Stack, den Sie selbst weiterführen können.
- 01Sie sprechen direkt mit Engineering — nicht mit Vertrieb über Engineering.
- 02Architekturentscheidungen werden in ADRs dokumentiert — nicht in Köpfen behalten.
- 03Wir sagen „nein“ zu unnötigen Lock-ins, exotischen Tools und Hype-getriebenen Wahlen.
- 04Stack-Wahl und Sicherheitsmodell sind im Repository sichtbar — nicht nur in Slides.
- 05Wir kommunizieren in Deutsch, Englisch oder Russisch — was für Ihr Team natürlich ist.
- 06Nach Launch bekommt Ihr Team alles, was es braucht, um den Stack eigenständig weiterzuführen.
Häufige Fragen zu Stack und Architektur.
Warum Next.js als Standard für Websites und Frontends?
Next.js (App Router) deckt SSR, SSG und ISR ab, hat starke Defaults für SEO und Performance, ein großes Ökosystem und einen sehr breiten Talentpool. Für Inhaltsseiten ist das SEO-Verhalten gut, für Frontends von Web-Apps die Komponenten- und Datenfluss-Architektur sauber. Für rein statische Inhalte mit minimalem JS ziehen wir Astro in Betracht.
Warum .NET im Backend — und nicht ausschließlich Node?
.NET / ASP.NET Core ist stark in Domänenmodellierung, Langlebigkeit und Integration mit Windows-/Enterprise-Welten, in denen viele unserer Auftraggeber zuhause sind. Node (TypeScript) verwenden wir, wenn Frontend und Backend nahe zusammen leben oder wenn ein schlanker Service ausreicht. Beide Optionen sind etabliert und wartbar.
Welche Datenbank wählt ihr typischerweise?
PostgreSQL als Standard — relational, robust, ausgereift und mit pgvector auch für KI-Use-Cases nutzbar. Bei spezifischen Anforderungen (Volltextsuche im Großmaßstab, Vector-Search mit hohem Volumen, Time-Series) ergänzen wir gezielt um spezialisierte Stores.
Wie geht ihr mit Auth, Rollen und DSGVO um?
Auth über etablierte Provider (z. B. Azure AD, Auth0, eigenes OIDC), Rollen und Rechte werden explizit modelliert und im Code sichtbar, nicht im UI versteckt. Für DSGVO klären wir Datenresidenz (häufig Azure West Europe), Verarbeitungsverträge, Logging mit Personenbezug, Löschkonzepte und Audit-Trails. Diese Punkte landen im Architekturdokument, nicht erst im Audit.
Wie ist euer Cloud-/DevOps-Setup aufgebaut?
Azure als Standard-Cloud mit klarem EU-Region-Setup, Docker für reproduzierbare Container, GitHub Actions für CI/CD inklusive Tests, Linting, Typecheck und Bundle-Budgets. Mehrere Environments (dev/stage/prod), dokumentierte Deployments, Logs/Metriken/Tracing, Backup- und Restore-Plan. Wenn Sie bereits AWS oder GCP nutzen, passen wir uns an — Cloud ist kein Selbstzweck.
Wie bindet ihr KI / LLM sicher ein?
Vor dem ersten LLM-Call definieren wir: Welche Daten dürfen reingehen? Welche Antworten sind akzeptabel? Wie wird Qualität gemessen? Wir bauen RAG über Firmenwissen, eine Evaluation-Suite (Goldset, Regressions-Tests), Guardrails (Prompt-Filter, Output-Validierung, Rate-Limits) und Logging. Bei sensiblen Daten prüfen wir EU-/lokale LLM-Optionen.
Wann macht eine PWA Sinn, wann React Native, wann .NET-Desktop?
PWA, wenn das Erlebnis web-nah bleibt, schnelle Updates wichtig sind und Store-Präsenz nicht zwingend. React Native, wenn echte Native-Funktionen, Offline-Verhalten oder Store-Präsenz nötig sind. .NET / WPF, wenn Windows-Integration, langlebige Spezial-Anwendungen oder Enterprise-Deployment im Vordergrund stehen. Wir wählen den Kanal nach Use-Case und Nutzerverhalten, nicht nach Trend.
Wie stellt ihr sicher, dass der Stack auch ohne euch wartbar ist?
Durch drei Dinge: etablierte Technologien mit großem Talentpool, dokumentierte Architekturentscheidungen (ADRs) und einen strukturierten Hand-off mit Wartungsleitfaden, Architekturdokumentation und reproduzierbaren Deployments. Sie können das System mit eigenem Team weiterführen — oder mit einem anderen Partner.
Könnt ihr in einen bestehenden Stack einsteigen?
Ja. Wenn Sie bereits Next.js, React, .NET, Node, PostgreSQL, Azure oder vergleichbare Technologien nutzen, dockt unsere Arbeit direkt an. Bei Legacy-Systemen starten wir mit einem Architektur-Audit und schlagen einen schrittweisen Modernisierungspfad vor — keine Big-Bang-Rewrites.
Was, wenn ihr eine Technologie nicht im Stack habt, die wir brauchen?
Dann sagen wir das offen. Wir nehmen Projekte nicht an, nur um sie zu nehmen. Wenn ein anderer Partner technisch besser passt (z. B. tiefe iOS-Native-Expertise, sehr spezielle Industrie-Software), empfehlen wir das ehrlich — und unterstützen ggf. nur in der Architekturphase.
Verwandte Leistungen und Themen
Lassen Sie uns Ihre Architektur ehrlich einordnen.
Schreiben Sie kurz, was Sie heute betreiben — und was Sie als Nächstes vorhaben. Wir sortieren in einem ersten Gespräch, wo der Stack stabil ist, wo Risiken liegen und welche nächsten Schritte Ihnen wirklich helfen. Direkt vom Gründer, ohne Vertriebsschicht.