Eine veröffentlichte Website kann erreichbar sein und trotzdem keinen übernehmbaren technischen Bestand besitzen. Wenn Code, Buildschritte, Konfigurationen oder Releasewege nur im Agenturzugang verständlich sind, wird ein scheinbar fertiges Projekt beim nächsten Wechsel zu einer Rekonstruktionsaufgabe.
DE-152 bewertet deshalb ein Release-Übergabeprotokoll. Es verfolgt eine neutrale Änderung von der Architekturentscheidung über Repository, Build und QA bis zur Zielumgebung. Die bekannte vorherige Fassung, offene Fehler und Rücknahmegrenze bleiben an derselben Kennung lesbar.
Der Pilot enthält ein abstraktes Seitenobjekt, ein leeres CMS-Modell und eine synthetische Integration. Konfigurationsnamen besitzen keine Werte. Ein kontrollierter Fehler zeigt, ob die Agentur Version, Test, Release und Rücknahme auseinanderhalten kann, ohne eine echte Website zu verändern.
DE-151 liefert nur freigegebene Designobjekte als Eingabe. DE-152 implementiert diese Fassung, entscheidet aber keine offenen Farben, Inhalte, Navigationen oder Marketingziele. Gestaltung und technische Umsetzung bleiben getrennte Abnahmen.
theStacc veröffentlicht DE-152 und bietet zugleich den auf Rang drei genannten Managed-Service mit Website-Erstellung, Hosting und Verwaltung an. Dieser wirtschaftliche Interessenkonflikt beeinflusst Auswahl und Reihenfolge. Das Herausgeberangebot erhält keine bevorzugte Platzierung. Kein Anbieter hat für die Aufnahme bezahlt. Die Darstellung beruht auf drei offiziellen URLs, die am 30. August 2026 erreichbar waren: den Webentwicklungsseiten von ScienceSoft und Netguru sowie der Managed-Services-Seite von theStacc. Wir haben keinen Anbieter, Vertrag, Retainer, Account, Dachdeckerbetrieb, Auftragnehmer, Kunden, keine Website, Architektur, Codebasis, Repository, Abhängigkeit, CMS-Instanz, Integration, Umgebung, Konfiguration, Build, Prüfung, Freigabe, Bereitstellung, Rücknahme, Überwachung, Störung, Zugangsklasse, Rechnung, Kündigung, Wiederherstellung oder Übergabe praktisch getestet. Preise, Laufzeiten, Teamzuschnitt, deutschsprachige Betreuung, Sicherheit, Hostingqualität, Vertragsbedingungen, Berechtigungen, Datenqualität, Supportqualität und Eignung bleiben offen. Anbieterquellen belegen nur den eigenen beschriebenen Leistungsbereich und keine objektive Überlegenheit. Der Pilot verwendet ein abstraktes Seitenobjekt, einen leeren CMS-Datensatz, einen synthetischen API-Vertrag, neutrale Umgebungsnamen, Konfigurationskennungen ohne Werte und einen erfundenen Releasefehler. Er enthält keine realen Firmen, Dachdecker, Auftragnehmer, Projekte, Kunden, Fälle, Testimonials, Bewertungen, Preise, Retainer, Tests, Reichweiten, Rankings, Leads, Umsätze, Personen, Prüfer, Eigentümer oder Zugangsdaten. Aussagen zu Arbeitssicherheit, Statik, Reparatur, Inspektion, Materialien, Garantien, Recht, Versicherungen, Vorschriften oder Ergebnissen bleiben vollständig außerhalb. DE-147 besitzt organische SEO, DE-148 lokale Profile, DE-149 Social Media, DE-150 breite Marketingsteuerung und DE-151 Discovery, Informationsarchitektur, Wireframes, UI, Inhalte, Assets und Designexport. DE-152 besitzt nur technische Architektur, Repository, Code, CMS, Integrationen, Umgebungen, Build, QA, Release, technische Betriebsgrenzen, Rollback, Zugriffsregister, Recovery und technischen Export. Eine fachkundige Prüfung, eine deutsche Sprachprüfung und ein Wartungsverantwortlicher sind nicht benannt. DE-152 bleibt needs_human_review und ist nicht automatisch zur Veröffentlichung freigegeben.
Die kurze Antwort
ScienceSoft führt den neutralen Release-Pilot an, weil die offizielle Seite Architektur, Frontend, Backend, API-Integration, Testing und QA sowie Support sichtbar trennt. Netguru folgt mit Webanwendungen, individuellem CMS, Technologieauswahl, Entwicklung, QA, Launch und Wartung. theStacc bleibt wegen Herausgeberkonflikt und nicht dokumentierter technischer Lieferkette auf Rang drei. Keine Quelle belegt Dachdecker-Eignung oder Ergebnisse.
- ScienceSoft: Betriebe, die Architektur, Frontend, Backend, API-Verträge, Testing, QA und laufende Supportgrenzen in einer technischen Beweiskette demonstrieren lassen möchten
- Netguru: Betriebe, die Technologieauswahl, Webanwendung, CMS, Entwicklung, QA, Launch und Wartung an einem neutralen Releasegegenstand prüfen möchten
- theStacc: Betriebe, die einen enger belegten Website-Service unabhängig gegen Repository-, Release-, Rollback- und Exit-Anforderungen prüfen möchten
Das Release-Übergabeprotokoll für eine abstrakte Dachdecker-Website
Der erste Protokolleintrag ist eine technische Annahmekarte. Sie enthält das freigegebene Designobjekt aus DE-151, das neutrale Inhaltsmodell, erwartete Systemgrenzen, bekannte Unklarheiten, Ausschlüsse und Abnahmekriterium. Im Pilot gibt es keine reale Brancheingabe, die ein Entwickler auslegen dürfte.
Eine Architekturentscheidung ist mehr als ein Technologiestapel. Problem, betrachtete Wege, gewählte Richtung, Folgen, Abhängigkeiten, offene Risiken und Rücknahmepunkt werden festgehalten. Ein Frameworkname ohne Zusammenhang zwischen Rendering, CMS, Integration, Build und Betrieb ist kein abnehmbarer Entwurf.
Der Codebestand beginnt unter institutionell kontrollierter Verwahrung. Repository-Ort, Dienstleisterrolle, Branchregel, Reviewstatus, Abhängigkeitsdateien und Buildanweisung sind vor der ersten Änderung bekannt. Der Pilot verwendet keine echten Zugangsdaten und behauptet keinen bestimmten Repository-Dienst.
Eine Designfassung aus DE-151 wird als unveränderliche Eingabe referenziert. Benötigt eine Komponente einen technischen Zustand, der dort fehlt, entsteht eine Rückfrage. Das Entwicklungsteam darf keine eigene visuelle Entscheidung als notwendige Implementation verstecken. Die Antwort erhält eine neue Designkennung.
Frontend und Backend haben getrennte Lieferstände. Eine gerenderte Komponente belegt keine funktionierende Datenquelle. Ein erfolgreiches API-Ergebnis belegt keine korrekte Oberfläche. Das Protokoll verbindet beide erst, wenn Vertrag, Fehlerzustand, Test und gemeinsame Version sichtbar sind.
Das CMS wird über ein Modell statt über einen Login abgenommen. Feldname, Datentyp, Pflichtstatus, erlaubter leerer Zustand, Vorschau, Rollenklasse, Versionsbezug und Exportform gehören zum neutralen Versuch. Es wird kein Dachdeckerinhalt eingegeben und keine redaktionelle Bedienbarkeit behauptet.
Eine Integration besitzt einen synthetischen Vertrag. Eingabeform, Ausgabeform, Fehlerklasse, Timeout, Testdouble, verantwortete Seite und Änderungsregel reichen aus. Es gibt keinen echten Drittanbieter und keinen Schlüssel. Der Anbieter soll zeigen, wie die Anwendung auf eine veränderte Antwort reagiert.
Konfigurationen werden als Namen und Herkunftsklassen geführt, nie als Geheimnisse. Lokale Arbeit, Vorschau, Test und Produktion können unterschiedliche Werte benötigen. Das Übergabeprotokoll hält nur fest, woher eine Klasse stammt, wer sie kontrolliert, wie ihr Fehlen erkannt und wie ein Dienstleisterzugriff entzogen wird.
Der Build erhält eine reproduzierbare Eingabeliste. Laufzeit, Abhängigkeitsdefinition, Installationsweg, Befehl, erwartetes Artefakt und bekannte manuelle Schritte werden dokumentiert. Ein Build auf einem einzelnen Agenturrechner besteht den Exit nicht, wenn ein anderes Team die Voraussetzungen nicht nachvollziehen kann.
QA wird nicht als grünes Wort gespeichert. Testklasse, getestete Version, Umgebung, Eingabe, erwarteter Zustand, beobachteter Zustand, Ergebnis und offene Ausnahme sind eigene Felder. Unit-, Komponenten-, Integrations-, System- und manuelle Prüfung können vorkommen, müssen aber einen benannten Gegenstand besitzen.
Der neutrale Pilot prüft einen Idealweg und zwei Fehlerwege. Das CMS-Feld bleibt leer, die synthetische API liefert eine geänderte Form und eine Konfigurationskennung fehlt. Die Agentur muss zeigen, welche Schicht den Fehler besitzt und welche anderen Arbeitsstände gültig bleiben.
Ein Release verbindet Quellversion, Build-Artefakt, Freigabe, Zielumgebung, Zeitpunkt, Ergebnis und anschließende Kontrolle. Ein erfolgreicher Upload allein ist kein Beleg für die erwartete Ausgabe. Die neutrale Kontrolle prüft nur die vereinbarte Zustandskennung, nicht Geschwindigkeit, Umsatz oder Suchwirkung.
Rollback bezeichnet eine bekannte Rücknahme, nicht ein allgemeines Beruhigungswort. Vorherige Quellversion, vorheriges Artefakt, notwendige Daten- oder Modellgrenze, auslösende Bedingung, entscheidende Rolle und Abschlusskontrolle werden vor dem Pilotfehler benannt. Eine tatsächliche produktive Rücknahme findet nicht statt.
Überwachung beginnt mit Ereignisklassen und Zuständigkeiten. Buildfehler, nicht erreichbare Anwendung, fehlende Konfiguration und Integrationsabweichung können getrennte Signale besitzen. DE-152 behauptet keine Verfügbarkeit, Reaktionszeit oder sichere Erkennung. Der Anbieter soll nur die verantwortete Grenze offenlegen.
Wartung und Support brauchen einen letzten Liefergegenstand. Diagnose, Änderung, Test, Release, Dokumentation und offene Restarbeit bleiben auch bei laufender Betreuung versioniert. Eine Supportbezeichnung belegt keine konkrete Frist, Verfügbarkeit oder Qualität und fließt ohne sichtbare technische Übergabe nicht in eine Abnahme ein.
Recovery verwendet eine neutrale Wiederanlaufkarte. Codekopie, Buildanweisung, Umgebungsinventar, CMS-Exportklasse, bekannte Version, Rollenentzug und offene Abhängigkeiten werden außerhalb des Agenturportals geöffnet. Der Pilot bestätigt weder Backup noch Hosting- oder Sicherheitsniveau.
Der technische Export enthält Architekturentscheidungen, Repository oder übertragbare Codekopie, Abhängigkeitsdateien, Buildweg, CMS-Modell, Integrationsverträge, Umgebungsinventar, Testbelege, Releasehistorie, Zugriffsregister, Betriebsgrenzen und offene Fehler. Eine Präsentation kann erklären, ersetzt aber keinen reproduzierbaren Bestand.
ScienceSoft und Netguru nennen zahlreiche weitere Leistungen. DE-152 übernimmt ausschließlich den auf den verwendeten Seiten sichtbaren Entwicklungsumfang. Kunden, Projekte, Zahlen, Garantien, Fallresultate, Preise, Geschwindigkeitsbehauptungen und behauptete Qualität bleiben aus Auswahl und Reihenfolge ausgeschlossen.
theStacc beschreibt Website-Erstellung, Hosting und Verwaltung. Die verwendete Seite macht daraus keinen sichtbaren technischen Ablauf für Architektur, Repository, CMS-Modell, Integration, QA, Release, Rollback und Export. Diese begrenzte Beleglage und der Herausgeberkonflikt führen zur letzten Position.
Branchenspezifische Nachweise, nach denen Sie fragen sollten
- Technische Anforderungen verweisen auf eine freigegebene Design- und Datenfassung.
- Architekturentscheidungen nennen Optionen, Folgen, offene Risiken und Rücknahmepunkte.
- Repository, Reviews, Abhängigkeiten und Buildweg bleiben institutionell kontrollierbar.
- CMS-Modell und synthetischer Integrationsvertrag besitzen getrennte Abnahmen.
- Vorschau, Test und Produktion haben dokumentierte Zwecke und Konfigurationsgrenzen.
- QA-Belege nennen Version, Umgebung, Eingabe, Erwartung, Beobachtung und Ausnahme.
- Release, Kontrolle und bekannte Rücknahme bleiben über eine Kennung verbunden.
- Code, Modelle, Tests, Historie, Rollen und offene Arbeit sind außerhalb exportierbar.
So haben wir die Anbieter bewertet
ScienceSoft steht auf Rang eins. Die offizielle Webentwicklungsseite beschreibt Architektur, Frontend-Entwicklung, Backend-Entwicklung, API-Integration, Testing und QA, Help Desk sowie kontinuierlichen Support und Weiterentwicklung als sichtbare Bereiche. Diese Trennung passt am direktesten zum Release-Übergabeprotokoll.
ScienceSoft verwendet auf der Seite auch Garantien, Zahlen, Kundenbeispiele und Ergebnisbehauptungen. DE-152 übernimmt nichts davon. Berücksichtigt werden nur die sichtbaren technischen Bereiche. Dachdecker-Eignung, deutsche Betreuung, tatsächliche Qualität, Repository-Verwahrung, Releasebeleg und Exit bleiben zu demonstrieren.
Netguru folgt auf Rang zwei. Die offizielle Seite nennt Webanwendungen, ein individuelles CMS, laufende Webentwicklung, Technologieauswahl, Entwicklung, QA Testing, Publishing beziehungsweise Launch, Maintenance und Support. Das deckt mehrere Protokollstationen ab, ohne einen konkreten Besitz- oder Recovery-Weg zu belegen.
Netguru zeigt außerdem Projektzahlen, Kunden, Fälle und behauptete Resultate. Diese Inhalte fließen nicht ein. DE-152 verwendet nur den dokumentierten Serviceumfang. Architekturentscheidungen, Repository-Kontrolle, Konfigurationsklassen, Releasehistorie, Rollback und Export müssen im neutralen Pilot separat gezeigt werden.
theStacc steht auf Rang drei. Die Managed-Services-Seite beschreibt, dass eine Website erstellt, gehostet und verwaltet werden kann. Ein vollständiger technischer Entwicklungsprozess ist dort nicht dokumentiert. Insbesondere bleiben Architektur, Repository, CMS-Modell, Integration, Umgebungen, QA, Release, Rücknahme und Export offen.
theStacc veröffentlicht DE-152 und verkauft das genannte Angebot. Die Einordnung braucht deshalb unabhängige Prüfung. Preise, Paketbestandteile, Mengen, Rankings, Wachstums-, Output-, Kunden- und Ergebnisbehauptungen der Seite werden ausgeschlossen. Die Bezeichnung Website wird nicht zu individueller Entwicklung erweitert.
Keine der drei Quellen belegt eine Eignung für Dachdecker oder eine reale Implementierung des beschriebenen Piloten. Jeder Rang bezeichnet nur die Nähe sichtbarer Leistungsbegriffe zur technischen Beweiskette. Ein fachkundiger Mensch muss Vertrag, Code, Sicherheit, Zugänglichkeit, Betrieb und Übergabe tatsächlich prüfen.
| Kriterium | Gewichtung | Was gezählt hat |
|---|---|---|
| Annahme und Architekturentscheidung | Hohe Priorität | Designversion, technisches Problem, Optionen, Folgen, Risiken und Rücknahme werden vor Code geklärt. |
| Repository und reproduzierbarer Build | Hohe Priorität | Codebesitz, Review, Laufzeit, Abhängigkeiten, Befehl, Artefakt und manuelle Schritte bleiben lesbar. |
| CMS und Integrationsverträge | Hohe Priorität | Modelle, Rollen, Exporte, Ein- und Ausgaben sowie Fehlerzustände besitzen getrennte Grenzen. |
| Umgebungen und QA-Belege | Hohe Priorität | Zweck, Konfigurationsklasse, Version, Erwartung, Beobachtung und Ausnahme sind verbunden. |
| Release, Kontrolle und Rollback | Hohe Priorität | Artefakt, Ziel, Freigabe, Ergebnis, bekannte vorherige Fassung und Rücknahme bleiben adressierbar. |
| Betriebsgrenze und technischer Exit | Mittlere Priorität | Signale, Zuständigkeiten, Code, Historie, Rollen und offene Fehler bleiben extern übernehmbar. |
Jeder Anbieter musste dieselben Mindestanforderungen erfüllen, bevor seine Position überhaupt betrachtet wurde.
- Eine erreichbare offizielle Seite beschreibt Webentwicklung oder einen klaren Website-Erstellungsumfang.
- Die dokumentierten Bereiche lassen sich mit neutralem Code, leerem CMS und synthetischer Integration prüfen.
- Preise, Kunden, Fälle, Testimonials, Zahlen, Garantien und Resultate werden nicht übernommen.
- Technische Umsetzung lässt sich von Webdesign, SEO und Marketing als eigener Gegenstand trennen.
- Architektur, Frontend, Backend, CMS, Integration, QA, Launch oder Website-Erstellung ist sichtbar.
- Der Herausgeberkonflikt von theStacc bleibt sichtbar und verhindert eine bevorzugte Platzierung.
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.
ScienceSoft
Belegte Stärken
- Architektur wird als eigener Bereich beschrieben.
- Frontend und Backend sind getrennt sichtbar.
- API-Integration wird ausdrücklich genannt.
- Testing, QA, Help Desk und kontinuierlicher Support werden aufgeführt.
Zu prüfende Grenzen
- Dachdecker-Eignung und deutsche Betreuung sind unbelegt.
- Repository-Verwahrung und Build-Reproduktion müssen gezeigt werden.
- Konfiguration, Releasehistorie und Rollback bleiben offen.
- Garantien, Ergebnisse, Sicherheit und Exporttiefe werden nicht bestätigt.
ScienceSoft führt DE-152 an, weil die offizielle Seite Architektur, Frontend-Entwicklung, Backend-Entwicklung, API-Integration, Testing und QA, Help Desk sowie kontinuierlichen Support und Weiterentwicklung getrennt beschreibt. Nicht übernommen werden Garantien, Zahlen, Fälle oder Ergebnisse. Unbelegt bleiben Dachdecker-Eignung, deutsche Betreuung, Repository-Kontrolle, konkrete Build- und Releasekette, Rollback, Zugriffsgovernance, Exporttiefe und tatsächliche Qualität.
Übergeben Sie ScienceSoft die technische Annahmekarte und die freigegebene Designkennung aus DE-151. Der Anbieter soll Architekturkomponenten, Systemgrenzen und offene Risiken dokumentieren. Architektur ist sichtbar beschrieben. Ein konkretes Entscheidungsformat und dessen Übertragbarkeit bleiben im Pilot zu zeigen.
Trennen Sie Frontend, Backend und synthetische API-Integration. ScienceSoft nennt alle drei Bereiche und beschreibt API-Verbindungen. Der Versuch verlangt zusätzlich Version, Vertrag, Testdouble und Fehlerzustand. Eine sichtbare Oberfläche darf eine ungeprüfte Datenverbindung nicht als erledigt erscheinen lassen.
Fordern Sie QA-Belege für Idealweg, geänderte Antwortform und fehlende Konfigurationskennung. Testing und QA sind dokumentiert. DE-152 übernimmt jedoch keine Garantie. Art, Version, Umgebung, Erwartung, Beobachtung, offener Fehler und erneute Prüfung müssen im Export stehen.
Proben Sie Release, anschließende Kontrolle, Rollbackkarte und Rollenentzug. Help Desk und kontinuierlicher Support sind sichtbare Bereiche, belegen aber keine Frist oder technische Übergabe. Rang eins folgt aus Servicegliederung, nicht aus einem getesteten Codebestand.
Quellen zu den Anbietern: ScienceSoft, offizielle Webentwicklungsseite, abgerufen am 30.08.2026
Netguru
Belegte Stärken
- Webanwendungen werden als eigener Umfang beschrieben.
- Ein individuelles CMS ist sichtbar.
- Technologieauswahl und Entwicklung werden als Prozessschritte genannt.
- QA Testing, Launch, Maintenance und Support gehören zum dokumentierten Umfang.
Zu prüfende Grenzen
- Dachdecker-Eignung und deutsche Betreuung sind unbelegt.
- Architekturentscheidungen und Repository-Besitz müssen gezeigt werden.
- Konfigurations-, Release- und Rollbackbelege bleiben offen.
- Fälle, Resultate, Sicherheit, Recovery und Exporttiefe wurden nicht geprüft.
Netguru steht auf Rang zwei. Die offizielle Seite nennt Webanwendungen, ein individuelles CMS, laufende Webentwicklung, Technologieauswahl, Entwicklung, QA Testing, Publishing beziehungsweise Launch, Maintenance und Support. Zahlen, Kundenfälle und Resultate bleiben ausgeschlossen. Unbelegt sind Dachdecker-Eignung, deutsche Betreuung, konkrete Architekturentscheidungen, Repository-Besitz, Konfigurationsgovernance, Releasebelege, Rollback, Recovery, Exporttiefe und tatsächliche Qualität.
Geben Sie Netguru dieselbe Annahmekarte und lassen Sie Technologieauswahl sowie Systemgrenzen begründen. Die Quelle nennt eine Entscheidung über Technologie und Vorgehen. Der Pilot verlangt Optionen, Folgen, offene Risiken und Rücknahmepunkt, ohne ein reales Projekt oder Geschäftsziel zu erfinden.
Modellieren Sie einen leeren CMS-Datensatz und eine neutrale Webanwendung. Ein individuelles CMS und Webanwendungen werden beschrieben. Feldtypen, Rollenklasse, Vorschau, Export und Versionsbezug sind dennoch nicht durch die allgemeine Servicebeschreibung bestätigt und müssen demonstriert werden.
Verfolgen Sie eine Änderung über Entwicklung, QA und Launch. Diese Stationen sind sichtbar. Der Anbieter soll Repository-Version, Build-Artefakt, Zielumgebung, Testbelege und Live-Kontrolle verbinden. Ein Launchbegriff allein belegt keinen reproduzierbaren oder rücknehmbaren Release.
Lassen Sie Wartungsänderung und Exit außerhalb des Anbieterzugangs öffnen. Laufende Entwicklung, Maintenance und Support werden angeboten, doch Frist, Ereignisklasse, letzter Liefergegenstand und Recovery bleiben offen. Rang zwei ist keine praktische Qualitätsbewertung.
Quellen zu den Anbietern: Netguru, offizielle Webentwicklungsseite, abgerufen am 30.08.2026
theStacc Service des Herausgebers, Rang drei
Belegte Stärken
- Website-Erstellung wird beschrieben.
- Hosting gehört zum sichtbaren Umfang.
- Website-Verwaltung wird genannt.
- Das Angebot kann als unabhängiger Gegenversuch dienen.
Zu prüfende Grenzen
- Dienstleister und Herausgeber sind dasselbe Unternehmen.
- Architektur, Repository und CMS-Modell sind nicht dokumentiert.
- QA, Release, Rollback und Zugriffsgovernance bleiben offen.
- Individuelle Entwicklung, Recovery und technischer Export sind unbelegt.
theStacc steht wegen Herausgeberkonflikt und indirekter technischer Passung auf Rang drei. Die Managed-Services-Seite beschreibt Website-Erstellung, Hosting und Verwaltung. Ein detaillierter Entwicklungsablauf mit Architektur, Repository, CMS-Modell, Integration, Umgebungen, Build, QA, Release, Rollback, Zugriffsregister und Export ist dort nicht dokumentiert. Preise, Paketmengen, Ranking-, Wachstums-, Kunden-, Output- und Ergebnisbehauptungen bleiben ausgeschlossen.
Übergeben Sie theStacc dieselbe technische Annahmekarte. Der Anbieter soll den konkreten Liefergegenstand hinter Website-Erstellung zeigen. Erstellung, Hosting und Verwaltung sind sichtbar, aber die Quelle belegt keine individuelle Entwicklungsarchitektur oder reproduzierbare Releasekette. Unabhängige Prüfung ist zwingend.
Fordern Sie Repository oder Codekopie, Buildanweisung, CMS-Modell, Integrationsvertrag und Umgebungsinventar. Wenn ein Gegenstand im tatsächlichen Angebot nicht enthalten ist, bleibt dies offen. DE-152 leitet ihn nicht aus dem allgemeinen Websitebegriff ab.
Trennen Sie Hosting und Verwaltung von institutioneller Kontrolle, Release und Rollback. Ein laufender Dienst kann diese Bereiche verbinden, ersetzt aber keine übertragbaren Artefakte und Rollen. Die verwendete Quelle dokumentiert keine konkrete technische Eigentums- oder Rücknahmeregel.
Exportieren Sie jeden vorhandenen Gegenstand und offene Lücken, dann entziehen Sie eine Testrolle. Kein theStacc-Service, Code, Build, Release, Hostingkonto oder Exit wurde praktisch geprüft. Rang drei macht Interessenkonflikt und begrenzte Beleglage sichtbar.
Quellen zu den Anbietern: theStacc, offizielle Managed-Services-Seite, abgerufen am 30.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.
Drei Anbieter am neutralen Release-Übergabeprotokoll
Die Tabelle ordnet nur sichtbare offizielle Leistungsbereiche technischen Prüfschritten zu. Sie bestätigt keine Preise, Dachdecker-Eignung, Sicherheit, Verfügbarkeit, Vertragsqualität, Hostingqualität, Codequalität oder Ergebnisse.
| Anbieter | Leistungsmodell | Belegter Leistungsumfang | Geeignet für | Wesentliche Einschränkung |
|---|---|---|---|---|
| ScienceSoft | Architektur- und integrationsbetonte Entwicklung | Architektur, Frontend, Backend, APIs, Testing, QA, Support | Schicht- und QA-Pilot | Release offen |
| Netguru | Webanwendung und individuelles CMS | Technologie, Entwicklung, CMS, QA, Launch, Maintenance | CMS-Release-Pilot | Besitz offen |
| theStacc | Indirekter Herausgeber-Service | Website erstellen, hosten und verwalten | unabhängiger Gegenversuch | Lieferkette fehlt |
Den Release-Pilot ohne realen Betrieb, produktive Daten oder Zugangsdaten durchführen
Das Prüfpaket enthält eine neutrale Designkennung, ein abstraktes Seitenobjekt, ein leeres CMS-Modell, eine synthetische API-Antwort, Konfigurationsnamen ohne Werte, drei Umgebungszwecke und einen erfundenen Releasefehler. Es enthält keine Firma, Dachdeckerleistung, Person, Website, Domain, echte Datei, Zugangsdaten, Bewertung, Preis oder Kennzahl.
Geprüft werden Annahme, Architekturentscheidung, Repository-Verwahrung, Build, CMS, Integration, Umgebungen, QA, Release, Kontrolle, Rollback, Betriebsgrenze, Recovery und technischer Export. Jeder Schritt besitzt einen erwarteten Zustand, ohne Anbieterqualität oder geschäftliche Wirkung zu bestätigen.
1. Technische Annahme und Architekturentscheidung abgrenzen
Referenzieren Sie die freigegebene Designfassung aus DE-151 und verbinden Sie sie mit einem neutralen Seitenobjekt. Anforderungen, offene Fragen, technische Grenzen, Ausschlüsse und Abnahmekriterien bleiben getrennt. Eine fehlende Designentscheidung geht als Rückfrage zurück.
Erstellen Sie Entscheidungskarten für Rendering, CMS, Integration, Build und Zielumgebung. Jede Karte nennt Problem, Optionen, gewählten Weg, Folgen, offene Risiken und Rücknahmepunkt. Ein Frameworklogo ohne begründete Beziehung zu anderen Schichten reicht nicht.
Ändern Sie die Designkennung einer Komponente. Nur die betroffene technische Aufgabe öffnet sich. Architekturentscheidungen ohne Abhängigkeit bleiben bestehen. Das Protokoll zeigt, ob der Anbieter Eingabeänderung und eigene Codeänderung sauber unterscheidet.
- Design referenziert.
- Anforderungen neutral.
- Grenzen sichtbar.
- Optionen dokumentiert.
- Risiken offen.
- Rückfrage getrennt.
2. Repository, Build und Konfiguration reproduzierbar halten
Inventarisieren Sie institutionelle Repository-Kontrolle, Agenturrolle, Branchregel, Reviewstatus, Laufzeit, Abhängigkeiten, Buildbefehl und Artefaktziel. Es werden keine Zugangsdaten erzeugt. Eine persönliche Kopie darf nicht die einzige technische Quelle sein.
Benennen Sie Konfigurationsklassen für Vorschau, Test und Produktion ohne Werte. Für jede Klasse stehen Herkunft, kontrollierende Rolle, Prüfung bei Fehlen und Entzugsweg fest. Geheimnisse gehören weder in Code noch in den Artikel oder das Übergabepaket.
Erzeugen Sie eine neutrale Codeänderung und verfolgen Sie Commitbezug, Review, Build und Artefakt. Ein anderer Arbeitsplatz muss den Buildweg aus dokumentierten Voraussetzungen verstehen. Manuelle Schritte bleiben sichtbar, bis sie ersetzt oder ausdrücklich akzeptiert werden.
- Repository institutionell.
- Rollen begrenzt.
- Abhängigkeiten festgehalten.
- Buildweg dokumentiert.
- Werte bleiben geheim.
- Manuelle Schritte sichtbar.
3. CMS-Modell und Integration getrennt prüfen
Legen Sie ein leeres CMS-Modell mit Feldtyp, Pflichtstatus, erlaubtem Leerzustand, Vorschau, Rollenklasse und Exportform an. Es gibt keinen echten Dachdeckerinhalt. Ein Login oder fertiges Formular bestätigt weder Modellqualität noch Übergabefähigkeit.
Definieren Sie eine synthetische Integration mit Eingabe, Ausgabe, Fehlerklasse, Timeout, Testdouble und verantworteter Grenze. Frontend, Backend und Vertrag behalten getrennte Versionen. Ein Idealzustand allein belegt keine funktionierende oder belastbare Verbindung.
Ändern Sie die Antwortform und lassen Sie ein CMS-Feld leer. Der Anbieter soll betroffene Tests und Komponenten öffnen, ohne unbeteiligte Arbeit zurückzusetzen. Kein echter Dienst, Schlüssel oder personenbezogener Datensatz wird verwendet.
- CMS leer.
- Feldtypen sichtbar.
- Export benannt.
- API synthetisch.
- Fehlerweg vorhanden.
- Schichten getrennt.
4. QA, Release und Rollback als eine Kette lesen
Planen Sie nur Tests mit benanntem Gegenstand. Jeder Beleg nennt Testklasse, Quellversion, Umgebung, Eingabe, erwarteten Zustand, beobachteten Zustand, Ergebnis und offene Ausnahme. Ein pauschaler Status ersetzt diese Zuordnung nicht.
Erstellen Sie einen neutralen Releaseeintrag aus Quellversion, Build-Artefakt, Freigabe, Ziel, Zeitpunkt, Ergebnis und anschließender Kontrolle. Die Kontrolle liest nur die vereinbarte Zustandskennung. Sie misst keine Geschwindigkeit, Reichweite, Conversion oder Suchposition.
Lösen Sie einen künstlichen Fehler aus und lesen Sie die vorbereitete Rollbackkarte. Vorherige Fassung, Daten- oder Modellgrenze, entscheidende Rolle und Abschlusskontrolle müssen bekannt sein. Der Pilot verändert keine produktive Website und bestätigt keine tatsächliche Recovery.
- Tests adressiert.
- Version und Umgebung genannt.
- Ausnahmen sichtbar.
- Release referenziert.
- Vorherige Fassung bekannt.
- Keine Produktivänderung.
5. Betriebsgrenzen und technischen Exit proben
Ordnen Sie Buildfehler, fehlende Konfiguration, nicht erreichbare Anwendung und Integrationsabweichung neutralen Ereignisklassen zu. Für jede Klasse stehen Erkennungspunkt, verantwortete Rolle, nächster Beleg und Übergabegrenze fest. Reaktionszeit und Verfügbarkeit bleiben offen.
Exportieren Sie Architekturkarten, Code, Abhängigkeiten, Buildweg, CMS-Modell, Integrationsverträge, Umgebungsinventar, QA-Belege, Releasehistorie, Rollbackkarten, Rollenklassen und offene Fehler. Öffnen Sie das Paket außerhalb des Agenturportals.
Entziehen Sie eine begrenzte Testrolle und starten Sie den neutralen Wiederanlaufweg. Das übernehmende Team muss gültige Version, Build, bekannte Zielumgebung und offene Lücken erkennen. Der Versuch bestätigt nur Lesbarkeit, nicht Sicherheit, Hostingniveau oder Anbieterleistung.
- Ereignisse getrennt.
- Zuständigkeit sichtbar.
- Code exportiert.
- Historie lesbar.
- Rolle entzogen.
- Grenzen offen.
Fehler, die einen SEO-Vergleich wertlos machen
- Ein Framework als vollständige Architektur behandeln. Rendering, CMS, Integration, Build, Betrieb, Folgen und Rücknahmepunkte brauchen begründete Beziehungen.
- Code nur in einem Agenturzugang verwahren. Institutionelle Kontrolle, Rollen, Reviews, Abhängigkeiten und übertragbare Kopie müssen vor dem Exit feststehen.
- Einen CMS-Login als Übergabe ansehen. Modell, Feldzustände, Vorschau, Rollenklasse, Versionsbezug und Exportform sind eigene Liefergegenstände.
- Nur den Idealweg einer Integration zeigen. Synthetischer Vertrag, geänderte Antwort, Timeout, Fehlerklasse und verantwortete Grenze gehören zur Prüfung.
- QA als pauschalen Status speichern. Testklasse, Version, Umgebung, Erwartung, Beobachtung und offene Ausnahme müssen gemeinsam lesbar sein.
- Upload und erfolgreiche Live-Kontrolle gleichsetzen. Release-Artefakt, Ziel, Ergebnis und anschließende Prüfung sind getrennte technische Zustände.
- Rollback erst nach einem Fehler erfinden. Vorherige Fassung, Auslöser, Modellgrenze, Rolle und Abschlusskontrolle werden vor dem Release benannt.
- Support ohne letzten Liefergegenstand einkaufen. Diagnose, Änderung, Test, Release, Dokumentation und offene Restarbeit bleiben versioniert.
- Designfragen still in Code schließen. Offene Gestaltung geht an DE-151 zurück und erhält eine neue freigegebene Eingabefassung.
Häufige Fragen
Welche Webentwicklungsagentur führt den neutralen Release-Pilot an?
ScienceSoft steht zuerst, weil die offizielle Seite Architektur, Frontend, Backend, API-Integration, Testing und QA sowie Support getrennt nennt. Netguru folgt mit Webanwendungen, individuellem CMS, Technologieauswahl, Entwicklung, QA, Launch und Wartung. theStacc bleibt wegen Herausgeberkonflikt und fehlender technischer Lieferkette zuletzt. Keine Position belegt Dachdecker-Eignung, Qualität oder Ergebnisse.
Was sollte ein Webentwicklungsangebot für Dachdecker enthalten?
Ein belastbares Angebot nennt technische Annahme, Architekturentscheidungen, Repository-Kontrolle, Reviews, Laufzeit, Abhängigkeiten, Build, CMS-Modell, Integrationsverträge, Umgebungen, Konfigurationsklassen, QA-Belege, Release, Live-Kontrolle, Rollback, Betriebsgrenzen, Zugriffsregister, Recovery und Export. Für jeden Gegenstand stehen letzter bezahlter Zustand, Ausschlüsse und Übergabeform fest. Webdesign, SEO und Marketing bleiben getrennt.
Welche Betriebsdaten werden für den technischen Pilot benötigt?
Der neutrale Pilot benötigt keine realen Betriebsdaten. Eine freigegebene Designkennung, ein abstraktes Seitenobjekt, ein leeres CMS-Modell, eine synthetische API-Antwort und Konfigurationsnamen ohne Werte reichen aus. Der Anbieter demonstriert technische Zustände, ohne Firma, Region, Dachdeckerleistung, Person, Domain, Website, Zugangsdaten, Kundenfall, Preis, Bewertung, Kennzahl oder Ergebnis zu erfinden.
Wem sollte das Repository gehören?
Die institutionelle Kontrolle sollte vertraglich geklärt und unabhängig von einer einzelnen Agenturperson erreichbar sein. Der Pilot inventarisiert Eigentumsgrenze, Dienstleisterrolle, Branchregel, Reviewweg, Abhängigkeiten, Buildanweisung und Export. Er legt keinen bestimmten Plattformanbieter fest und testet keinen Transfer. Entscheidend ist, dass ein Dienstleisterwechsel nicht zuerst eine unbekannte Codekopie rekonstruieren muss.
Was gehört zu einem reproduzierbaren Build?
Ein reproduzierbarer Build benötigt dokumentierte Laufzeit, Abhängigkeitsdefinition, Installationsweg, Befehl, erwartetes Artefakt, Konfigurationsklassen und bekannte manuelle Schritte. Die Quellversion bleibt mit dem Ergebnis verbunden. Der neutrale Versuch beweist keine vollständige Reproduzierbarkeit eines realen Projekts, zeigt aber, ob ein anderes technisches Team Voraussetzungen und Lücken außerhalb des Agenturrechners verstehen kann.
Wie wird ein CMS ohne echte Inhalte geprüft?
Verwenden Sie ein leeres Modell mit Feldnamen, Typen, Pflichtstatus, erlaubten Leerzuständen, Vorschauweg, Rollenklassen, Versionsbezug und Exportform. Es enthält keine Dachdeckerangaben. Danach wird eine Modelländerung verfolgt. Ein vorhandener Login oder Editor genügt nicht, wenn Struktur, Migration, Zugriffsgrenze und übertragbarer Inhaltsbestand für ein neues Team unklar bleiben.
Wie lässt sich eine Integration ohne echten Drittanbieter testen?
Ein synthetischer Vertrag beschreibt Eingabeform, Ausgabeform, Fehlerklasse, Timeout, Testdouble und verantwortete Systemseite. Der Pilot prüft Idealzustand, veränderte Antwort und Ausfall, ohne einen realen Dienst oder Schlüssel zu verwenden. Frontend, Backend und Vertrag behalten eigene Versionen. Dadurch bleibt sichtbar, welche Schicht einen Fehler besitzt und welche Arbeit weiterhin gültig ist.
Welche Informationen gehören in einen QA-Beleg?
Der Beleg nennt Testklasse, Quellversion, Build-Artefakt, Umgebung, Eingabe, erwarteten Zustand, beobachteten Zustand, Ergebnis und offene Ausnahme. Nur Tests mit einem benannten Gegenstand werden aufgenommen. Ein grüner Gesamtstatus ist zu grob, wenn unbekannt bleibt, welche Fassung, Schicht oder Fehlerbedingung tatsächlich betrachtet wurde. Spätere menschliche Prüfung bleibt zusätzlich erforderlich.
Was unterscheidet Release, Live-Kontrolle und Rollback?
Der Release überführt ein bestimmtes Build-Artefakt in eine Zielumgebung. Die anschließende Kontrolle prüft den vereinbarten technischen Zustand. Rollback beschreibt die vorbereitete Rücknahme auf eine bekannte Fassung samt Daten- oder Modellgrenze und Abschlusskontrolle. Diese Schritte erhalten getrennte Belege. DE-152 führt keinen produktiven Release oder Rollback aus und bestätigt keine tatsächliche Wiederherstellung.
Wo endet DE-151 und wo beginnt DE-152?
DE-151 besitzt Discovery, Informationsarchitektur, Sitemap, Wireframes, visuelle Regeln, UI-Zustände, responsive Designspezifikation, Content-Handoff, Assets, Reviews und Designexport. DE-152 übernimmt nur eine freigegebene Fassung und besitzt Architektur, Code, CMS, Integration, Build, QA, Release und technischen Exit. Eine offene Designfrage darf nicht still als Entwicklungsentscheidung geschlossen werden.
Warum steht theStacc auf Rang drei?
theStacc verkauft den verglichenen Managed-Service und veröffentlicht zugleich diese Seite. Die offizielle Quelle beschreibt Website-Erstellung, Hosting und Verwaltung, aber keinen detaillierten Ablauf für Architektur, Repository, CMS-Modell, Integrationen, Umgebungen, Build, QA, Release, Rollback und technischen Export. Rang drei macht den wirtschaftlichen Konflikt und die begrenztere sichtbare Beleglage gemeinsam deutlich.
Warum bleibt DE-152 in menschlicher Prüfung?
Die Seite stützt sich auf drei offizielle Anbieterquellen und einen abstrakten technischen Pilot. Kein Anbieter, Vertrag, Betrieb, Repository, Code, CMS, Build, Test, Release, Hostingkonto, Rollback, Recovery oder Exit wurde praktisch geprüft. Dachdecker-Eignung, deutsche Sprache, Rechte, Sicherheit, Zugänglichkeit, Hostingqualität und tatsächliche Umsetzung bleiben offen. Deshalb gilt needs_human_review bis Fach-, Sprach- und Wartungsprüfung benannt sind.
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.
Nehmen Sie den reproduzierbaren Releaseweg ab, nicht nur die Live-Seite
Ein belastbarer Pilot verbindet Annahme, Architektur, Repository, Build, CMS, Integration, QA, Release und Rollback in einer extern lesbaren Kette. Danach werden Code, Modelle, Historie, Rollen und offene Fehler außerhalb des Agenturzugangs geöffnet. DE-152 braucht vor Veröffentlichung weiterhin fachkundige Prüfung, deutsche Sprachprüfung und einen benannten Wartungsverantwortlichen.