Wie läuft ein typisches Webprojekt bei IT-stent ab?

Zuerst klären wir Ziele, Zielgruppe und bestehende Systeme (Discovery). Danach folgen ein schriftliches Angebot mit Umfang und Meilensteinen, die eigentliche Umsetzung in Iterationen sowie ein strukturierter Go-live mit Übergabe oder optionaler Betreuung. So bleiben Erwartungen und Verantwortlichkeiten durchgängig nachvollziehbar.

Brauchen wir ein Lastenheft, bevor wir starten können?

Ein vollständiges Lastenheft ist selten nötig. Ausreichend sind meist Ziele, Beispiele, Prioritäten und offene Fragen zu CMS, Schnittstellen und Hosting. Wo Lücken sind, arbeiten wir sie gemeinsam in Workshops oder Schriftverkehr heraus und dokumentieren Beschlüsse nachvollziehbar.

Wie gehen Sie mit sich ändernden Anforderungen um?

Kleine Präzisierungen fließen in den laufenden Sprint bzw. die nächste Iteration. Größere neue Features behandeln wir als Change Request: kurz abgeschätzt, bepreist und bewusst eingeplant. So bleibt der ursprüngliche Scope schützbar, ohne dass Verbesserungsideen unter den Tisch fallen.

Wie oft sprechen wir uns während der Umsetzung?

Das richtet sich nach Projektlage: oft reicht eine feste wöchentliche oder zweiwöchentliche Abstimmung plus asynchrone Updates (E-Mail, Ticket, kurze Loom-Notizen). In intensiven Phasen kann die Frequenz steigen – wichtig ist eine klare Ansprechperson auf Kundenseite und bei uns im Studio.

Was bedeutet „Abnahme“ in der Praxis?

Abnahme heißt: definierte Kriterien sind erfüllt (z. B. Kern-User-Flows, CMS-Editor, technische Checks). Wir dokumentieren offene Punkte als Tickets mit Priorität. Go-live erfolgt erst, wenn kritische Punkte geschlossen sind oder ausdrücklich als bekannt akzeptiert wurden.

Kann das Projekt in Phasen (MVP) finanziert werden?

Ja. Wir schneiden Releases so, dass ein nutzbarer MVP zuerst live geht – etwa Relaunch mit reduziertem Funktionsumfang oder API zuerst, UI später. Jede Phase hat klare Deliverables und Budgetrahmen, damit Sie früh Wert sehen und weiter investieren können.

Wer pflegt Inhalte nach dem Relaunch?

Redaktion und fachliche Inhalte liegen in der Regel bei Ihnen; wir liefern Templates, Schulungsnotizen und saubere Editor-Workflows im CMS. Auf Wunsch begleiten wir die ersten Wochen mit kurzen Check-ins oder übernehmen kleinere technische Nachziehjobs.

Wie dokumentieren Sie Architektur- und Projektentscheidungen?

Je nach Vereinbarung: kurze ADRs oder Wiki-Artikel, README im Repository, und für Schnittstellen OpenAPI oder vergleichbare Beschreibungen. Ziel ist, dass Ihr Team oder ein Drittanbieter später ohne Ratespiel weiterarbeiten kann.

Was passiert nach dem Go-live?

Wir prüfen Monitoring-Hooks, Caching, Redirects und kritische Formulare. Danach stehen Übergabe, Wartungsoption oder Übergabe an Ihr Team. Viele Kunden buchen ein kleines Kontingent für Folgereleases oder Security-Updates – das klären wir vor dem Launch.

Arbeiten Sie mit unseren Agenturpartnern zusammen?

Ja, wenn Rollen klar sind: Designlieferung, SEO-Briefing oder Brand-Artefakte kommen von Partnern, wir integrieren technisch und abstimmen Schnittstellen. Regelmäßige kurze Syncs verhindern, dass sich Design und technische Machbarkeit auseinanderlaufen.

TYPO3 oder Drupal – wie entscheiden wir?

Entscheidend sind Redaktions-Workflows, Rollenmodelle, Mehrsprachigkeit, vorhandenes Know-how und langfristige Roadmaps. Wir empfehlen nicht „religiös“ eine Plattform, sondern vergleichen pragmatisch Aufwand, Risiken und Betriebskosten – inklusive Upgrade-Pfaden.

Was ist der Unterschied zwischen Headless-CMS und klassischem CMS-Betrieb?

