Staging-Site Best Practices: So richten Freelancer Review-Umgebungen für Kunden ein

Eine Staging-Site fürs Kunden-Review sollte eine private, passwortgeschützte Kopie der Kunden-Website unter einer separaten URL sein. Niemals eine versteckte Seite auf der Live-Site, niemals von Google indexiert und niemals als nackter Link ohne Kontext geteilt. Die Aufgabe von Staging ist einfach: dem Kunden einen sicheren Ort geben, an dem er die Arbeit ansehen, herumklicken und Feedback hinterlassen kann, mit dem du wirklich etwas anfangen kannst. Den ersten Teil kriegen die meisten Freelancer hin, den Feedback-Teil aber komplett falsch, und genau da beginnt jeder schmerzhafte Revisionszyklus.

Dieser Leitfaden zeigt dir, wie du Staging richtig aufsetzt, wie du es teilst, ohne deinen Kunden zu verwirren, und wie du Feedback so einsammelst, dass du nicht am Sonntagabend durch 47 WhatsApp-Nachrichten scrollst.

Das Problem damit, wie die meisten Freelancer mit Staging umgehen

Stell dir das vor. Du schließt am Donnerstagabend ein Homepage-Redesign ab. Du pushst es auf eine Subdomain wie staging.clientsite.com, schickst eine einzeilige Mail ("hier ist der Link, sag mir, was du denkst") und gehst mit einem produktiven Gefühl ins Bett.

Freitagmorgen trudeln die Nachrichten ein. Der Kunde hat dir einen Screenshot mit einem roten Pfeil geschickt, der auf "das Ding mit dem Bild" zeigt. Seine Kollegin hat auf deine Mail mit einer nummerierten Liste geantwortet, aber die Nummerierung stimmt nicht, weil sie sich die Über-uns-Seite statt der Homepage ansieht. Der Chef des Kunden hat die Staging-URL bei Google gesehen, weil du vergessen hast, sie auf noindex zu setzen, und fragt jetzt, warum die neue Site "vor der Freigabe live ist". Jemand hat einen Kommentar zur Fußzeile in einem Google Doc hinterlassen, den du erst am Montag gesehen hast.

Am Ende des Wochenendes hast du Feedback von vier Personen, in vier Formaten, zu drei verschiedenen Seiten, von dem sich die eine Hälfte mit der anderen widerspricht. Du hast keine einzige Zeile Code geschrieben. Die "zweitägige Revisionsrunde" hat dich schon einen Tag gekostet, bevor sie überhaupt begonnen hat.

Die Staging-Site selbst war nicht das Problem. Das Problem war, Staging wie eine fertige Website zu behandeln statt wie einen kontrollierten Review-Prozess. Ein sauberes Staging-Setup ist halb technisch (separate Umgebung, Passwort, keine Indexierung) und halb Kommunikation (ein Feedback-Kanal, klare Anweisungen, Versionsbewusstsein). Lass eine der beiden Hälften weg und du landest dort, wo die meisten Freelancer landen: begraben unter unstrukturierten Kommentaren, Entscheidungen verteidigend, die du längst getroffen hast, und Dinge neu baust, die nie kaputt waren.

Staging vs. Preview vs. Live: was die Begriffe eigentlich bedeuten

Bevor wir zu den Best Practices kommen: Drei Begriffe werden ständig verwechselt. Bring sie auseinander und deine Kundengespräche werden über Nacht einfacher.

Umgebung  ·  Zweck  ·  Wer sieht sie  ·  Von Google indexiert

Lokal / Dev  ·  Du baust und testest auf deinem eigenen Rechner  ·  Nur du  ·  Nein

Staging  ·  Kunde reviewt die Arbeit vor dem Launch  ·  Du + Kunde (passwortgeschützt)  ·  Niemals

Preview  ·  Schnelles Teilen einer einzelnen Seite oder Änderung (oft über Webflow, Figma, Framer)  ·  Du + eingeladene Reviewer  ·  Nein

Production / Live  ·  Die echte öffentliche Website  ·  Alle, auch Suchmaschinen  ·  Ja

Staging ist kein Preview-Link. Ein Preview-Link von Webflow oder Framer ist gut, um eine einzelne Änderung zu zeigen ("sieht dieser Hero so besser aus?"), aber für ein vollständiges Review, bei dem dein Kunde sich durch Seiten klickt, Formulare ausfüllt und entscheidet, ob er launcht, willst du eine echte Staging-Umgebung, die Production spiegelt.

