Ein Entwicklungsangebot kann Framework, CMS und Launch nennen, ohne zu erklären, wo der übergebbare technische Bestand liegt. Eine Website kann sichtbar funktionieren und trotzdem an Agenturkonten, unbekannte Build-Schritte, nicht dokumentierte Integrationen oder einen nicht übertragbaren Bereitstellungsweg gebunden sein.
DE-146 vergleicht deshalb keine behauptete Leistung. Der Einkaufsgegenstand ist eine reproduzierbare technische Zustandskette. Anforderung, Architekturentscheidung, Codeänderung, Build, Test, Deployment und Recovery erhalten benannte Eingaben und Ausgaben. Der Live-Zustand bleibt mit Repository und Version verbunden.
Der neutrale Pilot nutzt eine abstrakte Informationsseite, ein generisches Inhaltsobjekt, eine synthetische API-Antwort und leere Umgebungen. Es gibt keine echte Praxis, keine Person und keine produktiven Zugangsdaten. Ein absichtlich fehlernder Konfigurationswert und eine geänderte Designversion machen Übergabegrenzen sichtbar.
Design und Marketing bleiben getrennt. DE-145 liefert spezifizierte Designartefakte. DE-141 bis DE-144 liefern oder koordinieren Marketinganforderungen. DE-146 darf diese Eingaben implementieren, aber keine offenen Design-, Inhalts- oder Kampagnenentscheidungen stillschweigend lösen.
theStacc veröffentlicht DE-146 und bietet zugleich den auf Rang vier 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 sechs offiziellen URLs, die am 30. August 2026 erreichbar waren: den Webentwicklungsseiten von Netguru, Lounge Lizard und Bop Design, der Managed-Services-Seite von theStacc, den Entwicklungstipps der W3C Web Accessibility Initiative sowie der GitHub-Dokumentation zum Repository-Transfer. Wir haben keinen Anbieter, Vertrag, Account, Zahnarzt, keine Praxis, Website, Architektur, Codebasis, Integration, Umgebung, Prüfung, Bereitstellung, Zugangsdaten, Repository, Rechnung, Kündigung, Recovery oder Übergabe praktisch getestet. Preise, Laufzeiten, Teamzuschnitt, deutschsprachige Betreuung, Sicherheit, Hosting, Vertragsbedingungen, Berechtigungen, Datenqualität, Support und Eignung bleiben offen. Anbieterquellen belegen nur den eigenen beschriebenen Leistungsbereich und keine objektive Überlegenheit. Der Pilot verwendet abstrakte Anforderungen, neutrale Datenobjekte, synthetische Integrationsverträge, leere Umgebungen und Testkennungen ohne reale Werte. Er enthält keine realen Praxen, Zahnärzte, Patienten, Websites, Fälle, Testimonials, Bewertungen, Preise, Tests, Rankings, Leads, Umsätze, Personen, Prüfer oder Eigentümer. Klinische, diagnostische, therapeutische, sicherheitsbezogene, rechtliche, datenschutzbezogene, patientenbezogene und Konformitätsaussagen bleiben vollständig außerhalb. DE-145 besitzt Discovery für Gestaltung, Informationsarchitektur, UI, Content-Handoff und Designexport. DE-141 bis DE-144 besitzen organische SEO, Local SEO, Social Media und breite Marketingsteuerung. DE-146 besitzt nur technische Discovery, Architektur, Implementierung, CMS- und Integrationsgrenzen, Umgebungen, QA, Deployment, Zugriffe, Repository, Recovery und technischen Export. Eine fachkundige Prüfung, eine deutsche Sprachprüfung und ein Wartungsverantwortlicher sind nicht benannt. DE-146 bleibt needs_human_review und ist nicht automatisch zur Veröffentlichung freigegeben.
Die kurze Antwort
Netguru führt den neutralen Auswahlpilot an, weil die offizielle Seite Discovery, Architektur, Frontend, Backend, Full Stack, CMS, QA, Publishing und Wartung sichtbar beschreibt. Lounge Lizard folgt mit modernen Frameworks, skalierbarer Architektur, WordPress und Testing. Bop Design steht für WordPress-Backend und Cross-Browser-Tests. theStacc bleibt wegen Herausgeberkonflikt und nicht dokumentiertem Entwicklungsprozess auf Rang vier. Keine Quelle belegt Dental-Eignung.
- Netguru: Praxisteams, die Discovery, Architektur, Frontend, Backend, CMS, QA, Publishing und Wartungsgrenzen in einem technischen Pilot demonstrieren lassen möchten
- Lounge Lizard: Praxisteams, die moderne Frameworks, Architektur, WordPress, Testing und Launch als getrennte technische Stationen prüfen wollen
- Bop Design: Praxisteams, die einen engeren WordPress-Pilot für Inhaltsmodell, Backend, responsive Umsetzung und Browserprüfungen durchführen möchten
- theStacc: Praxisteams, die einen indirekten Website-Service unabhängig gegen dokumentierte Entwicklungsprozesse abgrenzen möchten
Der beschaffbare technische Lieferweg für eine Zahnarzt-Website
Technische Discovery beginnt mit einem Anforderungsregister. Jede abstrakte Zeile enthält Geschäftsaufgabe, Designreferenz, Inhaltsobjekt, technische Abhängigkeit, unbekannte Annahme, Abnahmekriterium und Ausschluss. Im Pilot fehlen reale Praxiswerte. Die Agentur soll Unsicherheit auflösen oder sichtbar erhalten, nicht mit erfundenem Kontext schließen.
Eine Architekturentscheidung beschreibt Problem, betrachtete Optionen, gewählte Richtung, Folgen, offene Risiken und Rücknahmepunkt. Framework oder CMS allein sind keine Architektur. Der Pilot prüft, ob Seitenrendering, Inhaltsverwaltung, Integration, Build und Deployment nachvollziehbar zusammenspielen.
Design aus DE-145 ist eine versionierte Eingabe. Komponenten, Tokens, Layoutzustände, Content-Felder und offene Fragen werden im Entwicklungsbrief referenziert. Ändert sich die Designversion, öffnet sich nur die betroffene Implementierung. Entwickler dürfen eine offene visuelle Entscheidung nicht als technische Notwendigkeit ausgeben.
Das Repository wird vor dem ersten Build geklärt. Institutioneller Besitz, Agenturzugriff, Branchmodell, Reviewweg, Abhängigkeiten, Buildanweisung und Artefaktziel stehen im Pilot als Felder. GitHub dokumentiert Repository-Transfer als eigenen Vorgang. Das belegt keinen Anbieterworkflow, begründet aber die Frage nach Übertragbarkeit.
Frontend und Backend erhalten getrennte Arbeitsenden. Ein implementierter Komponentenstand ist nicht dasselbe wie eine integrierte Datenquelle. Eine API-Anbindung ist nicht durch ein sichtbares Formular bestätigt. Der Pilot verfolgt Code, Vertrag, Test und Fehlerzustand je Schicht, ohne reale Daten zu verwenden.
CMS-Arbeit beginnt mit einem Inhaltsmodell. Neutrale Felder besitzen Typ, Pflichtstatus, erlaubten Zustand, Vorschauweg, Versionsbezug und Exportform. DE-146 erfindet keine Praxisinhalte. Ein CMS gilt im Pilot nicht als handhabbar, nur weil ein Login existiert. Modell, Rollen und Export müssen demonstriert werden.
Integrationen werden über Verträge beschrieben. Endpunktklasse, Eingabeform, Ausgabeform, Fehlerzustand, Timeout, Testdouble und verantwortete Grenze reichen für den neutralen Pilot. Es gibt keinen echten Drittanbieter und keinen geheimen Schlüssel. Der Dienstleister soll zeigen, wie Ausfall und Änderung isoliert werden.
Umgebungen brauchen eindeutige Zwecke. Lokale Entwicklung, Vorschau, Test und Produktion dürfen unterschiedliche Konfigurationen besitzen, aber keine unlesbare Handarbeit erfordern. Der Pilot nutzt leere Werte und Konfigurationsnamen. Zugangsdaten werden weder erzeugt noch angezeigt. Unbekannte Variablen bleiben als Übergabelücke sichtbar.
Ein Build muss aus dokumentierten Eingaben reproduzierbar sein. Laufzeit, Paketdefinition, Installationsweg, Buildbefehl, Ausgabeverzeichnis und bekannte Voraussetzungen werden festgehalten. DE-146 führt keinen vollständigen Projektbuild aus. Der Anbieter muss im Pilot erklären, welche Schritte automatisiert und welche manuell bleiben.
QA beginnt mit Akzeptanzkriterien, nicht mit dem Satz getestet. Unit-, Komponenten-, Integrations-, End-to-End- und manuelle Prüfungen können unterschiedliche Gegenstände besitzen. Der Pilot verwendet nur neutrale Testfälle. Umfang, Umgebung, Version, Ergebnis und offener Fehler müssen lesbar bleiben.
Die W3C Web Accessibility Initiative veröffentlicht Entwicklungstipps für Webzugänglichkeit. DE-146 nutzt sie als Fragenkatalog zu semantischer Struktur, Tastaturnutzung, Formularen und DOM-Reihenfolge. Die Quelle ist kein Konformitätsnachweis. Kein Anbieter wird zertifiziert, und eine spätere technische sowie menschliche Prüfung bleibt offen.
Deployment ist eine Zustandsänderung mit Beleg. Quellversion, Build-Artefakt, Zielumgebung, Freigabe, Zeitpunkt, Ergebnis, bekannte vorherige Version und Rücknahmeweg werden referenziert. Ein erfolgreiches Upload-Signal belegt noch keine korrekte Live-Ausgabe. Der Pilot fordert eine anschließende neutrale Kontrolle.
Zugangsdaten bleiben außerhalb von Quellcode, Artikel und Exportbeispiel. DE-146 prüft nur Inventar, Eigentumsgrenze, Ablageklasse, Rotationseigentum und Entzugsweg. Es wird kein Geheimnis erzeugt oder gelesen. Ein Agenturkonto darf nicht der einzige Rückweg in Repository, CMS oder Deployment sein.
Asset-Eigentum wird technisch adressierbar. Designassets aus DE-145, statische Dateien, Medienvarianten, Schriftreferenzen und generierte Build-Artefakte besitzen Quellen- und Zielbezug. Der Pilot enthält keine reale Datei. Eine synthetische Kennung zeigt, ob Ersetzung, Build und Deployment den Zusammenhang erhalten.
Recovery wird als Übung ohne Störung beschrieben. Repository-Kopie, dokumentierter Build, bekannte vorherige Version, Umgebungsinventar, Inhaltsbackup-Klasse und Zugangsentzug bilden den neutralen Fall. DE-146 behauptet keine Backup-, Hosting- oder Sicherheitsgarantie. Der Anbieter muss nur seinen verantworteten Wiederanlaufweg zeigen.
Monitoring und Wartung sind getrennte Verträge. Eine Agentur kann Support oder Wartung anbieten, doch der Umfang braucht Ereignisklasse, Reaktionsweg, Liefergegenstand, Version und Übergabe. DE-146 erfindet keine Laufzeit oder Zusage. Nicht angebotene oder ungeklärte Arbeit bleibt sichtbar offen.
Der technische Export enthält Repository oder übertragbare Codekopie, Buildanweisung, Abhängigkeitsdateien, Architekturentscheidungen, CMS-Modell, Integrationsverträge, Umgebungsinventar, Testbelege, Deploymenthistorie, Zugangsinventar und offene Fehler. Ein PDF kann erklären, ersetzt aber keinen ausführbaren Bestand.
Der Exit wird vor einer langen Bindung geprobt. Eine Testrolle wird entzogen, eine neutrale Codeänderung außerhalb des Agenturkontos gebaut und ein synthetischer Fehler bis zur bekannten vorherigen Version verfolgt. Der nächste technische Arbeitsweg muss ohne das alte Portal verstehen, was live, offen, reproduzierbar und rücknehmbar ist.
Branchenspezifische Nachweise, nach denen Sie fragen sollten
- Technische Anforderungen verweisen auf die freigegebene Design-, Inhalts- und Datenversion.
- Architekturentscheidungen nennen Optionen, Folgen, offene Risiken und Rücknahmepunkte.
- Repository, Branches, Reviews, Abhängigkeiten und Buildanweisung bleiben institutionell zugänglich.
- CMS-Modelle und Integrationsverträge sind ohne reale Praxis- oder Zugangsdaten prüfbar.
- Entwicklung, Vorschau, Test und Produktion besitzen dokumentierte Zwecke und Konfigurationsgrenzen.
- QA-Ergebnisse beziehen sich auf Testart, Umgebung, Version und offenen Fehler.
- Deployment und Live-Kontrolle behalten Artefakt, Ziel und vorherige Version.
- Code, Dokumentation, Tests, Zugriffe, Recovery und offene Arbeit sind exportierbar.
So haben wir die Anbieter bewertet
Netguru steht vorn, weil die offizielle Seite Product Discovery, Architektur, Frontend, Backend, Full Stack, Low Code, Cloud, CMS, Coding, QA Testing, Publishing, Maintenance und Support sichtbar beschreibt. Diese Breite passt zum neutralen technischen Lieferweg. Sie belegt keine Dental-Eignung, sichere Implementierung, Konformität oder Resultate.
Lounge Lizard folgt. Die offizielle Seite nennt moderne Frameworks, skalierbare Architektur, sauberen Code, Custom WordPress sowie einen Prozess mit Entwicklung, Testing und Launch. DE-146 übernimmt keine Leistungs-, Sicherheits- oder Ergebnisbehauptungen. Relevant sind nur die dokumentierten technischen Bereiche und Übergabefragen.
Bop Design steht auf Rang drei. Die offizielle Entwicklungsseite beschreibt ein angepasstes WordPress-CMS, Backend-Programmierung, responsive Umsetzung, Cross-Browser-Tests und eine selbst verwaltbare WordPress-Website. Der Umfang ist klarer, aber enger als bei den ersten beiden Seiten. Repository, Umgebungen, Deployment und Recovery bleiben offen.
theStacc steht auf Rang vier. Die Managed-Services-Seite beschreibt Website-Erstellung, Hosting und Verwaltung. Sie dokumentiert dort jedoch keinen technischen Discovery-, Architektur-, Repository-, Integrations-, QA-, Deployment-, Credential-, Recovery- oder Exportprozess. Damit ist die Passung zu DE-146 indirekt.
theStacc ist zugleich Herausgeber. Der Anbieter erhält keine bevorzugte Platzierung und muss denselben neutralen Pilot unter unabhängiger Fach- und Sprachprüfung durchlaufen. Preise, Mengen, Fallbeispiele und Ergebnisbehauptungen der Quellseite werden nicht übernommen. Custom Development wird nicht aus der Bezeichnung Website abgeleitet.
W3C und GitHub dienen als methodische Quellen und sind keine Anbieter. W3C stützt Fragen zur zugänglichen technischen Umsetzung, GitHub dokumentiert Repository-Transfer. Keine Quelle bestätigt einen Anbieterprozess, eine Konformität oder einen sicheren Betrieb. Sie helfen nur bei QA-, Besitz-, Übergabe- und Recovery-Fragen.
Preise, Websites, Tests, Rankings, Leads, Umsatz, Patientenbezug, Testimonials und Fallstudien fließen nicht in die Reihenfolge ein. Jeder Rang ist eine redaktionelle Passung zum abstrakten Build-Pilot. Architektur, Code, CMS, Integration, Umgebung, QA, Deployment, Besitz, Recovery und Export bleiben zu demonstrieren.
| Kriterium | Gewichtung | Was gezählt hat |
|---|---|---|
| Technische Discovery und Architektur | Hohe Priorität | Anforderungen, Designversion, Datenobjekte, Optionen, Folgen und Rücknahmepunkte werden vor Code geklärt. |
| Implementierung und Integrationsgrenzen | Hohe Priorität | Frontend, Backend, CMS und externe Verträge besitzen getrennte Eingaben, Fehlerzustände und Abnahmen. |
| Repository und Umgebungen | Hohe Priorität | Codebesitz, Branches, Reviews, Konfigurationen, Build und Zielumgebungen bleiben institutionell lesbar. |
| QA und zugängliche Umsetzung | Hohe Priorität | Tests verweisen auf Art, Version, Umgebung und Ergebnis, ohne Konformität oder Sicherheit zu behaupten. |
| Deployment und Recovery | Hohe Priorität | Artefakt, Freigabe, Ziel, Live-Kontrolle, vorherige Version und Wiederanlaufweg bleiben verbunden. |
| Technischer Export und Exit | Mittlere Priorität | Code, Build, Modelle, Verträge, Tests, Zugriffe, Historie und offene Fehler sind extern übernehmbar. |
Jeder Anbieter musste dieselben Mindestanforderungen erfüllen, bevor seine Position überhaupt betrachtet wurde.
- Eine erreichbare offizielle Seite beschreibt Webentwicklung oder einen dokumentierten Website-Erstellungsbereich.
- Der Umfang lässt sich mit abstrakten Anforderungen, synthetischen Integrationen und leeren Umgebungen prüfen.
- Ungeprüfte Preise, Resultate, Testimonials, Fallstudien, Sicherheit und Dental-Eignung werden nicht übernommen.
- Technische Umsetzung kann von Webdesign, SEO und Marketing als eigener Liefergegenstand getrennt werden.
- Architektur, Implementierung, CMS, QA oder Website-Erstellung sind auf der verwendeten Quelle 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.
Netguru
Belegte Stärken
- Product Discovery und Architektur sind sichtbar.
- Frontend, Backend und Full Stack werden getrennt beschrieben.
- CMS-, Low-Code- und Cloud-Entwicklung werden genannt.
- Coding, QA Testing, Publishing, Maintenance und Support erscheinen im Umfang.
Zu prüfende Grenzen
- Dental-Eignung wird durch die Seite nicht belegt.
- Repository-, Credential- und Umgebungsgovernance müssen gezeigt werden.
- W3C-Konformität und sichere Umsetzung werden nicht bestätigt.
- Deutsche Betreuung, Recovery und Exporttiefe bleiben offen.
Netguru führt DE-146 an, weil die offizielle Seite den breitesten sichtbaren technischen Umfang beschreibt. Genannt werden Discovery, Architektur, Frontend, Backend, Full Stack, Low Code, Cloud, CMS, Coding, QA Testing, Publishing, Maintenance und Support. Nicht belegt sind Dental-Eignung, deutsche Betreuung, konkrete Repository- und Credential-Governance, sichere Umsetzung, Konformität, Recovery, Exporttiefe oder Resultate.
Übergeben Sie Netguru ein abstraktes Anforderungsregister, die Designversion aus DE-145 und eine synthetische Integration. Der Anbieter soll zeigen, wie Discovery zu Architekturentscheidungen und technischen Abnahmen führt. Discovery und mehrere Architekturbereiche sind offiziell sichtbar. Ein konkreter Projektworkflow bleibt zu demonstrieren.
Fordern Sie getrennte Frontend-, Backend- und CMS-Arbeitsstände. Eine sichtbare Seite darf keine unbekannte Datenintegration verdecken. Netguru beschreibt diese Entwicklungsbereiche sowie einen dedizierten CMS-Umfang. Der Pilot prüft zusätzlich Modellversion, Fehlerzustand, Testdouble und Export.
Prüfen Sie Repository-Besitz, Branchmodell, Umgebungen, Build, QA und Deployment. Coding, QA Testing, Publishing und Maintenance sind auf der Quelle genannt. Sie belegen aber weder institutionelle Kontoführung noch einen reproduzierbaren Build oder Recovery-Weg für eine Zahnarztpraxis.
Exportieren Sie Architekturentscheidungen, Code, Abhängigkeiten, CMS-Modell, Integrationsverträge, Tests, Deploymenthistorie, Zugriffsregister und offene Fehler. Rang eins folgt aus dokumentierter Breite. DE-146 hat keinen Account, Codebestand, Build, Test oder Anbieterwechsel praktisch geprüft.
Quellen zu den Anbietern: Netguru, offizielle Webentwicklungsseite, abgerufen am 30.08.2026
Lounge Lizard
Belegte Stärken
- Moderne Entwicklungsframeworks werden genannt.
- Skalierbare Architektur und sauberer Code sind sichtbar beschrieben.
- Custom WordPress gehört zum Leistungsumfang.
- Entwicklung, Testing und Launch erscheinen als Prozessstationen.
Zu prüfende Grenzen
- Dental-Eignung und deutsche Betreuung sind unbelegt.
- Repository, Integrationsverträge und Umgebungen müssen gezeigt werden.
- Credential-, Deployment- und Recovery-Wege bleiben offen.
- Sicherheit, Konformität und Exporttiefe werden nicht bestätigt.
Lounge Lizard steht auf Rang zwei. Die offizielle Seite beschreibt moderne Frameworks, skalierbare Architektur, sauberen Code, Custom WordPress und einen Ablauf mit Entwicklung, Testing und Launch. Das passt zu Architektur-, CMS- und QA-Fragen. Unbelegt bleiben Dental-Eignung, deutsche Betreuung, Repository-Besitz, Integrationsverträge, Umgebungen, Credential-Modell, Deploymentdetails, Recovery, Exporttiefe und Resultate.
Geben Sie Lounge Lizard dieselben neutralen Anforderungen und Designreferenzen. Der Anbieter soll Architektur, Framework-Entscheidung und Abnahmekriterien erklären, ohne eine offene Designfrage zu lösen. Moderne Frameworks und skalierbare Architektur werden offiziell beschrieben. Konkrete Entscheidungen bleiben im Pilot zu zeigen.
Prüfen Sie ein neutrales WordPress-Inhaltsmodell mit leeren Feldern, Vorschauzustand und Exportfrage. Custom WordPress ist sichtbar. DE-146 übernimmt keine Sicherheits- oder Hostinggarantie und kein reales Praxisobjekt. Rollen, Modellmigration und technischer Exit müssen demonstriert werden.
Verfolgen Sie eine synthetische Änderung über Repository, Build, Test und Launch. Testing und Launch sind auf der Quelle genannt. Sie belegen keinen bestimmten Build-, Deployment- oder Rollback-Weg. Der Anbieter muss Version, Umgebung, Ergebnis und bekannte vorherige Fassung sichtbar halten.
Lassen Sie Code, Abhängigkeiten, CMS-Modell, Tests, Umgebungen, Deployments und Zugriffe exportieren. Rang zwei folgt aus dem dokumentierten technischen Umfang, nicht aus einer getesteten Website. Kein Anbieterprozess, Zugriff oder Recovery-Fall wurde praktisch beobachtet.
Quellen zu den Anbietern: Lounge Lizard, offizielle Webentwicklungsseite, abgerufen am 30.08.2026
Bop Design
Belegte Stärken
- Ein angepasstes WordPress-CMS wird beschrieben.
- Backend-Programmierung gehört zum sichtbaren Umfang.
- Responsive Webentwicklung wird genannt.
- Cross-Browser-Tests und selbst verwaltbares WordPress sind sichtbar.
Zu prüfende Grenzen
- Dental-Eignung und deutsche Betreuung sind unbelegt.
- Architektur, Repository und Integrationsgrenzen müssen gezeigt werden.
- Umgebungen, Deployment und Credentials bleiben offen.
- Recovery, Konformität und technischer Export wurden nicht geprüft.
Bop Design steht auf Rang drei. Die offizielle Entwicklungsseite beschreibt ein angepasstes WordPress-CMS, Backend-Programmierung, responsive Umsetzung, Cross-Browser-Tests und eine selbst verwaltbare WordPress-Website. Der Umfang ist technisch relevant, aber enger. Dental-Eignung, deutsche Betreuung, Architekturentscheidungen, Repository, Integrationen, Umgebungen, Deployment, Credentials, Recovery, Exporttiefe und Resultate bleiben unbelegt.
Übergeben Sie Bop Design ein neutrales WordPress-Inhaltsmodell ohne reale Werte. Der Anbieter soll Felder, Rollen, Vorschau, Versionsbezug und Export erklären. Ein angepasstes WordPress-CMS und ein handhabbares Backend sind offiziell beschrieben. Die konkrete Übergabefähigkeit bleibt zu demonstrieren.
Prüfen Sie responsive Umsetzung als technische Eingabe aus DE-145. Bop Design nennt responsive Webentwicklung. Der Pilot verlangt zusätzlich Komponentenbezug, definierte Zustände, Buildversion und Testbeleg. Eine Designfreigabe bestätigt keine implementierte Browserausgabe.
Legen Sie neutrale Browser- und Geräteklassen ohne echten Websiteinhalt an. Cross-Browser-Tests sind auf der Quelle sichtbar. Der Anbieter soll Umfang, Version, Umgebung, Ergebnis und offenen Fehler dokumentieren. DE-146 behauptet keine vollständige Abdeckung oder Konformität.
Exportieren Sie Repository oder Codekopie, WordPress-Modell, Abhängigkeiten, Tests, Zugriffe und offene Fehler. Rang drei folgt aus dem klaren WordPress-Fokus. Build, Deployment, Repository-Besitz und Recovery wurden nicht praktisch geprüft und bleiben Vertragsfragen.
Quellen zu den Anbietern: Bop Design, offizielle Webentwicklungsseite, abgerufen am 30.08.2026
theStacc Service des Herausgebers, Rang vier
Belegte Stärken
- Website-Erstellung wird auf der Managed-Services-Seite genannt.
- Hosting gehört zum beschriebenen Umfang.
- Website-Verwaltung wird sichtbar angeboten.
- Der Service kann als enger Gegenversuch geprüft werden.
Zu prüfende Grenzen
- Dienstleister und Herausgeber sind dasselbe Unternehmen.
- Ein technischer Entwicklungsprozess wird nicht dokumentiert.
- Repository, QA, Deployment und Recovery bleiben offen.
- Custom Development, Konformität und Dental-Eignung sind unbelegt.
theStacc steht wegen Herausgeberkonflikt und indirekter Angebotsnähe auf Rang vier. Die Managed-Services-Seite beschreibt Website-Erstellung, Hosting und Verwaltung. Sie dokumentiert dort keinen technischen Discovery-, Architektur-, Repository-, Integrations-, QA-, Deployment-, Credential-, Recovery- oder Exportprozess. Custom Development, Dental-Eignung, sichere Umsetzung, Konformität, konkrete Übergabe und Resultate werden nicht belegt.
Übergeben Sie theStacc nur das abstrakte Anforderungsregister und eine freigegebene Designversion. Der Anbieter soll zeigen, welcher technische Liefergegenstand hinter Website-Erstellung steht. Die Quelle belegt Erstellung, Hosting und Verwaltung, aber keinen detaillierten Entwicklungsprozess.
Fordern Sie Repository, Architekturentscheidung, CMS-Modell, Integrationsvertrag, Umgebungen und Buildanweisung. Fehlt ein Objekt im tatsächlichen Angebot, bleibt die Lücke sichtbar. DE-146 ergänzt keine Custom-Development-Leistung aus dem Wort Website oder aus allgemeinem Wissen.
Trennen Sie Hosting und Verwaltung von Codebesitz, Deployment und Recovery. Ein laufender Dienst kann mehrere Bereiche verbinden, braucht aber übertragbare Zugänge, Artefakte und Arbeitsenden. Die verwendete Quelle belegt keine konkrete technische Eigentums- oder Übergaberegel.
Exportieren Sie jeden vorhandenen technischen Gegenstand und offene Lücken. Entziehen Sie eine begrenzte Testrolle. Wegen des Interessenkonflikts braucht jede Einordnung unabhängige Fach- und Sprachprüfung. DE-146 hat keinen theStacc-Service, Code, Build, Zugang oder Export praktisch getestet.
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.
Vier Anbieter am neutralen technischen Build-Pilot
Die Tabelle ordnet nur sichtbar dokumentierte Servicebereiche einem abstrakten technischen Bedarf zu. Sie bestätigt keine Preise, Dental-Eignung, sichere Umsetzung, Konformität, Vertragsqualität, Hostingqualität oder Ergebnisse.
| Anbieter | Leistungsmodell | Belegter Leistungsumfang | Geeignet für | Wesentliche Einschränkung |
|---|---|---|---|---|
| Netguru | Breiter End-to-End-Service | Discovery, Architektur, Frontend, Backend, CMS, QA, Publishing, Maintenance | vollständiger Build-Pilot | Besitz zu zeigen |
| Lounge Lizard | Custom-Webentwicklung | Frameworks, Architektur, WordPress, Entwicklung, Testing, Launch | Architektur und CMS | Deployment offen |
| Bop Design | WordPress-Entwicklung | Custom CMS, Backend, responsive Umsetzung, Browsertests | enger WordPress-Pilot | Repository offen |
| theStacc | Indirekter Herausgeber-Service | Website erstellen, hosten und verwalten | unabhängiger Gegenversuch | Entwicklungsprozess fehlt |
Einen Build-Pilot ohne reale Praxis, Website oder Zugangsdaten durchführen
Das Prüfpaket enthält abstrakte Anforderungen, eine neutrale Designversion, leere CMS-Felder, eine synthetische API-Antwort, Konfigurationsnamen ohne Werte, eine Testkennung und einen künstlichen Deploymentfehler. Es enthält keine Praxis, keinen Zahnarzt, Patienten, Fall, Website, Zugangsdaten, Preis, Testimonial oder geschäftliches Ergebnis.
Geprüft werden Discovery, Architektur, Codebezug, CMS, Integration, Umgebungen, Build, QA, Deployment, Credentials, Repository, Recovery und Export. Jeder Schritt besitzt einen erwarteten Zustand. Kein Anbieter wird als praktisch getestet oder als für Zahnärzte geeignet dargestellt.
1. Technische Anforderungen und Architekturentscheidungen versionieren
Legen Sie abstrakte Anforderungen mit Designreferenz, Datenobjekt, technischem Ziel, Annahme, Ausschluss und Abnahmekriterium an. Es gibt keine echten Praxiswerte. Eine offene Entscheidung bleibt offen und darf weder vom Entwickler noch von einem generischen Template unbemerkt geschlossen werden.
Erstellen Sie Architekturentscheidungen für Rendering, CMS, Integration, Build und Deployment. Jede Entscheidung nennt Optionen, gewählte Richtung, Folgen, offene Frage und Rücknahmepunkt. Ein Technologie-Logo ohne Begründung besteht den Pilot nicht.
Ändern Sie die referenzierte Designversion aus DE-145. Die betroffene Implementierung öffnet sich erneut, unveränderte Architektur kann bestehen bleiben. Der Verlauf muss zeigen, welche Designänderung welche technische Aufgabe ausgelöst hat.
- Anforderungen abstrakt.
- Designversion referenziert.
- Annahmen sichtbar.
- Optionen dokumentiert.
- Rücknahmepunkt vorhanden.
- Änderung adressiert.
2. Repository, Build und Umgebungen reproduzierbar machen
Inventarisieren Sie Repository-Eigentum, Agenturrolle, Branches, Reviewregel, Laufzeit, Abhängigkeiten, Buildbefehl und Artefaktziel. Verwenden Sie keine Zugangsdaten. GitHubs Transferdokumentation dient nur als Hinweis, dass Übertragbarkeit ein eigener Vorgang ist.
Definieren Sie lokale Entwicklung, Vorschau, Test und Produktion als getrennte Zwecke. Konfigurationsnamen bleiben leer. Der Anbieter soll erklären, wie fehlende Werte erkannt, wie Umgebungen aufgebaut und wie manuelle Schritte in der Übergabe sichtbar werden.
Führen Sie im Pilot nur eine neutrale Codeänderung durch. Verfolgen Sie Commit-Bezug, Reviewstatus, Build-Artefakt und Zielumgebung. Ein erfolgreicher Build bestätigt noch keine Live-Ausgabe. Diese erhält eine eigene Kontrolle.
- Repository institutionell.
- Rollen begrenzt.
- Build dokumentiert.
- Umgebungen getrennt.
- Keine Geheimnisse.
- Artefakt referenziert.
3. CMS und Integrationen ohne reale Daten prüfen
Erstellen Sie ein neutrales CMS-Modell mit Feldtypen, Pflichtstatus, leeren Zuständen, Vorschau und Exportfrage. Es enthält keine Praxisinformation. Der Anbieter zeigt, wie Modelländerung, Inhaltsmigration und Rollenübergabe dokumentiert werden.
Definieren Sie eine synthetische Integration mit Ein- und Ausgabeform, Fehlerzustand, Timeout und Testdouble. Es gibt keinen echten Drittanbieter und keinen Schlüssel. Frontend, Backend und Integrationsvertrag erhalten getrennte Abnahmen.
Ändern Sie die synthetische Antwortform. Der Build soll den betroffenen Test und die abhängige Komponente sichtbar öffnen. Eine Integration gilt nicht als bestätigt, nur weil ein Idealzustand im Browser erscheint.
- CMS-Modell neutral.
- Felder leer.
- Export gefragt.
- Integration synthetisch.
- Fehlerzustand vorhanden.
- Abhängigkeit sichtbar.
4. QA an Version, Umgebung und Ergebnis binden
Planen Sie Unit-, Komponenten-, Integrations-, End-to-End- und manuelle Prüfklassen nur dort, wo sie einen benannten Gegenstand besitzen. Jeder Test verweist auf Version, Umgebung, Eingabe, erwarteten Zustand, Ergebnis und offenen Fehler.
Nutzen Sie W3C-Entwicklungstipps als technische Fragen zu semantischer Struktur, Tastaturbedienung, Formularen und DOM-Reihenfolge. DE-146 behauptet keine Konformität. Designprüfung aus DE-145, technische Umsetzung und spätere menschliche Prüfung bleiben getrennt.
Erzeugen Sie einen synthetischen Fehler in einer Testumgebung. Der Anbieter soll zeigen, wie er triagiert, referenziert, korrigiert und erneut prüft. Ein pauschaler QA bestanden-Status ohne Testbestand und offene Ausnahmen reicht nicht.
- Testklassen begründet.
- Version genannt.
- Umgebung genannt.
- W3C nur Fragen.
- Fehler erhalten.
- Erneute Prüfung sichtbar.
5. Deployment, Credentials und Recovery abgrenzen
Definieren Sie Deployment mit Quellversion, Artefakt, Ziel, Freigabe, Zeitpunkt, Ergebnis und bekannter vorheriger Fassung. Simulieren Sie einen Fehler, ohne eine reale Website zu verändern. Der Rücknahmeweg bleibt als dokumentierter Zustand sichtbar.
Inventarisieren Sie Zugangsklassen für Repository, CMS, Build und Deployment. Kein Geheimnis wird erzeugt, gelesen oder exportiert. Institutionelle Kontrolle, begrenzte Agenturrolle, Ablageklasse, Rotationseigentum und Entzug werden nur als Felder geprüft.
Beschreiben Sie einen neutralen Recovery-Fall aus Codekopie, Buildanweisung, Umgebungsinventar und bekannter Version. DE-146 behauptet kein Backup, Hostingniveau oder Sicherheitsversprechen. Der Anbieter erklärt lediglich seinen verantworteten Wiederanlaufabschnitt.
- Deployment versioniert.
- Vorherige Fassung bekannt.
- Credentials nur inventarisiert.
- Hauptkontrolle institutionell.
- Recovery neutral.
- Keine Garantie.
6. Den technischen Bestand außerhalb der Agentur übernehmen
Exportieren Sie Repository oder Codekopie, Buildanweisung, Abhängigkeiten, Architekturentscheidungen, CMS-Modell, Integrationsverträge, Umgebungsinventar, Testbelege, Deploymenthistorie, Zugangsinventar und offene Fehler. Öffnen Sie alles außerhalb des Agenturportals.
Entziehen Sie eine begrenzte Testrolle und bauen Sie die neutrale Änderung im beschriebenen Übergabeweg. Wenn ein nicht dokumentierter Schritt oder Wert fehlt, bleibt er als Abnahmelücke sichtbar. DE-146 führt keinen vollständigen Projektbuild aus.
Übergeben Sie Designfragen zurück an DE-145 und Marketinganforderungen an DE-141 bis DE-144. Der neue technische Arbeitsweg muss den Live-Bezug, offenen Fehler, bekannte Version und Recovery-Grenze verstehen, ohne diese fremden Verantwortungen selbst zu übernehmen.
- Code exportiert.
- Build beschrieben.
- Modelle enthalten.
- Tests lesbar.
- Rolle entzogen.
- Grenzen übergeben.
Fehler, die einen SEO-Vergleich wertlos machen
- Eine Live-Seite als technischen Export behandeln. Sichtbare Ausgabe ersetzt weder Repository, Build, Abhängigkeiten, Umgebungen noch offene Fehler.
- Technologie ohne Architekturentscheidung wählen. Optionen, Folgen, Abhängigkeiten und Rücknahmepunkte müssen vor der Implementierung lesbar sein.
- Designfragen still im Code lösen. Offene Artefakte aus DE-145 bleiben offen und werden nicht als technische Notwendigkeit ausgegeben.
- Zugangsdaten im Repository speichern. Der Pilot prüft nur Zugangsklassen, Eigentum, Ablage, Rotation und Entzug, niemals Geheimnisse.
- Ein Idealbild als Integrationstest verwenden. Vertrag, Fehlerzustand, Testdouble, abhängige Komponente und offene Ausnahme brauchen eigene Belege.
- QA bestanden ohne Testbestand melden. Testart, Version, Umgebung, Ergebnis und offene Fehler müssen adressierbar bleiben.
- W3C-Tipps als Konformitätsbeleg verwenden. Die Quelle begründet technische Prüffragen, bestätigt aber keinen Anbieter und keine Implementierung.
- Hosting mit Codebesitz gleichsetzen. Betrieb, Repository, Build, Deployment, Recovery und Export sind getrennte technische Gegenstände.
- Nur eine technische Dokumentation als PDF übergeben. Ausführbarer Code, Abhängigkeiten, Modelle, Tests, Historie und Zugriffe gehören zum Exit-Paket.
Häufige Fragen
Welche Webentwicklungsagentur eignet sich zuerst für den neutralen Pilot?
Netguru beginnt DE-146 wegen des breit beschriebenen Umfangs aus Discovery, Architektur, Frontend, Backend, CMS, QA, Publishing und Wartung. Lounge Lizard folgt mit Frameworks, Architektur, WordPress und Testing. Bop Design steht für einen engeren WordPress-Pilot. theStacc bleibt wegen Herausgeberkonflikt und fehlendem Entwicklungsprozess zuletzt. Keine Position belegt Dental-Eignung.
Was gehört in ein Webentwicklungsangebot für eine Zahnarztpraxis?
Das Angebot nennt technische Discovery, Architekturentscheidungen, Repository, Branches, Reviews, Implementierung, CMS, Integrationen, Umgebungen, Build, QA, Deployment, Zugangsklassen, Recovery, Wartungsgrenze, Export und Exit. Für jeden Bereich steht der letzte bezahlte Zustand fest. Allgemeine Website-Erstellung reicht nicht, wenn Codebesitz, Reproduzierbarkeit und offene Fehler unklar bleiben.
Welche Praxisdaten gehören in den Build-Pilot?
Keine realen Praxisdaten sind nötig. Verwenden Sie abstrakte Anforderungen, eine neutrale Designversion, leere CMS-Felder, synthetische Integrationsantworten, Konfigurationsnamen ohne Werte und Testkennungen. Der Anbieter demonstriert Architektur, Codeweg, QA und Übergabe, ohne eine Praxis, einen Zahnarzt, Patienten, Website, Zugangsdaten oder Ergebnis zu erfinden.
Was muss eine Architekturentscheidung enthalten?
Sie beschreibt Problem, betrachtete Optionen, gewählte Richtung, Folgen, offene Risiken, Abhängigkeiten und Rücknahmepunkt. Framework oder CMS allein sind keine Begründung. Die Entscheidung verweist auf Anforderung und Designversion. Ändert sich eine Eingabe, muss erkennbar sein, ob Architektur und Implementierung erneut geprüft werden.
Wem sollte das Code-Repository gehören?
Institutionelle Kontrolle sollte beim Auftraggeber bleiben, während die Agentur begrenzte Rollen für benannte Aufgaben erhält. GitHub dokumentiert Repository-Transfer als eigenen Vorgang, bestätigt aber keinen Anbieterprozess. Der Pilot prüft Besitz, Branches, Reviews, Build und Entzug, ohne Zugangsdaten oder ein echtes Repository anzulegen.
Wie werden Entwicklungsumgebungen getrennt?
Lokale Entwicklung, Vorschau, Test und Produktion erhalten dokumentierte Zwecke, Konfigurationsnamen, Buildwege und Freigabegrenzen. Der Pilot verwendet keine realen Werte oder Geheimnisse. Ein Anbieter soll zeigen, wie ein Artefakt zwischen Zuständen wandert und wie fehlende Konfiguration oder manuelle Schritte im Handoff sichtbar bleiben.
Was gehört in ein CMS-Handoff?
Übergeben werden Inhaltsmodell, Feldtypen, Pflicht- und Leerzustände, Rollen, Vorschauweg, Migrationen, Versionsbezug, Export und bekannte Einschränkungen. Der Pilot enthält keine Praxisinhalte. Ein CMS-Login allein reicht nicht, wenn Modell, Codebezug, Inhalte und institutionelle Kontrolle ohne das Agenturportal nicht verständlich oder übertragbar sind.
Wie lässt sich eine Integration ohne echten Drittanbieter prüfen?
Nutzen Sie einen synthetischen Vertrag mit Eingabeform, Ausgabeform, Fehlerzustand, Timeout und Testdouble. Es gibt keinen realen Endpunkt und keinen Schlüssel. Der Anbieter zeigt, wie Frontend, Backend, Vertrag, Test und offene Ausnahme verbunden bleiben. Eine sichtbare Idealantwort bestätigt noch keine belastbare Integration.
Wie wird Webzugänglichkeit in der Entwicklung behandelt?
Die W3C-Entwicklungstipps dienen als Fragenkatalog für semantische Struktur, Tastaturnutzung, Formulare und DOM-Reihenfolge. Sie sind kein Zertifikat. DE-146 prüft Prozess und Testbezug, behauptet aber weder Konformität noch vollständige Umsetzung. Design, Code und spätere menschliche Bestätigung bleiben getrennte Zustände. Prüfgrenzen bleiben ausdrücklich offen.
Was muss ein QA-Bericht zeigen?
Der Bericht nennt Testart, Anforderung, Codeversion, Umgebung, Eingabe, erwarteten Zustand, tatsächliches Ergebnis und offenen Fehler. Unit-, Komponenten-, Integrations-, End-to-End- und manuelle Prüfungen werden nur dort verwendet, wo sie einen Gegenstand besitzen. Ein pauschaler bestanden-Status ohne Testbestand ist nicht abnahmefähig. Jeder Fehler bleibt adressierbar.
Was gehört in einen Deployment-Beleg?
Der Beleg verbindet Quellversion, Build-Artefakt, Zielumgebung, Freigabe, Zeitpunkt, Ergebnis, Live-Kontrolle, bekannte vorherige Fassung und Rücknahmeweg. Ein erfolgreicher Upload oder geschlossener Status genügt nicht. Der Pilot verändert keine reale Website, prüft aber, ob Fehler und Wiederholung adressierbar bleiben. Jede Bereitstellung bleibt rückverfolgbar.
Wie werden Zugangsdaten und Recovery geprüft?
DE-146 inventarisiert nur Zugangsklassen, institutionelle Kontrolle, Agenturrolle, Ablageklasse, Rotationseigentum, Entzug und Wiederanlaufgrenze. Es erzeugt, liest oder exportiert kein Geheimnis. Recovery wird mit Codekopie, Buildanweisung, Umgebungsinventar und bekannter Version beschrieben, ohne Backup-, Hosting- oder Sicherheitsgarantie zu behaupten. Kein Geheimnis wird dabei offengelegt.
Was gehört in den technischen Export?
Exportiert werden Repository oder Codekopie, Buildanweisung, Abhängigkeiten, Architekturentscheidungen, CMS-Modell, Integrationsverträge, Umgebungsinventar, Testbelege, Deploymenthistorie, Zugangsinventar, bekannte Versionen und offene Fehler. Das Paket wird außerhalb des Agenturportals geöffnet. PDF-Dokumentation ergänzt den Bestand, ersetzt aber keinen ausführbaren und übernehmbaren Codeweg. Alle Beziehungen bleiben technisch adressierbar.
Was trennt DE-146 von Webdesign und Marketing?
DE-146 besitzt technische Architektur, Code, CMS, Integrationen, Umgebungen, QA, Deployment und Recovery. DE-145 besitzt Informationsarchitektur, UI, Content-Handoff und Designexport. DE-141 bis DE-144 besitzen Marketingarbeit und Portfoliosteuerung. Diese Bereiche können Eingaben liefern, behalten aber eigene Versionen, Abnahmen, Konten und Übergaben. Ihre Abnahmen bleiben getrennt.
Warum steht theStacc auf Rang vier?
theStacc bietet den verglichenen Managed-Service an und veröffentlicht zugleich DE-146. Die eigene Seite beschreibt Website-Erstellung, Hosting und Verwaltung, dokumentiert aber keinen Discovery-, Architektur-, Repository-, Integrations-, QA-, Deployment-, Credential-, Recovery- oder Exportprozess. Rang vier macht Konflikt und indirekte Passung sichtbar. Custom Development wird nicht aus dem Wort Website abgeleitet.
Warum bleibt DE-146 in menschlicher Prüfung?
Die Seite stützt sich auf offizielle Anbieter-, W3C- und GitHub-Quellen sowie einen abstrakten Pilot. Kein Anbieter, Vertrag, Zahnarzt, keine Praxis, Website, Architektur, Codebasis, Integration, Prüfung, Bereitstellung, Zugangsdaten, Recovery oder Übergabe wurde praktisch getestet. Fachkundige Prüfung, deutsche Sprachprüfung und benannter Wartungsverantwortlicher fehlen. Deshalb bleibt der Status needs_human_review.
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.
Fordern Sie den reproduzierbaren Codeweg, nicht nur die Live-URL
Ein belastbarer Auswahlpilot verfolgt Anforderung, Architektur, Code, CMS, Integration, Build, QA und Deployment durch benannte Versionen und Umgebungen. Danach werden Repository, Zugriffe, Recovery-Grenzen und offene Fehler außerhalb des Agenturportals geöffnet. DE-146 braucht vor jeder Veröffentlichung weiterhin fachkundige Prüfung, deutsche Sprachprüfung und einen benannten Wartungsverantwortlichen.