Klassisch liefern CMS und Templates die komplette Website. Headless trennt Content-API und Frontend – ideal für SPAs, mehrere Kanäle oder stark individualisierte Oberflächen. Der Preis sind höhere Frontend-Kosten und klarere API-Verträge; wir helfen bei der Abwägung.

Wie migrieren wir Inhalte aus dem alten System?

Wir planen Mapping (Felder, Medien, URLs), Redirect-Strategie und ggf. automatisierte Import-Skripte oder redaktionelle Sprints. SEO-relevante URLs und Metadaten werden früh mitgedacht, damit Suchmaschinen und Bookmarks nicht verloren gehen.

Welche Rolle spielt Performance bei Relaunch-Projekten?

Ladezeit und Core Web Vitals beeinflussen Nutzererlebnis und SEO. Wir setzen auf schlanke Assets, sinnvolles Caching, moderne Bildformate und messen vor und nach dem Launch. Schwere Drittanbieter-Skripte werden bewusst priorisiert oder lazy geladen.

Wie bauen Sie APIs mit Laravel?

Wir modellieren Domänen sauber, versionieren öffentliche Endpunkte und schützen mit Auth, Rate-Limits und Validierung. OpenAPI-Dokumentation erleichtert Frontend- oder Partner-Integrationen. Wo nötig, ergänzen wir Admin-Oberflächen oder Queue-Jobs für Hintergrundarbeit.

Wann lohnt sich Vue.js statt reinem CMS-Templating?

Wenn Interaktion, Komponenten-Wiederverwendung oder eingebettete Apps stark sind – etwa Filter, Dashboards oder schrittweise Formulare. Für einfache Marketingseiten reicht oft klassisches Templating; wir empfehlen Vue dort, wo Wartbarkeit und UX langfristig profitieren.

Wie gehen Sie mit Barrierefreiheit um?

Wir berücksichtigen semantisches HTML, Tastaturbedienung, Kontraste und sinnvolle ARIA-Patterns im Rahmen des vereinbarten Umfangs. Für öffentliche Auftraggeber oder WCAG-Ziele definieren wir Testkriterien und prüfen mit Checklisten und Tools – kein „Sticker“, sondern Projektparameter.

Was gehört zu einem guten Git-Workflow?

Feature-Branches, aussagekräftige Merge Requests, Reviews und geschützte Hauptbranch. Wir verknüpfen Commits mit Tickets, damit Releases nachvollziehbar bleiben. Auf Wunsch richten wir Branch-Regeln und CI-Checks in GitLab ein.

Was macht eine sinnvolle GitLab CI/CD-Pipeline aus?

Sie baut bei jedem Merge Request zuverlässig, führt vereinbarte Tests aus und deployt gestuft (Staging/Production). Geheimnisse liegen in geschützten Variablen, Artefakte sind begrenzt. So wird Qualität wiederholbar statt abhängig vom „lokalen Glück“.

Warum End-to-End-Tests mit Cypress?

Cypress eignet sich gut für kritische Browser-Flows (Login, Checkout, Formulare) und lässt sich in CI einbinden. Wir pflegen stabile Selektoren, Testdaten-Strategien und vermeiden flaky Tests durch klare Wartebedingungen. Alternativen besprechen wir projektabhängig.

Wie sichern wir Deployments ab?

Staging-Umgebung, Datenbank-Backups vor Migrationen, Feature-Flags wo sinnvoll und ein Rollback-Plan für den Launch. Wir dokumentieren, welche Schritte manuell oder per Pipeline laufen – damit Nacht-Deployments nicht zum Ratespiel werden.

Übernehmen Sie Hosting und Domains?

Wir beraten zu Anforderungen (Traffic, Compliance, Region) und können Deployments vorbereiten. Oft bleiben Domain und Vertrag bei Ihnen oder einem Provider Ihrer Wahl; wir liefern die technische Checkliste und die Konfiguration für den Go-live.

Wie gehen Sie mit DSGVO und Formularen um?

Technische Maßnahmen wie TLS, Speicherminimierung und saubere Protokolle der Verarbeitung sind Standard. Rechtstexte und AV-Verträge klären Sie mit Ihrer Rechtsberatung; wir liefern die technischen Fakten (Logs, Speicherorte, Drittanbieter-Einbindungen).

Was sind typische Risiken bei CMS-Upgrades?

Veraltete Extensions, angepasste Core-Hacks oder inkompatible PHP-Versionen. Wir inventarisieren Extensions, setzen Staging-Kopien auf und planen einen staged Upgrade-Pfad mit Rollback. Zeitpuffer für unbekannte Abhängigkeiten einplanen ist Pflicht.