Die 10 Staging-Site Best Practices für Freelancer

Hier ist die Checkliste, die ich bei jedem Projekt durchgehe, bevor ich eine Staging-URL mit einem Kunden teile.

1. Nutze eine separate Umgebung, keine versteckte Live-Seite. Baue auf einer Staging-Subdomain (staging.clientsite.com), einer temporären Domain, die dir gehört (clientname.yourstudio.com), oder einer gehosteten Preview deines CMS (Webflows webflow.io-URL, Framers framer.website-URL, WordPress-Staging über WP Engine oder Kinsta). Klatsche niemals ein halbfertiges Design auf die echte Live-Site unter /new oder /v2.
2. Schütze alles mit einem Passwort. Das Minimum ist HTTP Basic Auth, aber ein richtiger Login (Webflow Site Password, Cloudflare Access, .htpasswd, Plugin-basiert bei WordPress) ist besser. Das Passwort sollte sich von allem unterscheiden, was der Kunde sonst nutzt, und in derselben Mail wie der Staging-Link stehen.
3. Sperre Suchmaschinen komplett aus. Füge ein seitenweites <meta name="robots" content="noindex, nofollow"> hinzu sowie ein Disallow: / in der robots.txt. Die meisten CMS haben einen "Suchmaschinen abhalten"-Schalter, schalte ihn ein. Wenn Staging vor dem Launch indexiert wird, erzeugst du später Duplicate-Content-Probleme mit der Live-Site.
4. Spiegle Production-Daten, kein Lorem Ipsum. Nutze wo immer möglich die echten Texte, echten Bilder und echten Produktdaten des Kunden. Eine Site voller Platzhaltertext zu reviewen führt zu Feedback wie "der Text ist komisch", nutzlos. Echte Inhalte bringen echte Probleme ans Licht (lange Produktnamen, die ein Card-Layout sprengen, eine CEO-Bio, die dreimal länger ist als das Design angenommen hat).
5. Bilde die Production-Umgebung so genau wie möglich ab. Gleiche Hosting-Stufe, gleiches CDN-Setup, gleiche Redirects, gleiche Formular-Handler. Wenn Staging auf Netlify Free läuft und Production auf einem Pantheon-Plan für 200 Dollar im Monat, sagen dir deine Staging-Tests nicht viel darüber, wie die echte Site performen wird.
6. Nutze einen Feedback-Kanal, nicht fünf. Entscheide, bevor du den Link teilst: Feedback kommt über dotts-Kommentare, oder über ein geteiltes Dokument, oder per Mail. Wähle eins. Wenn dein Kunde versucht, dir einen Screenshot zu schicken, lenke ihn um. "Hey, kannst du das als Kommentar in dotts hinzufügen? So geht nichts verloren."
7. Versioniere den Staging-Build vor jeder Review-Runde. Tagge Releases (review-1, review-2), damit du, wenn ein Kunde sagt "Ich habe die Version von Dienstag kommentiert", genau weißt, was er sich angesehen hat. Tools wie Webflow haben eine Backup-Historie, mit Code nutzt du Git-Tags.
8. Schick eine Review-Mail, keinen Link in einer Nachricht. Eine nackte URL in einem Chat lädt zum Chaos ein. Eine kurze, strukturierte Mail (was anzuschauen ist, wie viel Zeit bleibt, wo Feedback hingehört) setzt Erwartungen und gibt dir etwas, auf das du dich später beziehen kannst.
9. Setze eine Feedback-Deadline. "Schau es dir an, wenn du Zeit hast" garantiert dir, dass du dem Feedback zwei Wochen hinterherläufst. "Bitte hinterlasse alles Feedback bis Freitag 17 Uhr" bringt dir alles in drei Tagen. Setze das Datum immer in die Review-Mail.
10. Schließe den Kreis zwischen den Runden. Wenn du den nächsten Staging-Build pushst, markiere jeden vorherigen Kommentar als gelöst oder erledigt und sag dem Kunden, welche Seite sich geändert hat. Sonst wird aus Runde zwei wieder Runde eins, mit denselben Kommentaren, die erneut auftauchen, weil der Kunde nicht weiß, was schon erledigt ist.

So wählst du eine Staging-URL, die den Kunden nicht verwirrt

