Alles, was du wissen musst

Ja. Wir arbeiten seit 2020 ausschließlich mit Shopify und Shopify Plus, und dorthin sind wir gekommen, indem wir andere Plattformen abgesagt haben. Der Tausch ist bewusst: Ein Team, das jeden Tag dieselbe Plattform sieht, weiß, welches Problem eine native Lösung hat, welches eine App braucht und welches Custom Code - dadurch fließt weniger von deinem Budget in das Wiederfinden dieser Antwort. Und wir folgen Shopifys eigenen Konventionen, statt Muster aus Magento oder WooCommerce zu übertragen. Genau das hält einen Shop nach der Übergabe updatefähig.

Strategie & Beratung, Custom Shopify Theme-Entwicklung, Custom App-Entwicklung, Shop-Migrationen, UX/UI Design, Integrationen & Middleware, laufendes Store Management und AI E-Commerce Readiness. Die meisten Projekte kombinieren drei oder vier davon: An einer Migration hängen meist eine ERP-Integration und ein Redesign, und ein Redesign legt meist ein Performance-Problem frei. Alles läuft über ein Team, dadurch werden eine Design-Entscheidung und ihre Konsequenz in der Entwicklung gemeinsam geklärt statt zwischen zwei Agenturen verhandelt.

Absolut, und es ist einer der häufigsten Einstiege zu uns. Wir auditieren zuerst den bestehenden Shop - Conversion-Pfad, Seiten-Performance und die Templates, die den größten Umsatz tragen - und gestalten dann gegen das, was das Audit gefunden hat, statt gegen ein Moodboard. Produkte, Kunden, Bestellungen und URL-Struktur bleiben, wo sie sind, damit Rankings und Shopdaten nicht in Gefahr geraten. Ein Redesign kann auch gestaffelt live gehen: erst die Seiten, die verkaufen, der Rest danach. So siehst du die Wirkung, bevor das ganze Budget gebunden ist.

Ja, von Grund auf und nicht als umgefärbtes Marketplace-Template. Ein Custom Theme heißt: genau die Sections, die dein Merchandising-Team wirklich braucht, im Theme-Editor pflegbar ohne Entwickler, und kein geerbter Code für Funktionen, die du nie nutzen wirst. Der letzte Punkt ist das Performance-Argument: Themes von der Stange tragen die Summe aller Use Cases mit sich, für die sie verkauft wurden, und du bezahlst das bei jedem Seitenaufruf in den Core Web Vitals. Wir bauen gegen deinen Katalog und dein Content-Modell und übergeben Dokumentation, damit dein Team den Shop selbst betreiben kann.

Ja - WooCommerce, Magento, Shopware und andere Plattformen, in einem gestaffelten Prozess mit minimalem Risiko. Produkte, Varianten, Kunden und Bestellhistorie kommen mit, und jede indexierte URL bekommt einen gemappten 301, damit die Rankings, die du dir erarbeitet hast, den Umzug überleben. Über die Dauer entscheidet selten die Katalogröße: Es sind Datenstrukturen ohne direktes Shopify-Gegenstück (Bundles, konfigurierbare Produkte, kundenspezifische Preise) und die Systeme, mit denen dein Shop spricht. Beides inventarisieren wir, bevor ein Cutover-Datum steht. Deshalb enden unsere Migrationen nicht mit einer Redirect-Liste, die in der Nacht vor dem Launch entsteht.

Das hängt vom Umfang ab: Fokussierte Optimierungen dauern oft 4-6 Wochen, komplette Custom Builds oder Migrationen typischerweise 8-16 Wochen. Ein Shop auf konfigurierter Theme-Basis ist meist in 4-8 Wochen live, eine vollständig individuelle Storefront eher in 10-16. Vor dem Start bekommst du eine Timeline mit definierten Meilensteinen, und diese Meilensteine sind gestaffelte Releases statt eines einzigen Launch-Termins am Ende - eine Verzögerung an einer Stelle schiebt also nicht alles Übrige nach hinten. Am stärksten bewegen späte Scope-Erweiterungen und Integrationen, die zu Beginn niemand inventarisiert hat.

Immer. Wir designen Mobile-First, weil dort der Großteil des E-Commerce-Traffics liegt und der größte Teil der Conversion verloren geht. Jeder Shop wird auf echten Geräten getestet, nicht nur im verkleinerten Browserfenster, und vor dem Livegang gegen die Core Web Vitals gemessen - Largest Contentful Paint, Interaktionslatenz, Layout Shift. Die meiste Aufmerksamkeit bekommen Bildhandling, Font-Loading und Drittanbieter-Skripte, denn meist sind es Apps, die aus einem schnellen Theme einen langsamen Shop machen. Performance ist hier eine Launch-Bedingung und kein Ticket für danach.

Ja. Unsere Store-Management-Pläne decken Shopify- und App-Updates, iterative Verbesserungen, Testing und technischen Support ab, in einem monatlichen Umfang, den du anpassen kannst, wenn sich Prioritäten verschieben. Die meisten Shops brauchen die ersten Wochen nach dem Launch stärker als erwartet: Echter Traffic findet Sonderfälle, die Staging nie erzeugt hat, und die Analytics fangen erst mit Volumen an, die Wahrheit zu sagen. Danach besteht die laufende Arbeit meist aus Conversion-Iterationen auf den umsatztragenden Templates, Support für saisonale Kampagnen und dem Aktuellhalten des Themes, wenn Shopify Plattformänderungen ausliefert.