Wie priorisieren wir ein gemeinsames Backlog?

Wir sortieren nach Nutzen, Risiko und Aufwand, markieren Must-haves für den ersten Release und sammeln spätere Ideen in einem Icebox-Bereich. Transparente Tickets mit Akzeptanzkriterien reduzieren Missverständnisse zwischen Fachbereich und Entwicklung. Als Werkzeug reicht oft GitLab Issues; für viele Stakeholder kann ein Board in Jira oder Linear sinnvoll sein.

Wie schätzen Sie Aufwand und Termine?

Wir zerlegen Arbeit in überschaubare Pakete, nennen Annahmen explizit und puffern Unbekanntes ein. Festpreise sind möglich bei klar umrissenem Scope; bei Forschung oder Legacy empfehlen wir Budgetrahmen mit regelmäßiger Transparenz.

Was ist ein sinnvoller Umgang mit Drittanbieter-Skripten?

Jedes Skript kann Performance und Datenschutz belasten. Wir listen Skripte, prüfen Notwendigkeit und Ladezeit und setzen Consent-Mechanismen korrekt um. Technisch helfen async/defer, Tag-Manager-Disziplin und gezieltes Nachladen.

Wie bleibt das Frontend wartbar über Jahre?

Klare Komponentenstruktur, Linting, Tests für kritische Pfade und regelmäßige Dependency-Updates im Rahmen von Wartungsbudget. Wir vermeiden „einmalige“ Sonderlösungen ohne Doku und halten Build-Pipelines verständlich.

Können bestehende Design-Systeme übernommen werden?

Ja, wenn Tokens, Komponentenbibliothek und Lieferformate (Figma etc.) vorliegen. Wir mappen Design auf technische Komponenten und klären früh Abweichungen zwischen Design-Entscheid und CMS-Realität.

Wie starten wir am schnellsten?

Kurze Mail mit Ziel, ungefährem Zeitrahmen, Link zur bestehenden Website und wer entscheidet. Wir melden uns mit Rückfragen oder einem Terminvorschlag für ein Erstgespräch – oft reichen 30 Minuten, um passend weiterzumachen.

FAQ

Häufige Fragen zu Projekten & Webentwicklung

Antworten rund um Zusammenarbeit, CMS, Laravel, Frontend, Qualitätssicherung und Abläufe – kompakt formuliert, damit Sie schnell Orientierung gewinnen. Für Ihr konkretes Vorhaben sind wir gern im Kontakt.

Wie läuft ein typisches Webprojekt bei IT-stent ab?

Zuerst klären wir Ziele, Zielgruppe und bestehende Systeme (Discovery). Danach folgen ein schriftliches Angebot mit Umfang und Meilensteinen, die eigentliche Umsetzung in Iterationen sowie ein strukturierter Go-live mit Übergabe oder optionaler Betreuung. So bleiben Erwartungen und Verantwortlichkeiten durchgängig nachvollziehbar.
Brauchen wir ein Lastenheft, bevor wir starten können?

Ein vollständiges Lastenheft ist selten nötig. Ausreichend sind meist Ziele, Beispiele, Prioritäten und offene Fragen zu CMS, Schnittstellen und Hosting. Wo Lücken sind, arbeiten wir sie gemeinsam in Workshops oder Schriftverkehr heraus und dokumentieren Beschlüsse nachvollziehbar.
Wie gehen Sie mit sich ändernden Anforderungen um?

Kleine Präzisierungen fließen in den laufenden Sprint bzw. die nächste Iteration. Größere neue Features behandeln wir als Change Request: kurz abgeschätzt, bepreist und bewusst eingeplant. So bleibt der ursprüngliche Scope schützbar, ohne dass Verbesserungsideen unter den Tisch fallen.
Wie oft sprechen wir uns während der Umsetzung?

Das richtet sich nach Projektlage: oft reicht eine feste wöchentliche oder zweiwöchentliche Abstimmung plus asynchrone Updates (E-Mail, Ticket, kurze Loom-Notizen). In intensiven Phasen kann die Frequenz steigen – wichtig ist eine klare Ansprechperson auf Kundenseite und bei uns im Studio.
Was bedeutet „Abnahme“ in der Praxis?

Abnahme heißt: definierte Kriterien sind erfüllt (z. B. Kern-User-Flows, CMS-Editor, technische Checks). Wir dokumentieren offene Punkte als Tickets mit Priorität. Go-live erfolgt erst, wenn kritische Punkte geschlossen sind oder ausdrücklich als bekannt akzeptiert wurden.
Kann das Projekt in Phasen (MVP) finanziert werden?