Die Staging-URL selbst sendet deinem Kunden ein Signal darüber, wie offiziell die Arbeit ist. Es gibt drei Optionen, die für Freelancer gut funktionieren, grob nach Professionalität sortiert.

Option A: Subdomain auf der Domain des Kunden. staging.clientsite.com oder new.clientsite.com. Sieht am professionellsten aus, erfordert DNS-Zugriff (den du zu diesem Zeitpunkt im Projekt ohnehin haben solltest) und fühlt sich für den Kunden echt an. Füge ein Basic-Auth-Passwort hinzu und du bist fertig.

Option B: Subdomain auf deiner eigenen Studio-Domain. clientname.yourstudio.com. Nützlich früh im Projekt, wenn du noch keinen DNS-Zugriff hast, oder für Kunden, die noch gar keine Domain haben. Stell sicher, dass deine Studio-Domain etwas Professionelles ist, nicht dein persönliches Twitter-Handle.

Option C: CMS-gehostete Preview-URL. clientname.webflow.io, clientname.framer.website, clientname.myshopify.com/?preview_theme_id=.... Schnellstes Setup, kein DNS nötig, perfekt für frühe Review-Runden. Manche Kunden sehen den Plattformnamen in der URL und werden nervös ("warum steht da webflow?"), erkläre vorab, dass dies eine temporäre Review-URL ist.

Was du niemals tun solltest: eine halbfertige Seite auf die Live-Site unter /new-homepage oder /v2 zu klatschen, auch nicht temporär, auch nicht passwortgeschützt. Es verschmutzt die Analytics, riskiert Indexierung, verwirrt jeden, der darüber stolpert, und schafft echte rechtliche Risiken, wenn der Kunde eine Datenschutzerklärung hat, die besagt, dass alles auf der Site aktuell ist.

Die Feedback-Ebene: wo Staging wirklich scheitert

Du kannst alle zehn der obigen Praktiken umsetzen, die sauberste Staging-Umgebung deiner Karriere aufsetzen und trotzdem im Revisionschaos versinken. Warum? Weil die Staging-Site selbst nur der Veranstaltungsort ist. Die Feedback-Methode ist das eigentliche Produkt einer Review-Runde.

Der Standard bei den meisten Freelancern ("klick herum und mail mir deine Gedanken") ist die schlechteste Feedback-Methode, die je erfunden wurde. Sie legt die Last der Struktur auf einen Kunden, der nicht weiß, was Struktur bedeutet. Er antwortet in Absätzen. Er vergisst, auf welcher Seite er war. Er bringt Homepage und Über-uns-Seite durcheinander. Er schickt drei Folge-Mails über zwei Tage, jede mit einem einzelnen Kommentar. Bis du alles beisammen hast, hast du die Arbeit, das Feedback zusammenzustellen, selbst erledigt, und wahrscheinlich einen Teil davon übersehen.

Die Lösung ist, die Feedback-Ebene direkt über die Staging-Site zu legen. Tools wie dotts, MarkUp.io, BugHerd und Ruttl machen alle Varianten davon. Der Kunde klickt irgendwo auf die Seite (einen Button, einen Absatz, ein Hero-Bild) und hinterlässt einen angepinnten Kommentar, der genau dort bleibt, wo er ihn gesetzt hat. Du siehst den Kommentar im Kontext. Der Kunde sieht seinen Kommentar im Kontext. Niemand muss schreiben "das zweite Bild von oben, das mit der Frau, die den Laptop hält, das Ding rechts". Er klickt einfach darauf.

Speziell für Freelancer ist dotts für genau diese Situation gemacht: Solo-Designer, beschäftigter Kunde, keine Zeit für ein Tool-Tutorial. Der Kunde braucht keinen Account. Du schickst ihm den Staging-Link mit dem dotts-Overlay, er klickt und kommentiert, du bekommst bis Freitagnachmittag einen sauberen Feed strukturierten Feedbacks. Keine WhatsApp-Screenshots. Keine 12-Nachrichten-Mail-Threads. Kein "warte, welche Version hast du dir angesehen?"

Wenn du tiefer in diese Seite des Workflows eintauchen willst, schau dir unseren Leitfaden zu Website-Feedback-Tools für Freelancer an. Er geht durch, wie die Feedback-Ebene den Staging-Review-Prozess von Anfang bis Ende verändert.

