Question 1

Next.js oder reines React?

Accepted Answer

Reines React (mit Vite) ist top für interne Tools und Dashboards, wo SEO egal ist und alles clientseitig rendert. Next.js ist der bessere Default für öffentliche Produkte, weil es serverseitiges Rendering, statische Generierung, Routing und Bildoptimierung mitbringt — alles hilft SEO und First-Load-Tempo. Wir wählen danach, ob Sichtbarkeit in der Suche und schneller First Paint für Sie Priorität haben.

Question 2

Warum ist TypeScript im Frontend wichtig?

Accepted Answer

TypeScript fängt eine ganze Bug-Klasse — undefinierte Werte, falsche Props, abweichende API-Formen — zur Build-Zeit statt in der Produktion. Bei jedem Projekt mit mehr als einem Entwickler oder mehr als ein paar Monaten Lebensdauer zahlt sich der Aufwand schnell durch weniger Laufzeitfehler und sicherere Refactors aus. Wir nutzen es durchgängig, inklusive typisierter API-Antworten, damit UI und Backend synchron bleiben.

Question 3

Was sind Core Web Vitals und warum sollte ich mich kümmern?

Accepted Answer

Core Web Vitals sind Googles UX-Metriken: Largest Contentful Paint (Laden), Interaction to Next Paint (Reaktivität) und Cumulative Layout Shift (visuelle Stabilität). Sie sind ein echter Ranking-Faktor und korrelieren stark mit Conversion — langsame Seiten verlieren Nutzer. Wir zielen auf grüne Werte durch Bildoptimierung, Code-Splitting, Reduktion von Layout-Shift und minimiertes JavaScript auf dem kritischen Pfad.

Question 4

Wie machen Sie eine Seite barrierefrei?

Accepted Answer

Wir bauen nach WCAG 2.1 AA: semantisches HTML, volle Tastaturnavigation, ausreichender Farbkontrast, Fokus-Management und korrektes ARIA nur dort, wo native Elemente nicht reichen. Wir testen mit automatisierten Tools und echten Screenreadern, denn automatische Checks finden vielleicht die Hälfte der Probleme. Barrierefreiheit verbessert zudem SEO und Usability für alle, nicht nur für Menschen mit Behinderung.

Question 5

Welches State-Management soll ich nutzen?

Accepted Answer

Die meisten Apps brauchen weit weniger globalen State als angenommen. Wir trennen Server-State — Daten aus Ihrer API — gehandhabt von React Query oder SWR mit eingebautem Caching, vom echten Client-State wie UI-Toggles, gehandhabt von einem leichten Store wie Zustand. Redux ist für große, komplexe Apps weiterhin eine gute Wahl, aber per Default danach zu greifen, bringt meist unnötigen Boilerplate.

Question 6

Wie lange dauert ein Frontend-Build?

Accepted Answer

Eine Marketing-Site oder Landingpage läuft 2–4 Wochen; eine vollständige App-UI mit vielen Screens, komplexem State und Integrationen 2–4 Monate. Die größten Treiber sind die Zahl einzigartiger Screens, wie poliert die Interaktionen sein müssen und ob ein Design-System bereits existiert oder parallel zum Produkt entstehen muss.

Question 7

Können Sie ein bestehendes Figma-Design exakt umsetzen?

Accepted Answer

Ja — pixelgenaue Umsetzung ist für uns Standard, inklusive responsivem Verhalten, das das Design vielleicht nur an ein, zwei Breakpoints zeigt. Wir markieren, wo ein Design Performance oder Barrierefreiheit schadet, und schlagen Alternativen vor, denn ein schöner Mockup, der ein 5-MB-Hero-Bild ausliefert oder Kontrast-Checks reißt, ist nicht wirklich fertig. Enge Zusammenarbeit mit Ihrem Designer hält Fidelity und Qualität hoch.

Question 8

Übernehmen Sie SEO im Frontend?

Accepted Answer

Frontend-SEO ist ein großer Teil unserer Arbeit: serverseitiges Rendern oder statisches Generieren von Inhalten, damit Crawler sie sehen, korrektes semantisches Markup und Metadaten, strukturierte Daten (JSON-LD), schnelle Core Web Vitals und saubere URLs. Wir legen das technische SEO-Fundament; Content-Strategie und Linkaufbau sind eigene Disziplinen, aber wir stellen sicher, dass die Seite technisch ranking-bereit ist.

Frontend-Entwicklung
FAQ

Hilfreiche
Informationen

Erste Schritte

Zeitplan

Preisgestaltung

Support

Noch Fragen?

Frontend-EntwicklungFAQ

HilfreicheInformationen