Ja. Wir schneiden Releases so, dass ein nutzbarer MVP zuerst live geht – etwa Relaunch mit reduziertem Funktionsumfang oder API zuerst, UI später. Jede Phase hat klare Deliverables und Budgetrahmen, damit Sie früh Wert sehen und weiter investieren können.
Wer pflegt Inhalte nach dem Relaunch?

Redaktion und fachliche Inhalte liegen in der Regel bei Ihnen; wir liefern Templates, Schulungsnotizen und saubere Editor-Workflows im CMS. Auf Wunsch begleiten wir die ersten Wochen mit kurzen Check-ins oder übernehmen kleinere technische Nachziehjobs.
Wie dokumentieren Sie Architektur- und Projektentscheidungen?

Je nach Vereinbarung: kurze ADRs oder Wiki-Artikel, README im Repository, und für Schnittstellen OpenAPI oder vergleichbare Beschreibungen. Ziel ist, dass Ihr Team oder ein Drittanbieter später ohne Ratespiel weiterarbeiten kann.
Was passiert nach dem Go-live?

Wir prüfen Monitoring-Hooks, Caching, Redirects und kritische Formulare. Danach stehen Übergabe, Wartungsoption oder Übergabe an Ihr Team. Viele Kunden buchen ein kleines Kontingent für Folgereleases oder Security-Updates – das klären wir vor dem Launch.
Arbeiten Sie mit unseren Agenturpartnern zusammen?

Ja, wenn Rollen klar sind: Designlieferung, SEO-Briefing oder Brand-Artefakte kommen von Partnern, wir integrieren technisch und abstimmen Schnittstellen. Regelmäßige kurze Syncs verhindern, dass sich Design und technische Machbarkeit auseinanderlaufen.
TYPO3 oder Drupal – wie entscheiden wir?

Entscheidend sind Redaktions-Workflows, Rollenmodelle, Mehrsprachigkeit, vorhandenes Know-how und langfristige Roadmaps. Wir empfehlen nicht „religiös“ eine Plattform, sondern vergleichen pragmatisch Aufwand, Risiken und Betriebskosten – inklusive Upgrade-Pfaden.
Was ist der Unterschied zwischen Headless-CMS und klassischem CMS-Betrieb?

Klassisch liefern CMS und Templates die komplette Website. Headless trennt Content-API und Frontend – ideal für SPAs, mehrere Kanäle oder stark individualisierte Oberflächen. Der Preis sind höhere Frontend-Kosten und klarere API-Verträge; wir helfen bei der Abwägung.
Wie migrieren wir Inhalte aus dem alten System?

Wir planen Mapping (Felder, Medien, URLs), Redirect-Strategie und ggf. automatisierte Import-Skripte oder redaktionelle Sprints. SEO-relevante URLs und Metadaten werden früh mitgedacht, damit Suchmaschinen und Bookmarks nicht verloren gehen.
Welche Rolle spielt Performance bei Relaunch-Projekten?

Ladezeit und Core Web Vitals beeinflussen Nutzererlebnis und SEO. Wir setzen auf schlanke Assets, sinnvolles Caching, moderne Bildformate und messen vor und nach dem Launch. Schwere Drittanbieter-Skripte werden bewusst priorisiert oder lazy geladen.
Wie bauen Sie APIs mit Laravel?

Wir modellieren Domänen sauber, versionieren öffentliche Endpunkte und schützen mit Auth, Rate-Limits und Validierung. OpenAPI-Dokumentation erleichtert Frontend- oder Partner-Integrationen. Wo nötig, ergänzen wir Admin-Oberflächen oder Queue-Jobs für Hintergrundarbeit.
Wann lohnt sich Vue.js statt reinem CMS-Templating?

Wenn Interaktion, Komponenten-Wiederverwendung oder eingebettete Apps stark sind – etwa Filter, Dashboards oder schrittweise Formulare. Für einfache Marketingseiten reicht oft klassisches Templating; wir empfehlen Vue dort, wo Wartbarkeit und UX langfristig profitieren.
Wie gehen Sie mit Barrierefreiheit um?

Wir berücksichtigen semantisches HTML, Tastaturbedienung, Kontraste und sinnvolle ARIA-Patterns im Rahmen des vereinbarten Umfangs. Für öffentliche Auftraggeber oder WCAG-Ziele definieren wir Testkriterien und prüfen mit Checklisten und Tools – kein „Sticker“, sondern Projektparameter.
Was gehört zu einem guten Git-Workflow?