So schreibst du die Staging-Review-Mail

Hier ist die Vorlage, die ich nutze. Passe die Sprache an deinen üblichen Ton mit dem Kunden an.

Hallo [Name],

>

Die neue Homepage und die Über-uns-Seite sind auf Staging bereit für dein Review:

>

URL: https://staging.clientsite.com

Passwort: seeyou-soon-2026

>

Bitte hinterlasse alles Feedback direkt auf der Seite über das dotts-Overlay (klick einfach überall dort, wo du kommentieren möchtest). Ich sehe deine Kommentare, sobald sie eintreffen.

>

Ein paar Dinge, auf die du besonders achten solltest:

- Ist die Überschrift klar darin, was du machst?

- Fühlt sich die Reihenfolge der Abschnitte richtig an?

- Gibt es Fotos, die ausgetauscht werden sollten?

>

Bitte hinterlasse alles Feedback bis Freitag 17 Uhr. Sobald ich alles habe, fasse ich die Änderungen nächste Woche zu einer Revisionsrunde zusammen.

>

Kurzer Hinweis: Dies ist eine private Review-Version, nicht die Live-Site. Bitte teile die URL nicht mit jemandem außerhalb des Teams.

>

Sag Bescheid, wenn du Fragen hast.

Diese Mail erledigt fünf Dinge auf einmal: Sie gibt Link und Passwort an einem Ort, legt den erwarteten Feedback-Kanal fest, gibt dem Kunden drei Dinge zum Anschauen (damit er nicht von "review alles" überwältigt wird), setzt eine Deadline und erinnert ihn daran, dass das nicht öffentlich ist. Fünf Minuten zum Schreiben, spart dir eine Woche Chaos.

Ein echtes Beispiel: die Staging-Site, die fast einen Launch ruiniert hätte

Maya ist eine freiberufliche Webflow-Designerin in Berlin. Letzten Winter hat sie ein Redesign für einen kleinen E-Commerce-Kunden abgeschlossen, eine Kerzenmarke mit etwa 400.000 Euro Jahresumsatz. Die Site lag auf staging.candlebrand.com, passwortgeschützt, alles gut.

Dann leitete die Marketing-Managerin des Kunden den Staging-Link an zwei Freunde weiter, "nur um ihre Meinung zu hören". Einer dieser Freunde führte eine Marketing-Agentur. Der Agentur-Freund schickte ein fünfseitiges Dokument mit 73 Kommentaren zurück, die meisten davon stilistische Vorlieben, eine Handvoll davon echte Probleme. Die Hälfte davon widersprach den Markenrichtlinien, die Maya zu Projektbeginn bekommen hatte. Der Kunde, in Panik, bat Maya, "das gesamte Feedback vor dem Launch zu berücksichtigen".

Maya tat drei Dinge, die das Projekt retteten. Erstens antwortete sie dem Kunden mit einer ruhigen Zusammenfassung: "Hier ist, was ein echtes Problem ist, hier ist, was eine stilistische Vorliebe ist, hier ist, was dem widerspricht, was wir im Briefing vereinbart haben. Wollen wir das durchsprechen?" Zweitens setzte sie einen 30-minütigen Call an, um ihre Zusammenfassung am Bildschirm durchzugehen. Drittens (und das ist die Sache, die ihre Arbeitsweise tatsächlich verändert hat) fügte sie für das nächste Projekt eine Klausel in ihren Vertrag ein: "Das Staging-Review ist auf zwei namentlich genannte Stakeholder beschränkt. Zusätzliche Reviewer erfordern eine abgegrenzte Feedback-Runde zu X Euro."

Der Launch fand eine Woche später als geplant statt. Der Kunde zahlte den vollen Betrag. Und Maya hatte seitdem kein "eingeschmuggeltes Agentur-Review" mehr, weil ihre Staging-Mails jetzt ausdrücklich sagen "dieser Link ist nur für [namentlich genannte Personen]".

Die Lektion: Staging ist ein Prozess, keine URL. Das technische Setup ist wichtig, aber die Regeln darüber, wer reviewt und wie zurückgemeldet wird, sind wichtiger.

Staging-Tools nach CMS

Eine kurze Referenz, welches Staging-Setup pro Plattform am besten funktioniert.

CMS / Stack  ·  Empfohlener Staging-Ansatz  ·  Passwortschutz  ·  Hinweise