Auf jeden Fall, und wir sagen es dir auch, wenn ein Rebuild nicht die richtige Entscheidung ist. Wir arbeiten oft in fokussierten Iterationen - ein Conversion-Audit, Performance-Optimierung oder das Redesign der wenigen Templates, die den Großteil des Umsatzes tragen - ausgeliefert als gestaffelte Releases mit messbaren Ergebnissen statt als Big-Bang-Relaunch. Für einen Shop, der bereits konvertiert, ist das meist die bessere Rechnung: Du behältst, was funktioniert, investierst dort, wohin die Daten zeigen, und vermeidest das Risikofenster, das ein kompletter Replatform öffnet. Ein Rebuild lohnt sich, wenn das darunterliegende Theme oder Datenmodell die eigentliche Grenze ist.

Buche einen kostenlosen Strategie-Call - rund dreißig Minuten, und was dabei herauskommt, behältst du in jedem Fall. Wir fragen, was du heute betreibst: Plattform, Katalogstruktur, angebundene Systeme, und was nach dem Projekt besser sein soll. Daraus bekommst du ein schriftliches Angebot mit Umfang, Timeline und Preis, mit benannten Arbeitsblöcken statt einer einzigen Zahl. Wenn das Gespräch zeigt, dass du weniger brauchst als ein Agenturprojekt, sagen wir dir das auch. Das ist für beide Seiten das günstigere Gespräch, als es im zweiten Monat zu merken.

Jedes Projekt läuft durch Strategie, Design, Entwicklung, Launch und laufenden Support, mit einer Discovery-Phase, bevor die erste Design-Arbeit beginnt. Jede Phase endet in etwas, das du prüfen kannst, statt in einem Status-Update: ein Scope-Dokument, klickbare Designs, ein Staging-Shop. Releases sind gestaffelt, QA ist strukturiert statt einer letzten Woche Durchklicken, und die Meilensteine stehen vor dem Kickoff fest. Die Form bleibt gleich, ob ein Projekt zwei Wochen oder sechs Monate läuft - was sich ändert, ist der Umfang innerhalb der Phasen, nicht ihre Anzahl.

Wir starten damit, deine Marke, deine Kundschaft und das zu verstehen, was im Business tatsächlich passieren soll. Statt eine Vorlage über jedes Projekt zu legen, schauen wir, woher der Umsatz heute kommt und wo er verloren geht - und das ist oft nicht die Stelle, die das Briefing vermutet hat. Daraus entsteht ein Scope mit Prioritäten, damit klar ist, was zuerst weichen kann, wenn etwas weichen muss. Es heißt auch, dass wir manchmal weniger vorschlagen als gefragt war: Der schnellste Weg zum Ergebnis ist meist ein schmaleres erstes Release, kein längeres.

Der Kernprozess bleibt konsistent, seine Tiefe passt sich dem Umfang an. Ein Zwei-Wochen-Projekt und ein Sechs-Monats-Build durchlaufen dieselben Phasen - Discovery, Design, Entwicklung, QA, Launch - denn eine davon zu überspringen macht ein Projekt nicht schneller, sondern nimmt ihm die Nachvollziehbarkeit. Was skaliert, ist der Papierumfang: Ein kleines Projekt braucht ein kurzes Scope-Dokument und eine Review-Runde, ein Replatform braucht eine Dateninventur, eine Redirect-Map und getestete Cutover-Läufe. Der Workflow existiert, um Entscheidungen nachvollziehbar zu machen, nicht um Zeremonie abzurechnen.

Zusammenarbeit zieht sich durch das ganze Projekt, statt erst bei der Übergabe aufzutauchen. Du bekommst regelmäßige Updates, Review-Punkte am Ende jeder Phase und direkten Zugang zu den Leuten, die die Arbeit machen, statt einer Weiterleitung über einen Account Manager. Feedback holen wir dort ein, wo es am günstigsten umzusetzen ist - im Design, nicht nach der Entwicklung - und jede Änderung wird separat angeboten, bevor sie gebaut wird. So ist die Budgetwirkung einer Entscheidung sichtbar, während du sie triffst. Nichts Wesentliches sollte beim Launch überraschen.

Qualität steckt im Prozess, statt am Ende geprüft zu werden. Designs gehen durch ein Review, bevor die Entwicklung startet, der Code folgt Shopifys Plattform-Konventionen, damit er künftige Updates übersteht, und jedes Release durchläuft strukturierte QA über Geräte und Browser hinweg - keinen letzten Nachmittag Durchklicken auf der Startseite. Zuerst testen wir die Pfade, an denen Geld hängt: Suche, Produkt, Warenkorb, Checkout. Performance und Barrierefreiheit prüfen wir ebenfalls vor dem Launch, weil beides deutlich günstiger einzubauen als nachzurüsten ist, sobald ein Shop live ist.

Mit dem Launch fangen die brauchbaren Daten an, dort endet nicht das Projekt. Wir beobachten den Shop durch die ersten Wochen, in denen echter Traffic die Sonderfälle findet, die Staging nie erzeugt hat, und beheben, was auftaucht. Danach kannst du mit einem Store-Management-Plan weitermachen, der Updates, iterative Verbesserungen, Testing und technischen Support abdeckt, oder den Betrieb intern übernehmen. Dokumentation übergeben wir in beiden Fällen: Das Theme ist gebaut, damit dein Team es betreiben kann, nicht damit du von unserem abhängig bleibst.