Feature-Branches, aussagekräftige Merge Requests, Reviews und geschützte Hauptbranch. Wir verknüpfen Commits mit Tickets, damit Releases nachvollziehbar bleiben. Auf Wunsch richten wir Branch-Regeln und CI-Checks in GitLab ein.
Was macht eine sinnvolle GitLab CI/CD-Pipeline aus?

Sie baut bei jedem Merge Request zuverlässig, führt vereinbarte Tests aus und deployt gestuft (Staging/Production). Geheimnisse liegen in geschützten Variablen, Artefakte sind begrenzt. So wird Qualität wiederholbar statt abhängig vom „lokalen Glück“.
Warum End-to-End-Tests mit Cypress?

Cypress eignet sich gut für kritische Browser-Flows (Login, Checkout, Formulare) und lässt sich in CI einbinden. Wir pflegen stabile Selektoren, Testdaten-Strategien und vermeiden flaky Tests durch klare Wartebedingungen. Alternativen besprechen wir projektabhängig.
Wie sichern wir Deployments ab?

Staging-Umgebung, Datenbank-Backups vor Migrationen, Feature-Flags wo sinnvoll und ein Rollback-Plan für den Launch. Wir dokumentieren, welche Schritte manuell oder per Pipeline laufen – damit Nacht-Deployments nicht zum Ratespiel werden.
Übernehmen Sie Hosting und Domains?

Wir beraten zu Anforderungen (Traffic, Compliance, Region) und können Deployments vorbereiten. Oft bleiben Domain und Vertrag bei Ihnen oder einem Provider Ihrer Wahl; wir liefern die technische Checkliste und die Konfiguration für den Go-live.
Wie gehen Sie mit DSGVO und Formularen um?

Technische Maßnahmen wie TLS, Speicherminimierung und saubere Protokolle der Verarbeitung sind Standard. Rechtstexte und AV-Verträge klären Sie mit Ihrer Rechtsberatung; wir liefern die technischen Fakten (Logs, Speicherorte, Drittanbieter-Einbindungen).
Was sind typische Risiken bei CMS-Upgrades?

Veraltete Extensions, angepasste Core-Hacks oder inkompatible PHP-Versionen. Wir inventarisieren Extensions, setzen Staging-Kopien auf und planen einen staged Upgrade-Pfad mit Rollback. Zeitpuffer für unbekannte Abhängigkeiten einplanen ist Pflicht.
Wie priorisieren wir ein gemeinsames Backlog?

Wir sortieren nach Nutzen, Risiko und Aufwand, markieren Must-haves für den ersten Release und sammeln spätere Ideen in einem Icebox-Bereich. Transparente Tickets mit Akzeptanzkriterien reduzieren Missverständnisse zwischen Fachbereich und Entwicklung. Als Werkzeug reicht oft GitLab Issues; für viele Stakeholder kann ein Board in Jira oder Linear sinnvoll sein.
Wie schätzen Sie Aufwand und Termine?

Wir zerlegen Arbeit in überschaubare Pakete, nennen Annahmen explizit und puffern Unbekanntes ein. Festpreise sind möglich bei klar umrissenem Scope; bei Forschung oder Legacy empfehlen wir Budgetrahmen mit regelmäßiger Transparenz.
Was ist ein sinnvoller Umgang mit Drittanbieter-Skripten?

Jedes Skript kann Performance und Datenschutz belasten. Wir listen Skripte, prüfen Notwendigkeit und Ladezeit und setzen Consent-Mechanismen korrekt um. Technisch helfen async/defer, Tag-Manager-Disziplin und gezieltes Nachladen.
Wie bleibt das Frontend wartbar über Jahre?

Klare Komponentenstruktur, Linting, Tests für kritische Pfade und regelmäßige Dependency-Updates im Rahmen von Wartungsbudget. Wir vermeiden „einmalige“ Sonderlösungen ohne Doku und halten Build-Pipelines verständlich.
Können bestehende Design-Systeme übernommen werden?

Ja, wenn Tokens, Komponentenbibliothek und Lieferformate (Figma etc.) vorliegen. Wir mappen Design auf technische Komponenten und klären früh Abweichungen zwischen Design-Entscheid und CMS-Realität.
Wie starten wir am schnellsten?

Kurze Mail mit Ziel, ungefährem Zeitrahmen, Link zur bestehenden Website und wer entscheidet. Wir melden uns mit Rückfragen oder einem Terminvorschlag für ein Erstgespräch – oft reichen 30 Minuten, um passend weiterzumachen.