Webflow  ·  Nutze die webflow.io-Preview-URL oder eine Staging-Subdomain  ·  Site Password (Webflow-Plan nötig)  ·  Einfach zu versionieren mit Webflow Backups

Framer  ·  Nutze die framer.website-Preview-URL  ·  Site Password (kostenpflichtige Pläne)  ·  Begrenzte Unterschiede beim Formular-Handling vs. Production

WordPress  ·  WP Engine / Kinsta / Flywheel Staging-Umgebung  ·  Eingebautes Passwort oder .htpasswd  ·  Push-to-Live macht Review-Runden sauberer

Shopify  ·  Nutze einen Development Store oder eine passwortgeschützte Theme-Preview  ·  Eingebaute Passwortseite  ·  Teste den Checkout im Dev-Store, nicht in Production

Static / Jamstack  ·  Netlify- oder Vercel-Preview-Deployments  ·  Branch-Deploys + Basic Auth  ·  Saubererster Workflow für Code-First-Freelancer

Custom Backend  ·  Separate Subdomain auf identischer Infrastruktur  ·  Cloudflare Access oder HTTP Basic Auth  ·  Spiegle Umgebungsvariablen sorgfältig

Wenn du als Freelancer plattformübergreifend arbeitest, liegt die eigentliche Feedback-Ebene (dotts, MarkUp usw.) über jeder dieser Umgebungen. Wähle die Staging-Umgebung, die zum Projekt passt, und nutze jedes Mal dasselbe Feedback-Tool, damit dein Kunde keinen neuen Prozess lernen muss.

Die Fehler, die ich am häufigsten sehe

Acht Jahre Websites bauen und die Workflows anderer Freelancer reviewen, hier sind die Fehler, die am häufigsten vorkommen. Wenn du sonst nichts machst, behebe diese.

• Kein noindex auf Staging. Zwei Monate später taucht eine doppelte Version der Homepage bei Google auf. Der Kunde mailt dir in Panik.
• Das Passwort im Chat teilen, getrennt vom Link. Der Kunde verliert eins, fragt nochmal, du schickst neu, er speichert das falsche. Schick Link und Passwort immer in derselben Mail.
• Vergessen, Kontaktformulare oder Analytics zu deaktivieren. Echte Conversion-Daten landen aus Staging-Klicks in den Analytics des Kunden. Schlimmer: Das Kontaktformular mailt dem Kunden tatsächlich jedes Mal, wenn du es testest.
• Die Staging-URL durchsickern lassen. Setze Basic Auth, auch wenn du zusätzlich ein CMS-Passwort hast. Doppelt hält besser.
• Staging als "v1, launchreif" behandeln. Staging ist fürs Review. Dass es online ist, heißt nicht, dass es fertig ist. Sei dem Kunden gegenüber klar, dass nichts final ist, bis du auf Production pushst.
• Die Feedback-Kanal-Regel überspringen. "Schick mir Feedback, wie es am einfachsten ist" ist kein Feedback-Kanal. Wähle einen und setze ihn sanft durch.
• Zwischen den Runden nicht versionieren. Wenn der Kunde sagt "Ich habe die Version von letztem Dienstag kommentiert", solltest du genau auf diesen Build zeigen können.

Fazit

Eine gute Staging-Site fürs Kunden-Review ist privat, passwortgeschützt, niemals indexiert und mit einem einzigen strukturierten Feedback-Kanal gekoppelt. Das technische Setup dauert 20 Minuten. Das Kommunikations-Setup (Review-Mail, Feedback-Kanal, Deadline, Scope) ist das, was eine ruhige Revisionsrunde von einem zweiwöchigen WhatsApp-Zusammenbruch trennt.

Richte Staging als den kontrollierten Review-Prozess ein, der es eigentlich ist, und der Rest deiner Kundenarbeit wird sehr viel ruhiger.

FAQ

Was ist eine Staging-Site fürs Kunden-Review?

Eine Staging-Site fürs Kunden-Review ist eine private, passwortgeschützte Kopie einer Website, die unter einer separaten URL von der Live-Site liegt. Sie existiert, damit Kunden Arbeit-in-Arbeit ansehen und kommentieren können, ohne die Live-Site, das Suchranking oder die Analytics zu beeinflussen. Freelancer nutzen Staging während der Bau- und Revisionsphasen eines Projekts und entfernen oder verwenden sie nach dem Launch anderweitig.

