Der neue Kontaktflow funktioniert in der Vorführung. Nach dem Release nimmt das sichtbare Formular jedoch Eingaben an, obwohl der Server sie verwirft. Das CMS hat ein Feld umbenannt, die Bestätigungsseite liest noch den alten Namen und niemand weiß, welcher Release zuletzt sicher zurückgesetzt werden konnte. Der Screen war freigegeben. Das System war es nicht.
Webentwicklung beginnt mit einer überprüfbaren technischen Lieferkette. Quellcode, Inhalte, Konfiguration, Abhängigkeiten, Umgebungen, Tests, Freigaben, Deployments und Betriebsbelege müssen denselben Stand meinen. Ohne diese Verbindung wird jede spätere Änderung zur Suche nach Wissen, das nur im Kopf der Agentur existiert.
DE-170 verwendet ein Build-Übergabedossier. Es enthält ein leeres Repositorymodell, drei abstrakte Umgebungen, ein synthetisches CMS-Schema, ein Formular ohne Personenangaben, zwei erfundene Releasekennungen und einen Recovery-Fall. Während der Probe wird ein Feld umbenannt, eine Abhängigkeit gesperrt und ein Release zurückgenommen.
Das Dossier setzt keine Designentscheidung neu. Seitenbaum, Komponenten, Zustände, Viewports, Texte, Assets und Zugänglichkeitsnotizen kommen als freigegebene Eingaben aus DE-169. Der Entwicklungspartner darf technische Alternativen melden, aber weder Hierarchie noch Fachinhalt oder visuellen Zustand stillschweigend verändern.
Sechs Anbieter dokumentieren auf offiziellen Seiten mindestens einen relevanten Website-, Entwicklungs- oder Betriebsumfang und einen Elektriker-, Electrical- oder Home-Service-Bezug. Die Reihenfolge misst nur die sichtbare Passung zum Dossier. Kein Anbieter wurde auf Codequalität, Sicherheit, Barrierefreiheit, Performance oder Betrieb geprüft.
theStacc veröffentlicht DE-170 und verkauft zugleich den auf Rang sechs aufgeführten Managed-Service, der laut eigener Seite Websites erstellt, hostet und verwaltet. Daraus entsteht ein wirtschaftlicher Interessenkonflikt. Das Herausgeberangebot erhielt keine garantierte Position und keinen Auslegungsbonus. Kein Anbieter bezahlte für Aufnahme oder Platz. Der Quellenstand vom 31. August 2026 enthält zwölf erreichbare Originalseiten. Anbieterbelege stammen von Contractor Gorilla, On Purpose Media, Rival Digital, Thrive Internet Marketing Agency, Hook Agency und theStacc. Rival ist mit einer allgemeinen Website-Design-Seite und einem eigenen Electrical-Angebot vertreten. Die technischen Referenzen liefern MDN, W3C, OWASP, web.dev und GitHub. Aus Anbieterquellen wurden nur selbst beschriebene Entwicklungs- und Betriebsgegenstände übernommen. Wir haben keinen Anbieter, Vertrag, Quellcode, Repository, Branch, Umgebung, Domain, CMS, Plugin, Paket, Formular, Datensatz, Schnittstelle, Deployment, Backup, Wiederherstellung, Monitoring, Website oder Ergebnis praktisch geprüft. Preise, Laufzeiten, Teamgröße, deutschsprachige Betreuung, Deutschland-Eignung, Elektrofachwissen, Datenschutz, Sicherheit, technische Qualität, Support und Resultate bleiben offen. Portfolios, Testimonials, Fallstudien, Auszeichnungen, Prozentangaben, Rankings, Geschwindigkeit, Verfügbarkeit, Traffic, Leads, Anrufe, Termine, Aufträge, Umsatz und Rendite wurden nicht bewertet. Das Build-Übergabedossier arbeitet ausschließlich mit erfundenen Repository-, Feld-, Seiten-, Formular-, Release- und Incidentkennungen sowie Messfeldern ohne Werte. Darin erscheinen keine reale Person oder Firma, keine Anschrift, Kontaktinformation, Baustelle, elektrische Anlage, Störung, Diagnose, Arbeitsanweisung, Qualifikation, Zulassung, Verfügbarkeit oder Kundendatei. DE-170 besitzt Codebasis, Repository, Entwicklungsumgebungen, CMS- und Datenmodell, Komponentenimplementierung, Formular- und Schnittstellenlogik, technische Zugänglichkeit, Performanceanforderungen, Abhängigkeiten, Tests, Release, Rollback, Monitoring, Backup, Restore, Dokumentation und technischen Exit. DE-169 besitzt Seitenarchitektur, visuelle Hierarchie, Wireframes, responsive Screens, Designzustände, Prototypen und Designquelldateien. DE-168 besitzt Kampagnen, Paid, E-Mail, Budgets, Marketingkonten und kanalübergreifende Messplanung. DE-165 bis DE-167 behalten SEO-, Local- und Social-Facharbeit. Ein namentlich verantwortlicher Entwicklungs- und Elektrofachreview, eine bestätigte deutsche Schlussredaktion sowie eine laufende technische Pflegeverantwortung fehlen. DE-170 trägt deshalb needs_human_review und ist nicht automatisch publikationsfähig.
Die kurze Antwort
Contractor Gorilla führt diesen Dokumentationsvergleich an, weil die Elektriker-Seite Websitebau, Hosting, SSL, Backups, Sicherheitsarbeit, Softwarepflege und Inhaltsänderungen gemeinsam nennt. Rival folgt mit Home-Service-Entwicklung, Hosting-, Performance- und Sicherheitsgegenständen plus Electrical-Bezug. On Purpose, Thrive, Hook und theStacc zeigen engere oder weniger konkrete Ausschnitte. Kein Rang belegt technische Qualität oder Sicherheit.
- Contractor Gorilla: Elektrofachbetriebe, die Build, Hosting, Backup, Sicherheitsarbeit, Updates und laufende Websitepflege in einem technischen Pilot prüfen wollen
- Rival Digital: Betriebe, die Websiteentwicklung, Hosting-, Ladezeit- und Sicherheitsarbeit mit einer ausdrücklichen Electrical-Leistung verbinden möchten
- On Purpose Media: Elektrofachbetriebe, die Mobile-first-Website, CMS-Pflege, Entwicklung, Inhalte und Abnahmetests gemeinsam beschaffen
- Thrive Internet Marketing Agency: Betriebe, die Neubau oder Wiederaufbau einer Elektriker-Website mit Content und technischer SEO bei einem Anbieter prüfen
- Hook Agency: Betriebe, die eine Elektriker-Website im selben Auftrag wie Landingpages und laufende Websiteänderungen umsetzen lassen
- theStacc: Betriebe, die Websiteerstellung und laufende organische Betreuung bündeln, aber ein eigenständiges technisches Dossier vertraglich ergänzen
Das Build-Übergabedossier bindet Code, Release und Wiederherstellung
Das Dossier beginnt mit einer Systemgrenze. Website-Frontend, CMS, Formulare, externe Dienste, Analytics, Hosting, Domain, E-Mail-Zustellung und Dateispeicher werden als getrennte Bausteine erfasst. Für jeden Baustein stehen Besitzer, Umgebung, Konfiguration, Datenklasse, Abhängigkeit, Testnachweis und Exitweg fest. Der Pilot verwendet keine reale Plattform.
Ein technischer Eingangsschein übernimmt das Designpaket aus DE-169. Seitenkennung, Komponente, Zustand, responsive Fassung, Textquelle, Assetquelle, Interaktionsregel, Zugänglichkeitsannotation, Freigabe und offene Frage bleiben referenziert. Kann eine Vorgabe nicht umgesetzt werden, entsteht eine Abweichung mit Alternative und Entscheidung, kein stiller Ersatz im Code.
Das Repository gehört als Arbeitsgegenstand in den Vertrag. GitHubs offizielle Dokumentation beschreibt ein Repository als Ort für Code, Dateien und deren Revisionsverlauf und verweist auf berechtigungsbasierten Zugriff. Der Pilot ist plattformneutral. Er verlangt institutionelle Kontrolle, Rollen, Branchregeln, Reviewweg, Releaseverknüpfung und Export, ohne eine bestimmte Plattform vorzuschreiben.
Umgebungen werden ausdrücklich getrennt. Lokal, Integration, Abnahme und Produktion erhalten eindeutige Konfigurationsklassen, Datenregeln, Zugriffsrollen, Veröffentlichungswege und Sperren. Im Dossier stehen nur leere oder erfundene Werte. Produktionsdaten dürfen nicht als bequeme Testfüllung in eine andere Umgebung kopiert werden.
Konfiguration und Geheimnisse gehören nicht in frei sichtbare Inhaltsfelder oder einen Screenshot. Das Dossier benennt nur Schlüsselklassen, Besitzer, Zielumgebung, Rotationsweg und Prüfstatus, nie echte Werte. Der Anbieter muss zeigen, wie eine Rolle entzogen und eine Konfiguration erneuert wird, ohne den Quellverlauf oder eine Kundendatei offenzulegen.
Das CMS-Modell übersetzt Inhalt in definierte Felder. Seitentyp, Leistungsname, Zusammenfassung, Kontaktoption, Gebietsklasse, Projektasset, Nachweisreferenz, Fachfreigabe und Ablaufstatus erhalten Typ, Pflichtstatus, Quelle, Validierung und Darstellung. Der Pilot enthält keine echten Leistungen. Ein fehlendes Feld soll die Ausgabe sicher begrenzen, nicht einen erfundenen Standardtext auslösen.
Migrationen werden als eigene Lieferungen behandelt. Ausgangsschema, Zielversion, Zuordnung, ungültige Einträge, Rückfallweg, Testbestand und Freigabe bleiben dokumentiert. Der synthetische Test benennt ein CMS-Feld um. Die Agentur muss abhängige Templates, Abfragen, Vorschauen, Exporte und Tests finden und den vorherigen Zustand wiederherstellen können.
Formulare benötigen Browser- und Serverpfad. MDN erklärt, dass clientseitige Validierung eine erste Prüfung und nützlich für die Bedienung ist, aber keine vollständige Sicherheitsmaßnahme. Übermittelte Daten sollen auch serverseitig validiert werden, weil der Client umgangen werden kann. DE-170 bindet diese Aussage an die offizielle MDN-Seite und testet nur synthetische Eingaben.
Der Formularvertrag führt Feldname, Label, erwartetes Format, erforderlichen Status, Clientfeedback, Serverentscheidung, Fehlerabbildung, Sendestatus, Bestätigung, Zielsystem, Aufbewahrungsfrage und Löschweg. Rechtliche Entscheidungen werden nicht erfunden. Datenschutz und tatsächliche Datenverarbeitung brauchen zuständige Fachprüfung vor jedem echten Einsatz.
Schnittstellen erhalten eigene Verträge. Anfrage, Antwort, Authentifizierungsklasse, Timeout, Wiederholung, Deduplizierung, Fehler, Protokollierung, Besitzer und Abschaltweg werden beschrieben. Der Pilot sendet keine Anfrage. Er prüft, ob ein ausgefallener externer Dienst eine verständliche sichere Websiteausgabe erzeugt und keine Buchung oder Zustellung vortäuscht.
Technische Zugänglichkeit wird gegen die konkrete Umsetzung geprüft. WCAG 2.2 enthält technologieunabhängige, testbare Erfolgskriterien und sieht automatisierte sowie menschliche Evaluation als Teil der Prüfung. Das Dossier verbindet jede relevante Anforderung mit Komponente, Seite, Testart, Ergebnis, Prüfer und Ausnahme. Eine Designannotation allein ergibt keine Konformität.
Semantik, Tastaturbedienung, Fokusreihenfolge, sichtbarer Fokus, Namen und Beziehungen, Fehlerrückmeldung, dynamische Statusmeldung, Medienalternative und Zoomverhalten werden an laufenden Builds geprüft. Automatisierte Werkzeuge können Befunde liefern. Eine namentlich verantwortliche menschliche Prüfung bleibt nötig, bevor eine Konformitätsaussage überhaupt erwogen wird.
Performance bekommt ein Budget und wiederholbare Bedingungen, keine einzelne beeindruckende Messung. web.dev ordnet unter anderem HTML, kritischen Renderingpfad, Ressourcenladen, Bilder, Video, Webfonts, JavaScript-Aufteilung und verzögertes Laden als Performancegegenstände ein. Das Dossier wählt relevante Budgets erst nach Projektklärung und erfindet keine Grenzwerte.
Jeder Performancebeleg nennt Build, Route, Umgebung, Gerätekategorie, Netzwerkprofil, Werkzeug, Zeitpunkt und Abweichung. Laborwerte, Felddaten und Geschäftsresultate bleiben getrennt. Dieser Artikel behauptet keine Ladezeit oder Verbesserung für einen Anbieter. Er fordert nur, dass ein gemessener Wert reproduzierbar an eine Fassung gebunden wird.
Sicherheitsanforderungen werden vor dem Test benannt. OWASP beschreibt ASVS als Grundlage zum Prüfen technischer Sicherheitskontrollen von Webanwendungen und als Liste von Anforderungen für sichere Entwicklung, auch für Beschaffungsverträge. DE-170 behauptet bei keinem Anbieter ASVS-Nutzung oder Erfüllung. Eine zuständige Sicherheitsprüfung muss Umfang und Version festlegen.
Abhängigkeiten erhalten Name, Quelle, Version, Lizenzstatus, Besitzer, Einsatzort, Aktualisierungsweg, bekannte Sperre und Entfernungspfad. Das Dossier enthält keine echten Pakete. Ein synthetisch gesperrtes Paket soll betroffene Builds blockieren, eine dokumentierte Alternative öffnen und zeigen, welche Releases die Abhängigkeit enthalten.
Tests werden nach Risiko und Lieferobjekt geordnet. Schema-, Komponenten-, Formular-, Integrations-, Zugänglichkeits-, Performance-, Sicherheits-, Smoke- und Recoveryprüfungen erhalten Eingabe, Umgebung, erwarteten Zustand, tatsächlichen Befund und Beleg. Ein grüner Gesamttest ohne adressierbare Fälle reicht nicht für die Abnahme.
Ein Release manifestiert Codefassung, CMS-Migration, Konfiguration, Abhängigkeiten, Assets, Tests, Genehmiger, Zielumgebung, Deploymentzeit, Beobachtungsfenster und Rollbackbedingung. Der Pilot veröffentlicht nichts. Er prüft, ob aus denselben Belegen eine eindeutige Freigabe und eine eindeutige Rücknahme entstehen.
Monitoring trennt technische Beobachtung von Geschäftsmessung. Erreichbarkeit, Fehlerklasse, Antwortstatus, Jobzustand, Formularpfad und Ressourcenproblem können technische Signale sein. Sie belegen keinen Lead, Auftrag oder Umsatz. Alarmweg, Bereitschaft, Eskalation, Datenzugriff und Aufbewahrung müssen vor Betrieb geklärt werden.
Backup und Wiederherstellung werden nicht mit einem Häkchen abgeschlossen. Umfang, Häufigkeitsklasse, Verschlüsselungsfrage, Aufbewahrung, Besitzer, Restoreumgebung, Prüffall, Ergebnis und nächste Korrektur bleiben verbunden. Der synthetische Restore nutzt nur leere Inhalte und zeigt, ob Code, CMS-Schema, Konfiguration und Dateien wieder zusammenpassen.
Der technische Exit umfasst vollständigen Repositoryzugriff, Verlauf, Buildanweisungen, Umgebungs- und Konfigurationsregister, CMS-Schema, Migrationsskripte, Schnittstellenverträge, Testfälle, Releasehistorie, Monitoring, Backups, Restorebelege, Dokumentation, Lizenzen, Rollen und offene Incidents. Ein ZIP ohne lauffähige Anleitung ist keine Übergabe.
Zum Abschluss übernimmt ein neues Team den synthetischen Build. Es richtet eine leere Umgebung ein, migriert das erfundene Feld, reproduziert einen Formularfehler, erzeugt einen Releasekandidaten, führt einen Rollback aus und dokumentiert den offenen Paketfall. Erst dann ist das System ohne Agenturgedächtnis übernehmbar.
Branchenspezifische Nachweise, nach denen Sie fragen sollten
- Sichern Sie institutionellen Repositorybesitz, minimale Agenturrollen, Reviewweg und vollständigen Verlaufsexport.
- Trennen Sie lokale, Integrations-, Abnahme- und Produktionsumgebung samt Konfigurationsklassen.
- Versionieren Sie CMS-Felder, Migrationen, Templates, Vorschauen, Exporte und Rückfallskripte gemeinsam.
- Prüfen Sie Formulare im Browser und auf dem Server mit sichtbaren Fehler- und Bestätigungswegen.
- Binden Sie technische Zugänglichkeit, Performance und Sicherheitsprüfung an konkrete Builds und Testfälle.
- Inventarisieren Sie Abhängigkeiten, Lizenzen, Versionen, Sperren, Aktualisierungs- und Entfernungspfade.
- Verbinden Sie Release, Deployment, Beobachtungsfenster, Rollbackbedingung und tatsächlichen Betriebsbeleg.
- Proben Sie Monitoring, Incident, Backup, Restore und vollständige Übernahme ohne Agenturwissen.
So haben wir die Anbieter bewertet
Die Anbieterrecherche nutzt nur offizielle Seiten. Contractor Gorilla und On Purpose Media besitzen eigene Elektriker-Website-Seiten. Rival verbindet eine Home-Service-Website-Design-und-Development-Seite mit einem Electrical-Angebot. Thrive und Hook nennen Entwicklung oder technische Websitearbeit auf ihren Elektriker-Seiten. theStacc beschreibt Websiteerstellung, Hosting und Verwaltung im Managed-Service.
Contractor Gorilla dokumentiert Websiteerstellung, Hosting, SSL, regelmäßige Backups, Sicherheitsarbeit, Softwareupdates und laufende Inhaltsänderungen. Diese Mischung deckt den größten sichtbaren Teil aus Build und Betrieb ab. Aussagen zu ständiger Verfügbarkeit, Geschwindigkeit, Ergebnissen, Preisen und Servicezeiten wurden nicht übernommen.
Rivals Home-Service-Seite nennt Design und Development sowie Arbeiten an Ladezeit, Hosting und Website-Sicherheit. Die Electrical-Seite bestätigt neue Website oder Redesign für Elektriker. Der veröffentlichte Text ist technisch breiter als ein reiner Designauftrag, zeigt aber kein vollständiges Repository-, Release-, Test- oder Recovery-Dossier.
On Purpose Media beschreibt auf der Electrical-Seite Mobile-first-Websites, eine benutzerfreundliche Plattform, Schulung sowie Design, Entwicklung, Content und Testing als gemeinsamen Websiteprozess. Zeit- und Ergebnisbehauptungen wurden ausgeschlossen. Repositorybesitz, Umgebungen, technische Tests und Betriebsübergabe bleiben im gelesenen Material wenig konkret.
Thrive nennt Web Design and Development, Neubau oder Wiederaufbau einer Elektriker-Website, technische SEO, mobile Darstellung und Websitecontent. Hook beschreibt mobil responsive Websitegestaltung, Websiteeditierungen, Content und Landingpages. Beide belegen einen Elektriker-Websiteumfang, aber weniger sichtbare Betriebs- und Recoverygegenstände.
theStacc sagt, dass es Websites erstellt, bestehende Websites aufbaut oder optimiert und den Dienst hostet und verwaltet. Technische Fixes und Seitenstruktur werden ebenfalls genannt. Der Seitenfokus liegt auf SEO und Content. Repository, Formschema, Testmatrix, Security Review, Release, Rollback und Restore sind dort nicht ausreichend dokumentiert.
MDN, W3C, OWASP, web.dev und GitHub liefern technische Referenzen und bewerten keinen Anbieter. Sie begründen nur Prüffragen zu Formularvalidierung, Zugänglichkeit, Sicherheitsverifikation, Performancegegenständen und Repositoryinhalt. Kein Anbieter erhält Punkte für ein Werkzeug oder einen Standard, den seine Quelle nicht nachweisbar nennt.
Gewichtet wurden sichtbarer Elektriker- oder Home-Service-Bezug, technische Websiteerstellung, Repository- und Umgebungsübergabe, CMS und Migration, Formulare, Zugänglichkeitsprüfung, Performance, Abhängigkeiten, Sicherheitsverifikation, Tests, Release, Monitoring, Restore und Exit. Fehlende Dokumentation ist eine offene Beschaffungsfrage, keine negative Tatsachenbehauptung.
| Kriterium | Gewichtung | Was gezählt hat |
|---|---|---|
| Elektrikerbezug und technische Reichweite | Sehr hohe Priorität | Die Quelle verbindet Branchenauftrag mit Entwicklung, Websiteerstellung oder technischem Betrieb. |
| Repository und Umgebungen | Sehr hohe Priorität | Institutioneller Besitz, Rollen, Verlauf, Reviews, Konfiguration und Zielumgebungen bleiben prüfbar. |
| CMS-Schema und Migration | Hohe Priorität | Feldtypen, Quellen, Validierung, Versionen, Zuordnung, Tests und Rückfallweg sind dokumentiert. |
| Formulare und Schnittstellen | Sehr hohe Priorität | Client- und Servervalidierung, Fehler, Bestätigung, Übergabe, Protokollierung und Abschaltweg sind testbar. |
| Technische Zugänglichkeit | Hohe Priorität | Anforderungen, automatisierte Befunde, menschliche Prüfung, Buildbezug und Ausnahmen werden verbunden. |
| Performance und Ressourcen | Hohe Priorität | Budgets, Bedingungen, Builds, Routen, Werkzeuge, Ergebnisse und Abweichungen bleiben reproduzierbar. |
| Abhängigkeiten und Sicherheitsprüfung | Sehr hohe Priorität | Inventar, Version, Lizenz, Aktualisierung, Entfernung, Sicherheitsanforderung und Testbeleg sind adressierbar. |
| Release, Rollback und Beobachtung | Sehr hohe Priorität | Manifest, Freigabe, Deployment, Beobachtungsfenster, Alarm, Incident und Rücknahme bilden eine Lieferkette. |
| Restore und technischer Exit | Sehr hohe Priorität | Backups, Wiederherstellungsproben, Dokumentation, Rollen, Lizenzen und offene Arbeit bleiben übernehmbar. |
Jeder Anbieter musste dieselben Mindestanforderungen erfüllen, bevor seine Position überhaupt betrachtet wurde.
- Eine offizielle Seite verbindet Websitearbeit mit Elektriker-, Electrical- oder Home-Service-Kontext.
- Der sichtbare Umfang enthält Entwicklung, Websiteerstellung oder einen technischen Betriebsgegenstand.
- Die Quelle beschreibt eine betreute Leistung und nicht nur ein Designwerkzeug, Hostingprodukt oder Verzeichnis.
- Die verwendeten Anbieter-URLs waren am Beobachtungstag direkt erreichbar.
- Portfolios, Testimonials, Preise, Zeitangaben, Rankings und Ergebnisse zählen nicht für Aufnahme oder Position.
- theStacc erscheint nur unter ausdrücklicher Offenlegung des Herausgeberinteresses.
Die recherchierte Anbieterliste
Die Platzierungen folgen der veröffentlichten Methodik und dem Stichtag der Quellen; sie sind keine Ergebnisgarantie. Jede Karte nennt die stärkste Eignung und die Einschränkung, die eine Kaufentscheidung am ehesten verändert.
Contractor Gorilla
Belegte Stärken
- Eigene Elektriker-Website-Seite.
- Websiteerstellung und Build sichtbar.
- Hosting, SSL und Backups genannt.
- Sicherheitsarbeit, Softwareupdates und Contentpflege beschrieben.
Zu prüfende Grenzen
- Repository- und Umgebungsübergabe nicht sichtbar.
- Test- und Releaseprozess offen.
- Wiederherstellungsbeleg nicht dokumentiert.
- Technischer Exit bleibt zu klären.
Der breiteste veröffentlichte technische Elektriker-Websiteumfang im Quellenpaket, dessen Repository-, Test-, Release- und Restorebelege erst praktisch abgenommen werden müssen.
Contractor Gorilla veröffentlicht eine eigene Web-Design-for-Electricians-Seite. Der Anbieter beschreibt den Design-, Erstellungs- und Buildteil einer Website und nennt Hosting als betreuten Umfang. Für DE-170 zählt nur der technische Liefer- und Betriebsgegenstand. Designqualität und Marketingwirkung wurden nicht bewertet.
Die Seite nennt SSL, regelmäßige Backups, Sicherheitsarbeit und das Aktualisieren der verwendeten Software. Diese Angaben passen zu den Dossierfeldern für Zertifikatsklasse, Backup, Abhängigkeit und Pflege. Sie belegen jedoch weder konkrete Verfahren noch bestandene Tests, Wiederherstellung oder Sicherheitsniveau.
Laufende Inhaltsänderungen werden ebenfalls beschrieben. Im Pilot muss ein CMS-Feld über Version, Validierung, Vorschau, Migration und Rückfallweg geändert werden. Ein schneller Redaktionsservice ersetzt keine Schemaakte. Jede Änderung braucht einen Build- oder Contentstand und eine erkennbare Veröffentlichung.
Formulare und Projektseiten erscheinen als mögliche Websiteelemente. DE-170 fordert dafür Feldvertrag, Clientfeedback, Serverentscheidung, Fehlerabbildung, Bestätigung, Zielsystem und Testbeleg. Die untersuchte Seite erklärt diesen technischen Pfad nicht im Detail. Genau das soll die synthetische Probe sichtbar machen.
Rang eins folgt aus der größten dokumentierten Mischung von Build und Betrieb für Elektriker. Offen bleiben Repositorybesitz, Umgebungsmodell, CMS-Migrationen, Zugänglichkeitstests, Performancebudgets, ASVS-basierte Anforderungen, Release-Manifest, Rollback, Monitoring, Restorebeleg und vollständiger technischer Exit.
Quellen zu den Anbietern: Contractor Gorilla: Elektriker-Websitebau und Betrieb, Abruf 31.08.2026
Rival Digital
Belegte Stärken
- Home-Service-Design-und-Development-Seite.
- Separate Electrical-Seite.
- Hosting- und Ladezeitgegenstände sichtbar.
- Website-Sicherheit und mobile Umsetzung genannt.
Zu prüfende Grenzen
- Technischer Prozess nur allgemein beschrieben.
- Repository und CMS-Migration offen.
- Release- und Rollbackbelege fehlen.
- Restore und Exit nicht sichtbar.
Ein breiter allgemeiner technischer Umfang plus Elektrikerbezug, mit wenig sichtbaren Angaben zu Repository, Migration, Release und vollständiger Recovery.
Rival Digital veröffentlicht eine Website-Design-and-Development-Seite für Home-Service-Unternehmen. Eine separate Electrical-Seite nennt den Neubau oder das Redesign einer Elektriker-Website. Zusammen belegen die Quellen einen Branchenbezug und einen allgemeinen Websiteentwicklungsauftrag.
Die Home-Service-Seite beschreibt Arbeiten an mobiler Darstellung, Ladezeit, Hosting und Website-Sicherheit. Zahlen und Ergebnisbehauptungen wurden nicht verwendet. Im Dossier muss Rival stattdessen je technischem Gegenstand Codefassung, Konfiguration, Umgebung, Test, Verantwortlichen und Exitweg liefern.
Die Quelle nennt Maßnahmen rund um Ressourcen wie Bilder, Videos, Fonts und Websiteelemente und vermischt dabei Design- und Performancefragen. DE-170 bewertet nur die implementierte Ressourcenlieferung. Ein reproduzierbarer Test muss Route, Build, Umgebung, Profil, Werkzeug und Abweichung nennen.
Navigation, Inhaltsstruktur und visuelle Konsistenz gehören als Designinputs zu DE-169. Rival darf sie implementieren, aber nicht neu freigeben. Jede technische Abweichung benötigt eine Rückmeldung an das Designpaket. So bleibt sichtbar, warum Code und freigegebener Screen voneinander abweichen.
Rang zwei folgt aus dem breiten technischen Themenfeld mit separatem Electrical-Beleg. Repositorykontrolle, CMS-Schema, Formularserverpfad, Schnittstellenverträge, Zugänglichkeitsevaluation, Abhängigkeitsinventar, Release, Rollback, Monitoring und getesteter Restore bleiben im Angebot nachzuweisen.
Quellen zu den Anbietern: Rival Digital: Entwicklung und Betrieb für Home Services, Abruf 31.08.2026, Rival Digital: Electrical-Website-Angebot, Abruf 31.08.2026
On Purpose Media
Belegte Stärken
- Eigene Electrical-Website-Seite.
- Development und Testing genannt.
- Mobile-first-Umsetzung sichtbar.
- Plattform und Schulung zur Pflege beschrieben.
Zu prüfende Grenzen
- Technische Testarten nicht dokumentiert.
- Repository- und Umgebungsmodell offen.
- Betriebs- und Recoveryweg nicht sichtbar.
- Kompletter technischer Exit fehlt.
Ein direktes Electrical-Angebot mit sichtbarem Entwicklungs- und Testbezug, dessen technische Tiefe und Betriebsübergabe im Pilot geklärt werden müssen.
On Purpose Media veröffentlicht eine eigene Electrician-Website-Design-Seite. Die Quelle nennt Mobile-first-Websites, eine benutzerfreundliche Plattform und Schulung. In der Beschreibung des Websiteprozesses erscheinen Design, Development, Content Creation und Testing als Bestandteile.
Die Plattform- und Schulungsangabe ist für CMS-Übergabe relevant. Der Pilot fordert Rollen, Feldtypen, Quellen, Validierung, Vorschau, Veröffentlichung, Export und Rückfallweg. Die untersuchte Seite belegt nicht, welche Plattform oder welches Eigentums- und Migrationsmodell für einen konkreten deutschen Betrieb gilt.
Testing wird sichtbar genannt, aber nicht als technische Matrix ausgeführt. DE-170 verlangt adressierbare Fälle für Schema, Komponenten, Formulare, Schnittstellen, Zugänglichkeit, Performance, Sicherheit, Smoke und Restore. Ein pauschaler Teststatus kann weder Fehlerursache noch sicheren Release belegen.
Mobile-first gehört zum Design- und Implementierungsumfang. Der Entwicklungsbeleg muss zeigen, dass Navigation, Fokus, Inhalte, Formulare und Medien in laufenden Builds funktionieren. Eine visuelle schmale Fassung aus DE-169 ersetzt keine Browser-, Tastatur- oder Hilfsmittelprüfung.
Rang drei beruht auf direktem Electrical-Bezug sowie sichtbarer Entwicklung, Plattform, Schulung und Testing. Offen bleiben Repository, Umgebungen, Servervalidierung, Abhängigkeiten, Security Review, Performancebelege, Release-Manifest, Rollback, Monitoring, Backup, Restore und technischer Exit.
Quellen zu den Anbietern: On Purpose Media: Electrical-Entwicklung und Testing, Abruf 31.08.2026
Thrive Internet Marketing Agency
Belegte Stärken
- Eigene Elektriker-Seite.
- Webdesign und Development ausdrücklich genannt.
- Neubau und Wiederaufbau sichtbar.
- Technische SEO, mobile Darstellung und Content im Umfeld.
Zu prüfende Grenzen
- Repository- und Umgebungsweg nicht beschrieben.
- Test- und Releasebelege offen.
- Monitoring und Restore fehlen.
- Technischer Exit nicht dokumentiert.
Ein direkter Elektrikerbeleg für Development und Websiteaufbau, aber wenig sichtbare technische Governance für Release, Betrieb und Recovery.
Thrive veröffentlicht eine Electrician-Digital-Marketing-Seite mit einem Abschnitt für Web Design and Development. Dort nennt der Anbieter den Aufbau einer neuen Website von Grund auf oder den Wiederaufbau einer bestehenden Seite. Der Vergleich übernimmt keine Wirkungs- oder Rankingbehauptung.
Technische SEO, mobile Darstellung und Crawlbarkeit werden im Umfeld des Websiteangebots genannt. Diese Themen überschneiden sich mit DE-165, während die Implementierung bei DE-170 liegt. Ein technischer Auftrag muss Anforderungen, Codeänderung, Test, Freigabe und organischen Fachbeleg voneinander trennen.
Websitecopy und Landingpages erscheinen als Contentgegenstände. Im Build-Dossier werden sie als versionierte CMS-Eingaben behandelt. Thrive darf eine technische Vorlage implementieren, aber keinen ungeprüften Elektroinhalt, keine Verfügbarkeit und kein Ergebnis aus Platzhaltertext erzeugen.
Die Seite dokumentiert keinen konkreten Repository-, Umgebungs-, Migration-, Release- oder Restoreprozess. Bei einer kombinierten Design-, Development- und Marketingvergabe muss der Betrieb diese Artefakte umso deutlicher verlangen. Ein Teamname ersetzt keinen Rollen- oder Abnahmeverlauf.
Rang vier folgt aus sichtbarem Elektriker-Development, Neubau und Wiederaufbau. Vor Auswahl bleiben CMS-Schema, Formserver, Schnittstellen, Zugänglichkeit, Performancebudget, Sicherheitsprüfung, Abhängigkeiten, Testbelege, Rollback, Monitoring, Backup, Restore, Codezugriff und Exit offen.
Quellen zu den Anbietern: Thrive: Development im Electrician-Webangebot, Abruf 31.08.2026
Hook Agency
Belegte Stärken
- Eigene Elektriker-Marketing-Seite.
- Mobile-responsive Websitearbeit genannt.
- Websiteedits sichtbar.
- Content und Landingpages im selben Umfeld.
Zu prüfende Grenzen
- Development nur indirekt dokumentiert.
- Keine sichtbare Repository- oder Testmatrix.
- Release, Betrieb und Recovery offen.
- Technische Übergabe nicht beschrieben.
Ein direkter Elektriker-Websitebeleg mit geringerer technischer Dokumentation als bei den vorderen Anbietern.
Hook Agency besitzt eine Electrician-Marketing-Seite und beschreibt Website Design for Electrician Businesses als benutzerfreundlich, visuell und mobil responsive. Außerdem werden Websiteedits, Content Writing und Landingpages genannt. Das belegt Websitearbeit, nicht automatisch einen vollständigen Entwicklungsbetrieb.
DE-170 wertet die responsive Implementierung nur, wenn laufende Builds für Navigation, Fokus, Inhalte, Formulare, Zustände und Medien geprüft werden. Die sichtbare Anbieterbeschreibung nennt keine konkrete technische Zugänglichkeits- oder Browsermatrix. Diese Nachweise müssen im Pilot entstehen.
Websiteänderungen benötigen Repository- und Releasebezug. Eine kleine Text- oder Templateänderung kann CMS-Schema, Komponente, Test, Cache und Rollback berühren. Der Anbieter soll deshalb zeigen, wie ein synthetischer Feldwechsel durch Code, Vorschau, Abnahme und Veröffentlichung wandert.
Landingpages verbinden Entwicklung mit DE-168. Kampagnen können Anforderungen liefern, aber kein ungeprüftes Deployment erzwingen. Zielseite, Formularserverpfad, Messereignis, Fehlerzustand, Freigabe und Rollback müssen vor einem Paid-Start denselben technischen Stand tragen.
Rang fünf spiegelt den knappen technischen Beleg wider. Repository, Umgebungen, CMS-Migration, Servervalidierung, Schnittstellen, Performance, Sicherheitsanforderungen, Abhängigkeiten, Tests, Release, Monitoring, Backup, Restore, Dokumentation und vollständiger Exit sind auf der gelesenen Seite nicht sichtbar.
Quellen zu den Anbietern: Hook Agency: responsive Elektriker-Websitearbeit, Abruf 31.08.2026
theStacc Technischer Dienst des Herausgebers, Platz 6
Belegte Stärken
- Websiteerstellung genannt.
- Aufbau oder Optimierung bestehender Websites sichtbar.
- Hosting und Verwaltung beschrieben.
- Technische Fixes und Seitenstruktur im Umfang.
Zu prüfende Grenzen
- Herausgeberinteresse.
- Kein eigenständiger Entwicklungsprozess sichtbar.
- Keine Elektriker-spezifische Entwicklungsseite.
- Repository, Release, Restore und Exit offen.
Ein sichtbarer Build-, Hosting- und Managementumfang ohne ausreichend beschriebenen Entwicklungs- und Recoveryprozess, zusätzlich belastet durch die Herausgeberrolle.
theStacc ist der Herausgeberdienst. Die offizielle Managed-Services-Seite sagt, dass eine Website erstellt wird, wenn keine vorhanden ist, und dass bestehende Websites aufgebaut oder optimiert werden. Sie nennt die Website außerdem als gehostet und verwaltet.
Technische Fixes, Onpage-Arbeit und Seitenstruktur werden ebenfalls beschrieben. DE-170 wertet nur diese technischen Gegenstände. Aussagen zu künstlicher Intelligenz, Preisen, Geschwindigkeit, Kunden, Rankings, Ausgaben oder Ergebnissen wurden nicht in Rang und Methodik übernommen.
Der sichtbare Service verbindet Website, Content, Local SEO und Social. Das kann laufende Änderungen bündeln, erschwert aber die technische Abnahme, wenn Repository, CMS, Tests und Releases nicht getrennt dokumentiert sind. Marketingstatus darf keinen Code- oder Recoverybeleg ersetzen.
Die untersuchte Seite zeigt kein vollständiges Repositorymodell, keine Umgebungsmatrix, kein versioniertes CMS-Schema, keinen Formularserververtrag, keine Zugänglichkeitsprüfung, kein Performancebudget, keine ASVS-Anforderung, kein Release-Manifest und keinen getesteten Restore für diesen Auftrag.
theStacc bleibt wegen knapper technischer Belege und Interessenkonflikt auf Rang sechs. Klären Sie institutionellen Codebesitz, Buildanweisung, Hostingzugriff, Domain, Konfiguration, Lizenzen, Abhängigkeiten, Monitoring, Backup, Restore, Anbieterwechsel und die Löschung verbleibender Zugriffe schriftlich.
Quellen zu den Anbietern: theStacc: Websitebau, Hosting und Management, Abruf 31.08.2026
Vergleichen Sie den Workflow am eigenen Unternehmen
Prüfen Sie die unterstützten Managed Services, Freigabeoptionen, Veröffentlichungsziele und sichtbaren Grenzen von theStacc, bevor Sie sich entscheiden.
Welcher technische Umfang ist auf den Anbieter-Seiten dokumentiert?
Die Tabelle bildet ausschließlich den gelesenen veröffentlichten Umfang ab. Ein individuelles Angebot kann zusätzliche Belege liefern. Ein nicht sichtbarer Gegenstand ist daher eine Beschaffungsfrage, keine Aussage über tatsächliche Fähigkeiten, technische Qualität, Sicherheit oder Eignung.
| Anbieter | Leistungsmodell | Belegter Leistungsumfang | Geeignet für | Wesentliche Einschränkung |
|---|---|---|---|---|
| Contractor Gorilla | Elektriker-Websitebau und Betrieb | Build, Hosting, SSL, Backups, Sicherheit, Softwareupdates, Contentpflege | Breiter Technik- und Betriebspilot | Repo, Release und Restore offen |
| Rival Digital | Home-Service-Development plus Electrical | Entwicklung, mobile Umsetzung, Ladezeit, Hosting, Website-Sicherheit | Build plus technische Optimierung | Governance wenig konkret |
| On Purpose Media | Electrical-Websiteprojekt | Development, Testing, Mobile-first, Plattform, Schulung | Build und CMS-Pflege | Betrieb und Recovery offen |
| Thrive | Elektriker-Webdesign und Development | Neubau, Wiederaufbau, mobile und technische SEO-Gegenstände, Content | Kombinierter Websiteauftrag | Releasekette nicht sichtbar |
| Hook Agency | Elektriker-Websitearbeit | Mobile-responsive, Websiteedits, Content, Landingpages | Enger Entwicklungsumfang | Technikprozess kaum dokumentiert |
| theStacc | Managed gehostete Website | Website erstellen, aufbauen, optimieren, hosten und verwalten | Website in organischer Betreuung | Herausgeberkonflikt, Recovery fehlt |
So testen Sie Webentwicklung ohne Produktionsdaten oder Live-Deployment
Der Pilot verwendet ausschließlich leere Repositories, erfundene Schemas, neutrale Komponenten, synthetische Formulardaten, wirkungslose Konfigurationsschlüssel und isolierte Umgebungen. Keine Domain, Produktionswebsite, Person, Firma, Zahlung, Elektroinformation oder Kundendatei wird einbezogen.
Die Probe kombiniert einen CMS-Feldwechsel, eine gesperrte Paketkennung, einen Formularfehler, einen fehlgeschlagenen Releasekandidaten und eine Restoreaufgabe. Bewertet werden Beleg, Sperre, Rollback, Wiederaufnahme und Übernahme durch ein neues Team.
1. Übernehmen Sie das Designpaket mit einer Abweichungsliste
Referenzieren Sie Seiten, Komponenten, Zustände, Viewports, Texte, Assets, Interaktionsregeln und Zugänglichkeitsnotizen aus DE-169. Jede Eingabe erhält Fassung, Besitzer, Freigabe und offene Frage. Es wird kein echter Screen verwendet.
Der Anbieter markiert technische Unklarheiten, bevor Code entsteht. Alternative, Auswirkung, betroffene Designobjekte und Entscheidung bleiben dokumentiert. Eine Agentur darf eine fehlende Design- oder Fachfreigabe nicht durch eigene Implementierung schließen.
- Designfassung
- Komponente
- Zustand
- Viewport
- Inhalt
- Asset
- Annotation
- Abweichung
2. Prüfen Sie Repositorybesitz und leere Umgebungen
Legen Sie ein synthetisches Repository mit neutralen Dateien an. Dokumentieren Sie institutionellen Besitzer, Agenturrolle, Reviewweg, Branchklasse, Releasebezug, Export und Entzug. Keine Zugangsdaten erscheinen im Dossier.
Richten Sie leere Integrations- und Abnahmeumgebungen nach schriftlicher Anleitung ein. Konfigurationsklassen und Sperren bleiben sichtbar. Die neue Umgebung darf keine produktiven Daten oder echten Geheimnisse benötigen, um einen neutralen Build zu erzeugen.
3. Migrieren Sie ein erfundenes CMS-Feld
Benennen Sie ein neutrales Feld im synthetischen Schema um. Fordern Sie Zuordnung, Migration, ungültige Einträge, Templateänderung, Vorschau, Export, Tests und Rückfallskript. Jeder Beleg verweist auf dieselbe Schema-Version.
Führen Sie zuerst den Vorwärtsweg und anschließend den Rückfall in der isolierten Umgebung aus. Der vorherige Inhalt muss erhalten bleiben. Ein manueller Datenfix ohne Skript, Verlauf und Prüffall gilt nicht als übernehmbarer Migrationsweg.
- Ausgangsschema
- Zielversion
- Zuordnung
- Migration
- Template
- Test
- Export
- Rückfall
4. Testen Sie Formularfehler auf Client und Server
Verwenden Sie nur erfundene Werte und neutrale Felder. Prüfen Sie erforderliche Eingabe, Format, Clientfeedback, Serverentscheidung, Feldfehler, Gesamtfehler, Sendestatus, Bestätigung und doppelte Übermittlung. Es wird nichts gespeichert oder versendet.
Umgehen Sie im Test die clientseitige Prüfung. Der Server muss den synthetischen ungültigen Zustand weiterhin ablehnen und eine definierte Rückmeldung erzeugen. Dokumentieren Sie Anfrageklasse, Antwortklasse, Protokollbeleg und das Fehlen echter personenbezogener Daten.
- Label
- Format
- Clientstatus
- Serverstatus
- Fehler
- Bestätigung
- Deduplizierung
- Beleg
5. Binden Sie Zugänglichkeitsprüfungen an Builds
Ordnen Sie relevante WCAG-Anforderungen den implementierten Komponenten und Seiten zu. Hinterlegen Sie Testart, Build, Umgebung, Befund, menschliche Prüfung, Ausnahme und nächsten Schritt. Keine Konformität wird im Pilot behauptet.
Prüfen Sie mit synthetischen Inhalten unter anderem Semantik, Tastaturweg, Fokus, Namen, Beziehungen, Fehler, Statusmeldungen, Medienalternativen und Zoom. Automatisierte und menschliche Befunde bleiben getrennt, bis eine verantwortliche Person sie bewertet.
6. Definieren Sie Performancebudgets ohne erfundene Zahlen
Wählen Sie für das reale Projekt später geeignete Routen, Ressourcen und Messbedingungen. Im Pilot bleiben Grenzwerte leer. Die Agentur dokumentiert, wie HTML, CSS, JavaScript, Bilder, Fonts, Video und externe Ressourcen erfasst werden.
Erzeugen Sie zwei synthetische Builds mit unterschiedlicher Bildressource. Der Bericht muss Build, Route, Umgebung, Profil, Werkzeug und Abweichung nennen. Er darf weder aus einem Laborwert einen Geschäftsgewinn noch aus fehlenden Felddaten einen Erfolg ableiten.
- Build
- Route
- Umgebung
- Profil
- Werkzeug
- Ressource
- Budget
- Abweichung
7. Sperren Sie eine erfundene Abhängigkeit
Führen Sie ein neutrales Paket mit Version, Quelle, Lizenzstatus, Einsatzort, Besitzer, Aktualisierungsweg und Entfernungspfad. Markieren Sie die Kennung anschließend als gesperrt. Kein echtes Paket oder Sicherheitsproblem wird benannt.
Der Build soll betroffenes Modul und Releases erkennen, die Sperre sichtbar machen und eine dokumentierte Alternative öffnen. Eine Versionsänderung braucht eigene Tests. Die Agentur darf den Warnstatus nicht durch stummes Entfernen des Inventareintrags beseitigen.
8. Erstellen Sie Release und Rollback aus demselben Manifest
Bündeln Sie Codefassung, Schema, Konfiguration, Abhängigkeiten, Assets, Tests, Genehmigung, Zielumgebung, Beobachtungsfenster und Rücknahmebedingung. Der Pilot führt nur einen isolierten Releasekandidaten aus.
Lösen Sie einen synthetischen Smoke-Testfehler aus. Das Team stoppt die Freigabe, führt den dokumentierten Rollback durch und prüft den vorherigen Stand. Neue Korrekturen beginnen mit einer neuen Fassung statt den fehlgeschlagenen Beleg zu überschreiben.
- Code
- Schema
- Konfiguration
- Abhängigkeiten
- Tests
- Freigabe
- Beobachtung
- Rollback
9. Proben Sie Monitoring, Incident und Restore
Erzeugen Sie ein wirkungsloses technisches Signal für Formularpfad oder Jobstatus. Erfassen Sie Zeit, Build, Umgebung, Beobachtung, Auswirkung, Sofortmaßnahme, Besitzer, Entscheidung und Wiederaufnahmebedingung. Es existiert kein echter Ausfall.
Stellen Sie anschließend leere Inhalte, Schema und Konfiguration in einer isolierten Umgebung wieder her. Vergleichen Sie erwarteten und tatsächlichen Stand. Ein vorhandenes Backup ohne bestandene Restoreprobe bleibt ein unbewiesener Betriebsgegenstand.
10. Lassen Sie ein neues Team den technischen Exit ausführen
Übergeben Sie Repository, Verlauf, Buildanweisung, Umgebungsregister, CMS-Schema, Migrationen, Schnittstellen, Tests, Releases, Monitoring, Backup, Restorebelege, Lizenzen, Rollen und offene Incidents. Ein Zugangsscreenshot reicht nicht.
Das neue Team baut die leere Umgebung, migriert das Feld, reproduziert den Formularfall, erzeugt einen Releasekandidaten und rollt ihn zurück. Danach werden Agenturrollen und verbundene Systeme kontrolliert entfernt. Offene Risiken bleiben im Übergabeprotokoll sichtbar.
Fehler, die einen SEO-Vergleich wertlos machen
- Die Live-URL gilt als Abnahme. Eine sichtbare Seite belegt weder Repositoryzugriff noch CMS-Migration, Servervalidierung, Tests, Rollback, Monitoring oder Restore.
- Designfreigabe und technische Freigabe werden vermischt. Screens beschreiben Sollzustände. Laufende Builds, Datenwege, Browser, Hilfsmittel und Betriebsprozesse brauchen eigene Nachweise.
- Produktionsdaten füllen die Testumgebung. Der Pilot funktioniert mit synthetischen Daten. Reale Kundendaten schaffen unnötige Risiken und verdecken fehlende Testfixtures.
- Clientvalidierung schützt das Formular. Browserprüfungen verbessern Feedback, können aber umgangen werden. Der Serverpfad benötigt eigene Validierung und Sicherheitsprüfung.
- Ein Teststatus bleibt ohne Testfall grün. Prüffall, Umgebung, Build, Erwartung, Ergebnis und Beleg müssen adressierbar sein, sonst lässt sich ein Fehler nicht reproduzieren.
- Backup wird mit Restore gleichgesetzt. Nur eine Wiederherstellungsprobe zeigt, ob Code, Schema, Konfiguration und Dateien in einer neuen Umgebung zusammenpassen.
- Der Exit liefert Quellcode ohne Betriebswissen. Neue Teams brauchen Build-, Release-, Monitoring-, Recovery-, Lizenz- und Rollenunterlagen sowie die offenen Incidents.
Häufige Fragen
Was sollte eine Webentwicklungsagentur für Elektriker liefern?
Verlangen Sie Repository und Verlauf, Umgebungsanleitung, CMS-Schema, Migrationen, Komponentenimplementierung, Formular- und Schnittstellenverträge, Zugänglichkeits-, Performance- und Sicherheitsprüfungen, Abhängigkeitsinventar, Testfälle, Release- und Rollbackbelege, Monitoring, Backup, getesteten Restore, technische Dokumentation und vollständigen Exit als jeweils prüfbare Lieferungen. Designentscheidungen und Marketingkampagnen bleiben getrennte Aufträge.
Warum steht Contractor Gorilla auf Rang eins?
Contractor Gorilla nennt auf der Elektriker-Website-Seite Websiteerstellung, Hosting, SSL, Backups, Sicherheitsarbeit, Softwareupdates und laufende Contentänderungen. Das ist der breiteste sichtbare Build- und Betriebsumfang dieses Quellenpakets. Der Rang bestätigt weder Codequalität, Sicherheit, Zugänglichkeit, Performance, deutsche Betreuung noch einen bestandenen Restore im Projekt.
Wem sollten Repository und Quellcode gehören?
Der Vertrag sollte institutionellen Repositorybesitz, Agenturrollen, Reviewweg, Revisionsverlauf, Export, Lizenzen und den Entzug von Zugriffen festlegen. Welche rechtliche Eigentumsregel passt, muss fachkundig geprüft werden. Praktisch sollte ein neues berechtigtes Team den Code, die Dateien und ihre Historie übernehmen und nach dokumentierter Anleitung bauen können.
Warum braucht ein Formular Client- und Servervalidierung?
Clientseitige Validierung gibt früh verständliches Feedback, kann aber umgangen werden. MDN fordert deshalb auch serverseitige Validierung für übermittelte Daten. Der Vertrag sollte Feldformat, Clientstatus, Serverentscheidung, Fehlerrückmeldung, Bestätigung, Protokollierung und Testfall verbinden. Datenschutz und tatsächliche Speicherung benötigen eine separate fachliche Prüfung.
Wie prüft man technische Barrierefreiheit?
Ordnen Sie Anforderungen aus WCAG 2.2 konkreten Komponenten, Seiten und Builds zu. Kombinieren Sie geeignete automatisierte Prüfungen mit verantwortlicher menschlicher Evaluation und dokumentieren Sie Umgebung, Testart, Befund, Ausnahme und Korrektur. Ein freigegebener Screen oder ein fehlerfreier Scanner allein belegt keine Konformität der laufenden Website.
Welche Performancewerte gehören in den Vertrag?
Wählen Sie Werte und Budgets erst nach Projekt-, Routen- und Nutzerklärung. Dokumentieren Sie für jede Messung Build, Route, Umgebung, Gerätekategorie, Netzwerkprofil, Werkzeug, Zeitpunkt und Abweichung. Trennen Sie Laborwerte, Felddaten und Geschäftsergebnisse. Dieser Vergleich setzt keine Zahlen, weil keine projektspezifische Messgrundlage vorliegt.
Was gehört in ein Release-Manifest?
Ein Release-Manifest sollte Codefassung, CMS-Schema und Migration, Konfiguration, Abhängigkeiten, Assets, Testbelege, Genehmiger, Zielumgebung, Deploymentzeit, Beobachtungsfenster und Rollbackbedingung verbinden. Jede Korrektur erhält eine neue Fassung. So lässt sich später für das Projekt zeigen, was tatsächlich ausgeliefert, beobachtet, zurückgenommen oder noch nicht freigegeben wurde.
Reicht ein regelmäßiges Backup aus?
Nein. Ein Backup ist erst als Wiederherstellungsweg belastbar, wenn Umfang, Aufbewahrung, Besitzer, Zielumgebung und Restoreablauf dokumentiert und praktisch geprüft wurden. Die Probe sollte Code, CMS-Schema, Konfiguration und Dateien in einer isolierten Umgebung zusammenführen. Dieser Artikel hat bei keinem Anbieter einen echten Backup- oder Restoreprozess getestet.
Was muss beim technischen Agenturwechsel übergeben werden?
Übergeben Sie Repository, Verlauf, Buildanweisung, Umgebungs- und Konfigurationsregister, CMS-Schema, Migrationen, Schnittstellen, Testfälle, Releasehistorie, Monitoring, Backups, Restorebelege, Lizenzen, Rollen, Domain- und Hostingwege sowie offene Incidents. Ein neues Team sollte daraus eine leere Umgebung bauen, einen Release zurücknehmen und den nächsten sicheren Schritt erkennen können.
Wie vergleicht man Angebote für Webentwicklung?
Vergleichen Sie ein identisches technisches Los aus Repository, Umgebungen, CMS, Migrationen, Formularen, Integrationen, Zugänglichkeit, Performance, Sicherheitsanforderungen, Abhängigkeiten, Tests, Hosting, Releases, Monitoring, Backup, Restore, Dokumentation und Exit. Trennen Sie Webdesign, Content, SEO und Kampagnen. Ein Gesamtpreis ohne gleiche Lieferobjekte ist nicht aussagekräftig.
Warum bleibt DE-170 needs_human_review?
Für DE-170 fehlen ein namentlich verantwortlicher Entwicklungs- und Elektrofachreview, eine bestätigte muttersprachliche Schlussredaktion und eine klar zugewiesene technische Pflegeverantwortung. Die Quellen waren erreichbar und der Pilot ist synthetisch, doch diese fehlenden menschlichen Kontrollen verhindern eine automatische Veröffentlichung oder Darstellung als praktischer Techniktest.
Quellen und redaktionelle Grundsätze
Lesen Sie die verlinkten Quellen zusammen mit der Methodik und dem Hinweis des Herausgebers in diesem Artikel. Prüfen Sie aktuelle Preise, Funktionen und Bedingungen beim jeweiligen Anbieter; ein Quellenverweis allein belegt keinen Praxistest.
- [01]MDN, clientseitige Formularvalidierung
- [02]OWASP, Application Security Verification Standard
- [03]W3C, Web Content Accessibility Guidelines 2.2
- [04]web.dev, Learn Performance
- [05]GitHub Docs, About repositories
- [06]Contractor Gorilla, Websitebau für Elektriker
- [07]Rival Digital, Home-Service Website Development
- [08]Rival Digital, Electrical-Angebot
- [09]On Purpose Media, Electrical Website Design
- [10]Thrive, Electrician Digital Marketing
- [11]Hook Agency, Electrician Marketing
- [12]theStacc, Managed Services
Kaufen Sie eine wiederherstellbare Lieferkette, nicht nur eine Live-URL
Eine Webentwicklungsagentur für Elektriker muss einen Build erklären, einen Fehler reproduzieren, einen Release zurücknehmen und ein leeres System wiederherstellen können. Lassen Sie jeden Anbieter dasselbe synthetische Dossier bearbeiten und anschließend an ein neues Team übergeben. Erst dann sind technische Verantwortung und Exit vergleichbar. DE-170 benötigt vor Veröffentlichung weiterhin Entwicklungs- und Elektrofachreview, deutsche Schlussredaktion sowie einen benannten Pflegeverantwortlichen.