Wie schütze ich eine Staging-Site mit einem Passwort?

Die einfachsten Optionen sind HTTP Basic Auth (auf dem Server oder über Cloudflare Access gesetzt), ein CMS-Site-Passwort (Webflow, Framer, Shopify und die meisten WordPress-Hoster haben das eingebaut) oder ein Plugin (Restricted Site Access für WordPress ist zuverlässig). Schick das Passwort deinem Kunden immer in derselben Mail wie den Staging-Link und nutze ein Passwort, das nirgendwo sonst wiederverwendet wird.

Sollte ich Staging auf einer Subdomain oder einer separaten Domain hosten?

Eine Subdomain auf der Domain des Kunden (staging.clientsite.com) ist die professionellste Option, sobald DNS in deiner Kontrolle ist. Davor ist eine Subdomain auf deiner eigenen Studio-Domain (clientname.yourstudio.com) oder die CMS-gehostete Preview-URL in Ordnung. Vermeide es, den Staging-Build auf die Live-Site unter einem Pfad wie /new zu legen, das verschmutzt die Analytics und riskiert versehentliche Indexierung.

Wie verhindere ich, dass Google meine Staging-Site indexiert?

Füge ein seitenweites <meta name="robots" content="noindex, nofollow">-Tag hinzu und setze User-agent: * und Disallow: / in deine robots.txt. Die meisten CMS haben einen "Suchmaschinen abhalten"-Schalter (Webflow, WordPress, Framer haben ihn alle), schalte ihn ein. Kombiniere das mit HTTP Basic Auth, damit Suchmaschinen die Seite gar nicht erst erreichen können.

Was ist der beste Weg, Feedback auf einer Staging-Site einzusammeln?

Nutze ein visuelles Feedback-Tool, das über der Staging-Site liegt, damit der Kunde irgendwo auf der Seite klicken und einen angepinnten Kommentar hinterlassen kann. Tools wie dotts, MarkUp.io und BugHerd machen das. Der Vorteil ist strukturiertes Feedback im Kontext (kein "der dritte Abschnitt, das Ding mit dem Bild" mehr) und ein Ort, um jeden Kommentar zu verfolgen, statt Mail plus Chat plus Screenshots.

Wie lange sollten Kunden Zeit haben, eine Staging-Site zu reviewen?

Für das Review einer einzelnen Seite reichen meist 2 bis 3 Werktage. Für das Review einer ganzen Site gib 5 Werktage und setze eine harte Deadline in die Review-Mail. Offene Zeitpläne garantieren dir, dass du dem Feedback zwei Wochen hinterherläufst; eine klare Deadline bringt tendenziell alles innerhalb von drei Tagen herein.

Was soll ich tun, wenn der Kunde die Staging-URL mit anderen Leuten teilt?

Lege vorab fest, wie viele Stakeholder reviewen dürfen, und schreib es in deinen Vertrag oder Scope. Wenn zusätzliche Personen hinzukommen, behandle ihr Feedback als neue, abgegrenzte Runde (mit mehr Zeit und möglicherweise zusätzlichen Kosten). Sei höflich, aber bestimmt: Unkontrollierte Review-Gruppen sind die größte Einzelursache für Projektausuferungen bei Freelancern.

Brauche ich eine Staging-Site für kleine Projekte?

Ja, sogar für eine einzelne Landingpage. Die Kosten von Staging sind minimal (eine Subdomain, ein Passwort, 20 Minuten Setup), und die Alternative ist, auf der Live-Site zu bearbeiten oder Screenshots hin und her zu schicken. Staging plus ein strukturierter Feedback-Kanal zahlt sich schon in der ersten Revisionsrunde durch gesparte Zeit aus.

Genervt vom Staging-Review-Chaos? [dotts kostenlos testen →](https://dotts.se)

Weiterführende Artikel

• So teilst du eine Website mit einem Kunden für Feedback (richtig gemacht)
• Webdesign-Revisionsprozess: So managst du Kundenrevisionen, ohne die Kontrolle zu verlieren
• So bekommst du die Freigabe des Kunden für eine Website: Ein vollständiger Leitfaden für Freelancer
• So präsentierst du eine Website einem Kunden: Ein Schritt-für-Schritt-Leitfaden für Freelancer