Häufig gestellte Fragen

Wir nutzen KI-Assistenten als technische Partner, um Probleme schneller zu diagnostizieren und präzisere Lösungen zu entwickeln. Jede Ausgabe wird überprüft und getestet, bevor sie in Produktion geht.

KI beschleunigt kritische Arbeit auf zweierlei Weise: Erstens hilft sie uns, Muster gegen Tausende bekannter Szenarien abzugleichen und die Diagnosezeit von Stunden auf Minuten zu reduzieren. Zweitens generiert sie Code, den wir gegen Ihren spezifischen Tech-Stack verifizieren. Sie zahlen für Expertise im richtigen Umgang mit KI – zu wissen, wann man ihr vertrauen kann, wann man sie überstimmen muss und wie man gründlich testet.

Vergleichbar mit einem erfahrenen Mechaniker, der Diagnosesoftware verwendet. Das Tool beschleunigt den Prozess, aber die menschliche Expertise bestimmt die tatsächliche Lösung.

Ja. Wir arbeiten mit externen KI-Anbietern (wie OpenAI, Anthropic) mit aktivierten strikten Datenschutzmodi. Ihr Code wird verarbeitet, aber niemals zum Training ihrer Modelle verwendet und ist für niemanden sonst abrufbar.

So schützen wir Ihre Informationen: Alle großen KI-Anbieter bieten Enterprise-Datenschutzeinstellungen, die verhindern, dass Ihre Daten langfristig gespeichert oder zur Modellverbesserung verwendet werden. Wir arbeiten ausschließlich mit diesen datenschutzaktiven Modi. Bei sensiblen Daten (API-Keys, Zugangsdaten, personenbezogene Informationen) bereinigen oder entfernen wir diese vollständig vor jeder KI-Verarbeitung. Bei vertraulichen Projekten unterzeichnen wir selbstverständlich NDAs.

Bei Authentifizierungssystemen, Zahlungsabwicklungen und Verarbeitung personenbezogener Daten schreiben wir kritische Abschnitte oft manuell ohne jegliche KI-Beteiligung. Sicherheit ist nicht verhandelbar – wir balancieren KI-Effizienz mit Ihren Datenschutzanforderungen.

Wir prüfen jede Zeile KI-generierten Codes, bevor er in Produktion geht. Keine KI-Ausgabe wird ohne menschliche Verifikation, Tests und Sicherheitsüberprüfung live geschaltet.

Unser Workflow: KI schlägt Lösungen vor, wir bewerten diese gegen Ihre Anforderungen, testen auf Grenzfälle, prüfen auf Sicherheitslücken und verifizieren, dass der Code sich ordnungsgemäß in Ihr bestehendes System integriert. Wir behandeln KI-Vorschläge wie Output von Junior-Entwicklern – nützliche Ausgangspunkte, die erfahrene Aufsicht erfordern.

Was wir prüfen: Sicherheitslücken (SQL-Injection, XSS, Authentifizierungs-Bypässe), Performance-Probleme (N+1 Queries, Memory Leaks), Wartbarkeit (ist dieser Code in 6 Monaten noch lesbar?) und Geschäftslogik-Korrektheit (löst er tatsächlich Ihr Problem?). Unsicherer oder schlecht architektierter Code wird umgeschrieben oder abgelehnt – unabhängig davon, ob ihn zunächst KI oder Menschen geschrieben haben. Sie sind durch unseren Review-Prozess geschützt, nicht durch blindes Vertrauen in KI-Output.

Wir sind transparent: KI-Tools sind in unseren Entwicklungsworkflow integriert, und davon profitieren Sie direkt. Moderne Entwicklungsassistenten helfen uns, saubereren Code schneller zu schreiben, Bugs früher zu erkennen und Konsistenz über Ihr Projekt hinweg aufrechtzuerhalten – was bessere Qualität zu fairen Preisen bedeutet.

Aber entscheidend ist: Ihre Projektdaten, Geschäftslogik und sensiblen Informationen bleiben privat. Wir nutzen KI genauso wie jedes professionelle Tool – strategisch, mit voller Kontrolle darüber, was verarbeitet wird und wie. Vergleichbar mit Rechtschreibprüfung für Code, nicht Outsourcing Ihres Projekts an eine Black Box.

Bei spezifischen Datenschutzanforderungen (Gesundheitsdaten, proprietäre Algorithmen, regulierte Branchen) arbeiten wir innerhalb dieser Rahmenbedingungen. Wir können genau besprechen, welche Tools wo eingesetzt werden und unseren Ansatz für sensible Komponenten anpassen.

Was wir nicht tun: So zu tun, als hätte sich die Branche nicht weiterentwickelt. KI-unterstützte Entwicklung ist mittlerweile Standard bei seriösen Softwarehäusern – der Unterschied liegt darin, ob Ihr Anbieter ehrlich damit umgeht und sie verantwortungsvoll einsetzt. Das tun wir.

Ja, falls das Projekt rettbar ist. Wir prüfen zunächst, was existiert, identifizieren, was verwertbar ist, und geben Ihnen eine ehrliche Einschätzung, bevor wir uns zur Fertigstellung verpflichten.

Der typische "Entwickler verschwunden"-Prozess: Innerhalb von 24-48 Stunden verschaffen wir uns Zugang zu dem, was hinterlassen wurde – Codebasis, Datenbanken, Dokumentation (falls vorhanden), Deployment-Setup. Wir führen Diagnosen durch, um Codequalität, Fertigstellungsgrad und Schwere der technischen Schulden zu bestimmen. Dann geben wir Ihnen drei Optionen: Fertigstellung wie vorliegend (am schnellsten), Refactoring kritischer Bereiche (mittlerer Zeitrahmen) oder Neuaufbau von Grund auf (wenn der vorhandene Code nicht zu retten ist).

Was wir nicht tun: Versprechen, jedes Projekt ohne Prüfung fertigzustellen. Manche verlassenen Projekte sind so schlecht architektiert, dass die Fertigstellung mehr kostet als ein Neuaufbau. Wir sagen Ihnen die Wahrheit innerhalb der ersten Diagnosesitzung – selbst wenn diese Wahrheit "neu beginnen" lautet. Die Audit-Phase umfasst Tests, was funktioniert, Dokumentation dessen, was fehlt, und realistische Schätzung der Fertigstellungszeitpläne basierend auf tatsächlicher Codequalität, nicht Wunschdenken.

Die meisten Produktionsausfälle erhalten eine erste Diagnose innerhalb von 2-4 Stunden, wobei viele kritische Probleme innerhalb von 24-72 Stunden je nach Komplexität und Systemzugang gelöst werden.

Die Geschwindigkeit hängt von drei Faktoren ab: Wie schnell Sie Zugang bereitstellen können (Hosting-Zugangsdaten, Datenbank, Codebasis), wie klar die Fehlersymptome sind (spezifische Fehlermeldungen sind besser als "es hat einfach aufgehört zu funktionieren") und ob es sich um ein bekanntes Problem handelt oder tiefes Debugging erfordert. Beispiel: Ein fehlkonfigurierter Server nach einer Host-Migration könnte in Stunden behoben sein. Ein subtiles Datenbank-Korruptionsproblem, das intermittierende Abstürze verursacht, könnte 2-3 Tage zur vollständigen sicheren Diagnose und Reparatur benötigen.

Unser Ansatz: Wir priorisieren, Ihre Seite zunächst funktionsfähig zu machen (auch wenn nicht schön), dann wenden wir ordnungsgemäße Fixes an, sobald Sie wieder online sind. Es macht keinen Sinn, 8 Stunden mit der perfekten Lösung zu verbringen, während Ihr Geschäft offline ist. Erwarten Sie regelmäßige Updates während der Diagnose – wir verschwinden nicht während Notfällen.

Wir führen Reverse Engineering durch. Die meisten Codebasen sind selbstdokumentierend, wenn man weiß, wo man suchen muss – Datenbankschemata, Git-Historie, Code-Kommentare und Benennungskonventionen erzählen die Geschichte.

Undokumentierte Projekte sind häufig. Wir beginnen mit dem Mapping der Architektur: Welches Framework ist das? Wie fließen die Daten? Wo sind die kritischen Abhängigkeiten? Dann verfolgen wir den Bug rückwärts von Symptomen zur Grundursache. Tools helfen (KI-gestützte Code-Analyse, Dependency-Graphen, Fehlerlog-Korrelation), aber Erfahrung zählt mehr – Muster aus Hunderten vorheriger Debugging-Sessions zu erkennen.

Das größte Risiko bei undokumentiertem Code ist nicht, das unmittelbare Problem zu beheben – es ist, unwissentlich etwas anderes zu brechen. Deshalb testen wir gründlich vor, während und nach Reparaturen. Wenn Ihr vorheriger Entwickler null Kommentare und keine Git-Historie hinterlassen hat, erwarten Sie, dass die Diagnosephase länger dauert. Wir beheben nicht nur den Bug; wir bauen ein mentales Modell davon auf, wie Ihr gesamtes System funktioniert, um Kollateralschäden zu vermeiden.

Ja, bei den meisten gängigen Hacks (Malware-Injektionen, verunstaltete Seiten, Spam-Redirects). Wir bewerten die Schadenschwere, entfernen bösartigen Code, patchen Schwachstellen und stellen aus sauberen Backups wieder her, wenn verfügbar.

Der Wiederherstellungsprozess hängt von Angriffstyp und Tiefe der Kompromittierung ab. Oberflächliche Hacks (injizierte Spam-Links, verunstaltete Homepage) werden oft innerhalb von 24-48 Stunden bereinigt. Tiefere Kompromittierungen (Backdoors in Core-Dateien, Datenbankmanipulation, Server-Level-Zugriff) erfordern gründlichere Untersuchung – manchmal 3-5 Tage, um sicherzustellen, dass der Angreifer vollständig entfernt ist und nicht zurückkehren kann.

Was wir tun: Infizierte Dateien isolieren, auf Malware-Signaturen scannen, Datenbankintegrität prüfen, Server-Logs auf Eintrittspunkte überprüfen, die Schwachstelle patchen, die den Hack ermöglichte, alle Zugangsdaten ändern und verifizieren, dass die Seite sauber ist, bevor sie wieder online geht. Wenn Sie Backups von vor dem Angriff haben, ist die Wiederherstellung schneller. Falls nicht, bauen wir wieder auf, was rettbar ist, und dokumentieren, was verloren ging. Wir bieten auch Post-Recovery-Härtungsempfehlungen (aktualisierte Software, Sicherheits-Plugins, Firewall-Regeln), um wiederholte Angriffe zu verhindern – aber laufendes Sicherheitsmonitoring erfordert einen Wartungsplan, nicht eine einmalige Reparatur.

Wir springen als Ihr neuer technischer Kontakt ein. Zuerst verschaffen wir uns Zugang zu allem (Hosting, Domain, Codebasis, Konten), dann bewerten wir, was sie tatsächlich geliefert haben versus was Sie bezahlt haben.

Post-Launch-Verlassenheit ist frustrierend häufig – besonders bei Agenturen, die Projekte als einmalige Verkäufe statt als fortlaufende Beziehungen behandeln. Unser Übernahmeprozess: Wir fordern Zugangsdaten für alle Systeme an (Hosting, Domain-Registrar, CMS-Admin, Git-Repository falls vorhanden, E-Mail-/Analytics-Konten). Dann prüfen wir, was geliefert wurde – entspricht es dem ursprünglichen Scope? Gibt es offensichtliche Bugs, die sie ignorierten? Ist der Code wartbar oder ein verworrenes Durcheinander?

Von dort entscheiden Sie die nächsten Schritte: Sofortige Probleme beheben und weitermachen, uns für laufenden Support engagieren oder eine schrittweise Migration zu besserer Infrastruktur planen, falls das, was sie bauten, grundlegend fehlerhaft ist. Wir haben alles gesehen, von völlig einwandfreien Codebasen (Agentur hatte nur schlechte Kundenkommunikation) bis zu kompletten Desastern, die kaum funktionieren. So oder so erhalten Sie innerhalb der ersten Woche eine ehrliche Einschätzung – einschließlich, ob es sich lohnt, ihre Arbeit zu warten oder neu zu beginnen. Keine Agentur-Loyalität hier; wir arbeiten für Sie, nicht für sie.

Einfache Integrationen (Zahlungs-Gateway, E-Mail-Service) dauern 1-2 Wochen. Multi-System-Integrationen mit komplexem Daten-Mapping dauern 2-4 Wochen. Custom-Integrationen mit schlecht dokumentierten APIs können sich auf 4-8 Wochen erstrecken.

Der Zeitrahmen hängt von vier Faktoren ab: API-Qualität (gut dokumentiert mit Sandbox-Umgebung vs. kryptische Docs und kein Testmodus), Datenkomplexität (einfacher Webhook vs. komplexe bidirektionale Synchronisation), Authentifizierungsmethode (modernes OAuth vs. Legacy-SOAP) und Ihr interner Freigabeprozess (sofortige Entscheidungen vs. mehrwöchige Stakeholder-Reviews).

Wir geben Zeitschätzungen nach der Discovery-Phase – sobald wir beide APIs und Datenanforderungen tatsächlich geprüft haben. Agenturen, die Zeitrahmen vor Prüfung der APIs zitieren, raten. Wir nicht. Wenn wir "2 Wochen" sagen, erwarten Sie 2 Wochen, es sei denn, der Anbieter ändert seine API mitten im Projekt (selten, kommt aber vor).

Wir führen Reverse Engineering durch. Schlechte Dokumentation ist häufig, besonders bei älteren Plattformen. Wir testen Endpoints manuell, inspizieren Antworten und lernen oft mehr aus Fehlermeldungen als aus offiziellen Docs.

Die Realität: Viele Anbieter liefern schreckliche API-Dokumentation, weil sie Vertrieb über Developer Experience priorisieren. Damit haben wir regelmäßig zu tun. Unser Prozess: Test-API-Calls durchführen, um zu sehen, was tatsächlich zurückkommt (nicht was Docs behaupten), Response-Strukturen inspizieren, um Datenformate zu verstehen, Edge-Cases testen, um undokumentiertes Verhalten zu entdecken, und Vendor-Support mit spezifischen technischen Fragen kontaktieren (die meisten Support-Teams sind nutzlos, aber gelegentlich findet man jemanden Technischen).

Diese Discovery-Arbeit dauert länger – manchmal verdoppelt sich die initiale Zeitschätzung. Wir berechnen diese Zeit, weil es notwendige Arbeit ist, keine Ineffizienz. Wenn die API des Anbieters wirklich undokumentiert ist und ihr Support-Team nicht antwortet, sagen wir Ihnen, ob die Integration machbar ist oder ob Sie einen Anbieterwechsel erwägen sollten. Manche APIs sind schlicht zu kaputt oder undokumentiert, um zuverlässig zu integrieren – wir sind von Projekten zurückgetreten, wo die API des Anbieters grundlegend unbrauchbar war.

Wir bauen mit Monitoring und Error-Logging, sodass Sie sofort wissen, wenn etwas bricht. Dann bewerten wir, ob es eine behebbare Änderung ist oder ein Neuaufbau der Integration erforderlich ist.

API-Änderungen fallen in drei Kategorien: Minor (Versions-Updates, neue optionale Felder) – meist keine Aktion erforderlich. Medium (Deprecation-Warnungen, Authentifizierungs-Änderungen) – wir aktualisieren innerhalb von 30-90 Tagen, bevor die alte Version abgeschaltet wird. Major (komplettes API-Redesign, Sunset ohne Ersatz) – erfordert Neuaufbau der Integration oder alternative Lösungen.

Unsere Integrationen beinhalten Error-Alerting, sodass Sie sofort benachrichtigt werden, wenn eine API-Änderung etwas bricht, statt es drei Wochen später zu entdecken, wenn ein Kunde sich beschwert. Wir loggen auch alle API-Requests und -Responses, was die Diagnose schnell macht, wenn Probleme auftreten. Wenn Sie einen Wartungsplan bei uns haben, überwachen wir Vendor-Changelogs proaktiv und wenden Updates an, bevor Breaking Changes eintreten. Ohne Wartungsplan sind Sie verantwortlich für die Überwachung der Vendor-Ankündigungen und Kontaktaufnahme mit uns, wenn Probleme entstehen – was riskant ist, wenn der Vendor wenig Vorwarnung gibt.

Manchmal, abhängig vom verfügbaren Zugang. Wenn das System eine Datenbank hat, auf die wir zugreifen können, Daten-Dateien exportiert oder irgendeine programmatische Schnittstelle hat, gibt es meist einen Weg – auch wenn er nicht elegant ist.

Non-API-Integrationsoptionen: Direkter Datenbankzugriff (nicht ideal, funktioniert aber, wenn das System es erlaubt), geplante Datei-Exports/-Imports (CSV, XML, JSON), Screen-Scraping (absolut letzter Ausweg, fragil und bricht leicht) oder Custom-Middleware, die zwischen Systemen übersetzt. Jeder Ansatz hat Tradeoffs. Direkter Datenbankzugriff ist schnell, aber riskant, wenn sich das Schema ändert. Datei-Imports funktionieren, sind aber nicht Echtzeit. Screen-Scraping ist hacky und bricht, wann immer der Vendor sein UI aktualisiert.

Bevor wir diese Workarounds verfolgen, bewerten wir zwei Dinge: Ist dies die Komplexität und Wartungslast wert? Würde der Wechsel zu einem anderen System mit ordentlicher API langfristig weniger kosten? Wenn Ihr proprietäres System wirklich locked down ohne Integrationspfad ist, sagen wir es Ihnen ehrlich – manchmal ist die richtige Antwort "System ersetzen", nicht "fragilen Workaround hacken".

Wir implementieren Retry-Logik mit exponentiellem Backoff, Queue-Systeme für High-Volume-Operationen und Caching wo angemessen. Wenn APIs ausfallen, degradiert Ihr System elegant statt abzustürzen.

Rate-Limits sind unvermeidbar bei den meisten APIs – typischerweise Requests-pro-Sekunde oder tägliche Quoten. Wir handhaben dies mit Queuing (Verteilen von Requests über Zeit statt Bursting), Caching häufig abgerufener Daten (Reduzierung unnötiger API-Calls) und Webhook-Listeners (Vendor pusht Updates, statt dass wir konstant pollen). Wenn Sie trotz Optimierungen Rate-Limits erreichen, implementieren wir graceful Degradation – Ihr System funktioniert weiter mit leicht verzögerten Daten, statt Fehler zu werfen.

Bei Downtime: Alle Drittanbieter-Services fallen irgendwann aus. Unsere Integrationen erkennen Ausfälle, loggen Fehler und retrien automatisch, wenn Services sich erholen. Kritische Operationen werden für später gequeued statt verloren. Sie erhalten Monitoring-Alerts bei längeren Ausfällen, sodass Sie nicht überrascht werden. Was wir nicht können: Unzuverlässige Vendor zuverlässig machen. Wenn deren API 95% Uptime hat, wird Ihre Integration das reflektieren – keine Menge cleveres Coding fixt einen grundlegend unzuverlässigen Service. Wir warnen Sie während der Discovery, wenn die Zuverlässigkeit des Vendors fraglich ist.

Erfahrung zählt. Wir haben Hunderte API-Integrationen debuggt und erkennen Fehlermuster schnell – Authentifizierungsprobleme, Datentyp-Mismatches, undokumentierte Rate-Limits, Timezone-Handling-Bugs.

Häufige DIY-Integrationsfehler: OAuth-Flows missverstehen (die meisten APIs verwenden dies jetzt, aber die Implementierung variiert wild), Error-Responses nicht ordentlich handhaben (APIs scheitern auf unerwartete Weisen), Rate-Limits ignorieren, bis sie Produktion brechen, schlechte Datenvalidierung, die korrupte Syncs verursacht, und kein Monitoring oder Logging (Sie wissen nicht, dass es kaputt ist, bis Kunden sich beschweren).

Wir haben Erfolg, weil wir diese Fehler bereits gemacht haben – bei anderen Projekten. Sie profitieren von Jahren schmerzhafter Debugging-Sessions, seltsamer Vendor-Eigenheiten und Edge-Cases, denen wir begegnet sind. Wir wissen auch, wann man um Hilfe fragt (Vendor-Support, Developer-Communities, GitHub-Issues anderer Entwickler über dieselben API-Probleme lesen). Wenn Ihr vorheriger Entwickler scheiterte, weil die API des Vendors wirklich kaputt oder die Integration technisch unmöglich ist, entdecken wir das in der Assessment-Phase und sagen es Ihnen ehrlich. Nicht jeder Integrationsversuch sollte gelingen – manche sollten zugunsten besserer Lösungen aufgegeben werden.

Mini-Anwendungen konzentrieren sich darauf, ein Kernproblem gut zu lösen, statt alles für jeden zu sein. Kleinerer Scope, schnellere Lieferung, niedrigere Kosten – aber dennoch produktionsreife Code-Qualität.

Der Unterschied liegt in bewussten Einschränkungen: Begrenztes Feature-Set (ein primärer Workflow, nicht zehn konkurrierende Prioritäten), einfacherer Tech-Stack (bewährte Tools, keine experimentellen Frameworks), pragmatisches Design (funktional und sauber, nicht preisgekrönt) und schlanke Architektur (einfach zu verstehen und zu modifizieren, nicht over-engineered für theoretische zukünftige Bedürfnisse). Das bedeutet nicht billig oder fragil – es bedeutet fokussiert.

Beispiel: Eine vollständige E-Commerce-Plattform handhabt Inventar, Bestellungen, Versand, Kunden, Analytics, Marketing, Reviews und Multi-Vendor-Support. Eine Mini-Anwendung könnte nur "eine einfache Bestellschnittstelle für Ihr Restaurant" sein mit Menüverwaltung und Bestellbenachrichtigungen. Sie erhalten 90% des Werts zu 20% der Kosten, indem Sie unnötige Features gnadenlos weglassen. Wir helfen Ihnen, die 10% zu identifizieren, die wirklich zählen, statt alles zu bauen und zu hoffen, dass es funktioniert.

Der Code ist wartbar und erweiterbar gebaut. Features später hinzuzufügen ist unkompliziert, weil die Architektur sauber ist, nicht verworren. Sie können uns oder jeden kompetenten Entwickler engagieren, um sie zu erweitern.

Wir schreiben Mini-Anwendungen mit zukünftigem Wachstum im Hinterkopf – modulare Struktur, klare Dokumentation, Standard-Patterns – aber wir over-engineeren nicht für hypothetische Features, die Sie vielleicht nie brauchen. Wenn Sie etwas hinzufügen müssen, ist das Fundament solide. Häufige Ergänzungen: Benutzerrollen und -berechtigungen (falls mit Single-User-Admin gestartet), zusätzliche Datenfelder oder Workflows, Drittanbieter-Integrationen, Reporting- und Export-Features.

Kosten für Erweiterung: Abhängig von Komplexität, aber typischerweise 30-50% günstiger als wenn wir das Feature initial gebaut hätten, weil das Fundament bereits existiert und wir die Codebasis verstehen. Wenn ein anderer Entwickler übernimmt, machen der saubere Code und die Dokumentation seine Arbeit einfacher (und günstiger für Sie). Was wir vermeiden: Features "für alle Fälle" bauen, die das initiale Projekt aufblähen und vielleicht nie genutzt werden. Sie können Features immer hinzufügen, wenn Sie sie tatsächlich brauchen – zu versuchen, jeden zukünftigen Bedarf im Voraus vorherzusagen, ist wie Projekte von €5k auf €50k aufblasen, obwohl sie €5k hätten sein sollen.

Ja, durch Verwendung bewährter Technologien und sauberer Architektur von Tag Eins. Der Unterschied zwischen einem guten MVP und einem Wegwerf-Prototyp ist Code-Qualität, nicht Feature-Anzahl.

Nachhaltige MVPs fokussieren auf: Solide Datenmodelle (Ihr Datenbankschema ist am schwersten später zu ändern, also designen wir es von Anfang an richtig), wartbare Codebasis (lesbarer Code mit klarer Struktur, mit dem andere Entwickler arbeiten können), Standard-Frameworks (Laravel, React, Next.js – keine experimentelle Tech, die in einem Jahr aufgegeben wird) und ordentliches Testing (automatisierte Tests für Core-Features, sodass Sie Features sicher hinzufügen können, ohne Bestehendes zu brechen).

Was sich beim Skalieren ändert: Infrastruktur (Umzug von Shared-Hosting zu dedizierten Servern), Optimierung (Caching-Layer, Datenbank-Indexierung, Frontend-Performance) und Team-Struktur (mehrere Entwickler, Deployment-Pipelines). Aber der Core-Application-Code bleibt solide. Wir haben MVPs gesehen, die von 10 auf 10.000 Nutzer wuchsen ohne Rewrite-Bedarf – nur Optimierung und Skalierung. Der "MVP = Wegwerf-Code"-Mythos kommt von Agenturen, die absichtlich Müll-MVPs bauen, um Ihnen später ein Rebuild zu verkaufen. So arbeiten wir nicht. Wenn wir es bauen, bauen wir es ordentlich – auch wenn es bewusst klein im Scope ist.

Wir haben keinen Agentur-Overhead (Account Manager, Sales-Teams, schicke Büros). Sie zahlen für Entwicklungsarbeit, nicht für Unternehmensstruktur. Wir vermeiden auch Feature-Bloat, indem wir uns auf das konzentrieren, was Sie tatsächlich brauchen.

Kostenersparnis-Aufschlüsselung: Kein Sales-Prozess (Sie kontaktieren uns direkt, wir bewerten Fit, kein mehrmonatiger Verhandlungstanz), keine Projektmanager (Entwickler kommunizieren direkt mit Ihnen – schneller und klarer), keine aufwendigen Discovery-Phasen (wir stellen gezielte Fragen, führen nicht wochenlang Stakeholder-Interviews für ein einfaches Tool durch) und keine künstlichen Preisstufen (Agenturen packen Features, um Preispunkte zu erreichen; wir schätzen basierend auf tatsächlich erforderlicher Arbeit).

Wir bauen auch pragmatisch: Wenn eine existierende Open-Source-Library 80% Ihres Problems löst, verwenden wir sie, statt von Grund auf neu zu bauen. Wenn ein einfacheres UI den Job erledigt, verschwenden wir keine Zeit mit elaborierten Design-Mockups. Wenn Ihr Feature mit manuellen Admin-Controls starten kann statt einem komplexen Automatisierungssystem, starten wir einfach und automatisieren später, wenn das Volumen es rechtfertigt. Agenturen über-bauen oft, weil Komplexität höhere Gebühren rechtfertigt. Wir bauen, was Sie brauchen, nicht was unsere Rechnung maximiert.

Sie migrieren zu einer robusteren Lösung, wenn Ihre Bedürfnisse wirklich das übersteigen, was die Mini-App bietet. Das ist ein Erfolgssignal, kein Misserfolg. Wir können bei der Planung und Durchführung dieser Migration helfen.

Aus einer Mini-App herauswachsen bedeutet meist: User-Volumen überschritt initiales Design (Hunderte wurden Tausende), Feature-Bedürfnisse expandierten signifikant (was als einfaches Bestellsystem startete, braucht jetzt Multi-Location-Inventar) oder Business-Anforderungen änderten sich (Sie sind jetzt in regulierter Branche mit Compliance-Anforderungen). Das sind gute Probleme – sie bedeuten, Ihr Business wuchs.

Migrationsoptionen: Existierende Anwendung mit mehr Infrastruktur erweitern (funktioniert oft bis zu einem Punkt), spezifische Komponenten rebuilden, während andere behalten werden (schrittweise Modernisierung) oder Migration zu Enterprise-Plattformen, wenn Komplexität es rechtfertigt (Salesforce, SAP usw. machen Sinn bei einer gewissen Größe). Wir helfen Ihnen bewerten, wann erweitern vs. migrieren. Manche Mini-Apps laufen jahrelang ohne Ersatz-Bedarf – einfache Tools, die einfache Probleme lösen, brauchen keine Enterprise-Architektur. Aber wenn Migration richtig ist, sagen wir es Ihnen ehrlich und helfen bei der Ausführung, statt zu versuchen, Enterprise-Features unangemessen in eine kleine Anwendung zu zwingen.

Ja. Sobald Sie vollständig bezahlt haben, gehört Ihnen aller Custom-Code, den wir für Ihr Projekt schreiben. Wir halten ihn nicht als Geisel oder verlangen Lizenzgebühren. Er gehört Ihnen zum Modifizieren, Erweitern oder an einen anderen Entwickler übergeben.

Was Ihnen gehört: Aller Custom-Application-Code, Datenbankschemata, Konfigurationsdateien und Dokumentation, die wir spezifisch für Ihr Projekt erstellen. Was Ihnen nicht gehört: Drittanbieter-Libraries und Frameworks (die sind bereits Open-Source oder kommerziell lizenziert) und wiederverwendbare Komponenten, die wir gebaut haben, die nicht spezifisch für Ihr Business sind (wir könnten diese Patterns in anderen Projekten verwenden, aber Ihre spezifische Geschäftslogik gehört Ihnen).

Praktisches Eigentum: Sie erhalten vollen Quellcode-Zugriff, Git-Repository mit kompletter Historie (falls gewünscht) und Deploy-Credentials, sodass Sie kontrollieren, wo es läuft. Wenn Sie später zu einem anderen Entwickler wechseln oder Entwicklung in-house bringen möchten, können Sie. Wir verwenden keine proprietären Frameworks oder Lock-in-Taktiken – alles ist mit Standard-, gut dokumentierten Technologien gebaut, mit denen jeder kompetente Entwickler arbeiten kann. Code-Eigentum gehört Ihnen; optionaler laufender Support und Wartung ist ein separater Service, den Sie fortsetzen können oder nicht.

Werden sie nicht. Wir erstellen vollständige Backups, bevor wir etwas anfassen, testen Upgrades zuerst in einer Staging-Umgebung und verifizieren alles, bevor wir auf Produktion umschalten.

Jedes Upgrade beginnt mit einem vollständigen Backup der Datenbank und Dateien – offsite gespeichert, nicht nur auf demselben Server. Dann führen wir das Upgrade in einer Test-Umgebung durch, die eine exakte Kopie Ihrer Produktion ist. Wenn etwas kaputt geht, fixen wir es, bevor wir das Live-Upgrade durchführen.

Bei Hosting-Migrationen: Wir bereiten die neue Umgebung vollständig vor, migrieren alle Daten und Dateien, testen gründlich und schalten erst dann DNS um. Ihre alte Site bleibt unberührt, bis die neue zu 100% verifiziert ist. Wir haben immer einen Rollback-Plan, falls nötig.

Datenverlust während Upgrades oder Migrationen ist fast immer das Ergebnis von Eile, Überspringen von Staging-Tests oder fehlenden ordentlichen Backups. Wir machen keinen dieser Fehler. Wenn wir sagen, Ihre Daten sind sicher, dann weil wir es in der Test-Umgebung bewiesen haben, bevor wir Produktion anfassen.

Abhängig von der Art der Arbeit. Die meisten Versions-Upgrades (z.B. Contao 4 → 5, PHP 7.4 → 8.2) erfordern 1–4 Stunden Downtime in einem geplanten nächtlichen Fenster. Hosting-Migrationen können 4–12 Stunden dauern, abhängig von Datenbankgröße und Konfigurationskomplexität.

Wir minimieren Downtime durch Vorbereitung im Voraus: Wir testen das Upgrade in der Staging-Umgebung, dokumentieren alle Schritte, lösen Probleme vor der Produktion und führen dann das finale Upgrade während Ihres niedrigsten Traffic-Fensters durch (typischerweise 2–6 Uhr morgens).

Bei Hosting-Migrationen ist Downtime hauptsächlich auf DNS-Propagation beschränkt (1–24 Stunden) – die technische Arbeit selbst wird vorher auf dem neuen Server durchgeführt. User können einen kurzen Übergang erleben, aber die meisten Projekte wachen morgens zum upgegradeten System auf ohne längere Downtime.

Wenn Ihre Site hohen Traffic hat und Downtime teuer ist, können wir fortgeschrittene Techniken anwenden (Blue-Green-Deployment, phasenweise Rollouts), aber das erhöht Komplexität und Kosten. Die meisten kleinen bis mittleren Projekte brauchen so einen Ansatz nicht.

Wir rollen zum Backup zurück, diagnostizieren das Problem, fixen es in der Test-Umgebung und versuchen es erneut. Deshalb upgraden wir nie ohne getestete Backups und Rollback-Prozeduren.

Einen dokumentierten Rollback-Plan zu haben bedeutet, dass Fehler behebbar sind, nicht katastrophal. Wenn etwas schiefgeht: Wir stellen Datenbank und Dateien aus dem Backup wieder her (typischerweise 15–30 Minuten), untersuchen was fehlschlug, fixen das Problem in der Staging-Umgebung, testen erneut und versuchen das Upgrade dann im nächsten geplanten Fenster erneut.

Typische Probleme, auf die wir vorbereitet sind: Inkompatibilitäten benutzerdefinierter Erweiterungen (upgegradetes Framework bricht alten Code), Performance-Probleme nach dem Upgrade aufgedeckt (ineffiziente Queries, die vorher verborgen waren), Integrationen mit externen APIs, die wegen Versionsänderungen brechen, und Edge-Case-Bugs nicht in Tests gefangen (unerwartete Datenkombinationen, obskure User-Workflows).

Was professionelle Upgrades von Desastern trennt: Wir erwarten Probleme und planen dafür. Amateur-Upgrades nehmen an, dass alles funktioniert – dann Panik, wenn nicht. Wir kommunizieren sofort, wenn etwas bricht, führen Rollback durch falls nötig und fixen es richtig, bevor wir es erneut versuchen.

Versions-Upgrade: Aktualisierung der Plattform (Contao 3 → 4 → 5, PHP 7.x → 8.x, TastyIgniter, Next.js, Symfony-Abhängigkeiten) auf demselben Hosting. Code muss angepasst werden, um mit neuerer Framework-Version zu funktionieren. Beispiel: Ihre Contao 3 Site auf PHP 7.4 wird zu Contao 5 auf PHP 8.2 – derselbe Server, upgegradete Plattform.

Hosting-Migration: Verschieben der gesamten Site von einem Server zum anderen – dieselbe Plattform-Version, neue Umgebung. Beinhaltet Datenbank- und Dateitransfer, DNS-Konfiguration, SSL-Zertifikate, E-Mail-Einstellungen und alle Integrationen. Beispiel: Umzug von veraltetem Hosting-Provider mit ablaufender Abschaltfrist zu modernem VPS-Server.

Oft machen wir beides gleichzeitig: Upgrade Contao 3 → 5 UND Umzug auf neues Hosting im selben Projekt. Das macht Sinn – wir arbeiten bereits an der Konfiguration, also machen wir alle Upgrades auf einmal. Aber jede Operation ist ein separater Satz von Schritten mit eigenen Risiken und Tests.

Versions-Upgrades betreffen hauptsächlich benutzerdefinierten Code und Erweiterungen. Hosting-Migrationen betreffen Infrastruktur-Konfiguration. Beide erfordern Backups, Staging-Tests und Rollback-Pläne – nur die Herausforderungen sind unterschiedlich.

Nein. Wir arbeiten on-demand – Sie rufen an, wenn Sie ein Sicherheits-Update oder technischen Support brauchen, Sie zahlen nur für tatsächlich geleistete Arbeit.

Warum keine monatlichen Verträge: Die meisten kleinen bis mittleren Websites brauchen kein kontinuierliches Monitoring oder wöchentliche Updates. Sicherheitslücken treten unregelmäßig auf – vielleicht zweimal im Jahr, vielleicht einmal alle 18 Monate. Eine monatliche Gebühr für Arbeit zu zahlen, die sporadisch passiert, ist Geldverschwendung.

Unser Ansatz: Wenn ein kritisches Sicherheits-Update auftaucht (CVE in Contao, PHP-Lücke, Dependency-Exploit), kontaktieren Sie uns, wir schätzen die Arbeit, führen das Update durch, Sie testen, Sie zahlen. Keine wiederkehrenden Gebühren. Keine ungenutzten Stunden. Nur echte Arbeit, wenn Sie sie tatsächlich brauchen.

Für Kunden mit sehr niedriger Risikotoleranz oder zeitkritischen Systemen können wir individuelle SLA-Vereinbarungen besprechen – aber das fügt signifikante Kosten hinzu und macht nur Sinn für hochprofitable Projekte, wo selbst eine Stunde Downtime teuer ist. Die meisten Projekte brauchen das nicht.

Wenn Sie proaktives Sicherheits-Monitoring wollen: Verfolgen Sie Sicherheitsankündigungen von Ihrer Plattform (Contao Security Advisories, PHP Security Bulletins) und kontaktieren Sie uns, wenn Sie Updates anwenden müssen. Oder rufen Sie einfach an, wenn Sie von einem Problem hören – wir antworten schnell.

Contao CMS (3 → 4 → 5 und alle Dependency-Updates), TastyIgniter (Versions-Upgrades und benutzerdefinierte Erweiterungen), Next.js und React Apps (Framework-Upgrades, Node.js-Migrationen, npm-Pakete) und Symfony und PHP Apps (Symfony-Framework-Upgrades, PHP 7.x → 8.x Versionsmigrationen, Composer-Updates).

Wir machen auch Rettungen alter Sites, die jahrelang aufgegeben wurden: Contao 3 Site auf PHP 5.6, die seit 2017 nicht angefasst wurde? Wir können sie auf Contao 5 auf PHP 8.2 upgraden. Custom TastyIgniter App mit Erweiterungen, die durch Updates kaputt gingen? Wir fixen und stellen Funktionalität wieder her. Next.js 10 will zu 14 gehen? Wir handhaben deprecated APIs und Breaking Changes.

Was wir NICHT machen: Wir migrieren nicht ganze Plattformen (WordPress → Contao, Custom → Laravel). Das sind Rebuild-Projekte, keine Wartungs-Upgrades – sie erfordern andere Skills und kosten deutlich mehr. Wenn Ihr Projekt ein vollständiges Plattform-Rebuilding braucht, sagen Sie Bescheid – wir können das als separates Projekt besprechen, aber es ist kein Wartungs-Upgrade.

Wenn Ihre Plattform oben nicht aufgeführt ist: Kontaktieren Sie uns und beschreiben Sie Ihren Tech-Stack. Wenn es PHP, Symfony, Node.js oder React verwendet, können wir wahrscheinlich helfen. Wenn nicht, empfehlen wir jemand Geeignetes.

Ja. Das ist ein Kern dessen, was wir tun – aufgegebene Sites mit veralteten Software-Versionen und bekannten Sicherheitslücken retten.

Typisches Szenario: Contao 3 Site auf PHP 5.6 (End-of-Life seit 2018, bekannte Exploits, Hosting-Provider sendet 30-Tage-Kündigungswarnung). Vorheriger Entwickler verschwunden, benutzerdefinierte Erweiterungen funktionierten 2018 perfekt, brechen aber komplett auf neueren Versionen. Site-Besitzer verzweifelt – kann sich keinen vollständigen Rebuild leisten, aber aktuelles System ist zum Scheitern verurteilt.

Unsere Bewertung: Wir analysieren benutzerdefinierten Code und Erweiterungen, mappen was beim Upgrade brechen wird, schätzen Kosten Reparatur vs. Rebuild-Alternativen und geben ehrliche Empfehlung. Manchmal kostet Upgraden weniger als Rebuilding – manchmal ist Rebuilding klüger. Wir sagen, was tatsächlich für Ihre Situation Sinn macht.

Prozess: Wir testen das Upgrade in Staging-Umgebung (sicheres Kaputtmachen, nicht Ihre Live-Site), dokumentieren alles was bricht, fixen benutzerdefinierten Code und Erweiterungen für neuere Version, verifizieren Funktionalität und Sicherheit, führen dann Produktions-Upgrade mit Rollback-Backup durch. Sie können mit Contao 5 auf PHP 8.2 enden, alle Custom-Features wiederhergestellt, Sicherheitslücken gepatcht, Hosting nicht vor Abschaltung stehend.

Nicht alle alten Sites sind es wert, gerettet zu werden – manchmal ist Code so kaputt, dass Rebuilding weniger kostet als Reparieren. Aber wir bewerten das ehrlich während Discovery und geben Ihnen Optionen: Upgrade mit Reparaturen (echter Preis), partielles Rebuilding (Daten behalten, Code auffrischen), vollständiges Rebuilding (komplett neues System) oder Risiko weiterlaufen lassen (wenn Sie sich absolut nichts leisten können). Entscheidung liegt bei Ihnen – wir zeigen nur echte Optionen und Kosten.

Wir schreiben Custom-Code, der für Ihr spezifisches Ziel optimiert ist, statt gegen Template-Limitierungen zu kämpfen. Sie erhalten schnellere Ladezeiten, besseres SEO und keine monatlichen Plattform-Gebühren nach Launch.

Website-Baukasten-Probleme: Aufgeblähter Code (Features laden, die Sie nicht nutzen), Template-Einschränkungen (Kernstruktur nicht modifizierbar), Plattform-Lock-in (Site nicht woanders hin bewegbar), monatliche Gebühren für immer (€10-30/Monat summiert sich), SEO-Limitierungen (schwerer für Suche zu optimieren) und Performance-Probleme (langsames Laden, besonders auf Mobile). Diese Plattformen sind für wiederkehrende Einnahmen designed, nicht Ihren Erfolg.

Unser Ansatz: Sauberer, minimaler Code (nur was Sie brauchen), Custom-Design passend zu Ihrer Marke (nicht Template #47, das 10.000 andere Sites verwenden), Performance-optimiert (schnelles Laden verbessert Conversions), echtes Eigentum (überall hosten, keine Plattform-Abhängigkeit) und einmalige Kosten (einmal zahlen, für immer besitzen – optionales Hosting separat). Für einfache Landing-Pages scheinen Baukästen initial günstiger (€15/Monat vs. €500 upfront). Aber über 3 Jahre: Baukasten = €540 an Gebühren. Custom = €500 einmal + €70/Jahr Hosting = €710 gesamt. Plus unserer lädt 3x schneller und rankt besser in Suche. Die einzige Zeit, wo Baukästen Sinn machen: Sie brauchen in 2 Stunden etwas live und Qualität ist egal. Für alles andere ist Custom besserer Wert.

Ja, falls Sie ein einfaches CMS während des Projekts anfordern. Andernfalls erfordern Content-Updates Entwickler-Hilfe – aber wir können schnelle Änderungen erschwinglich machen oder Sie in grundlegenden HTML-Edits schulen.

CMS-Optionen: Einfaches Admin-Panel für Text und Bilder (fügt €200-400 zu Projektkosten hinzu), Markdown-basiertes Editing (nur technische User, aber sehr leichtgewichtig) oder direktes HTML-Editing (wir liefern Dokumentation und können Sie schulen). Für die meisten One-Pager ändert sich Content selten – Launch-Ankündigung, Kontaktinfo, vielleicht saisonale Updates. Für ein vollständiges CMS zu zahlen, wenn Sie zweimal im Jahr updaten, ist Overkill.

Ohne CMS: Kleine Text-Änderungen (Telefonnummer, E-Mail, Preise) dauern uns 5-15 Minuten zum Update – wir berechnen minimale Gebühren (€20-40) für schnelle Edits. Größere Updates (neue Bereiche, umstrukturierter Content) werden basierend auf Scope zitiert. Dies ist oft langfristig günstiger als für CMS-Features zu zahlen, die Sie selten nutzen. Wir liefern auch einen einfachen Guide für grundlegende Text-Edits direkt in HTML-Dateien, falls Sie damit komfortabel sind – viele Clients handhaben kleinere Updates so selbst. Die Frage: Wie oft wird Content tatsächlich ändern? Wenn wöchentlich, holen Sie ein CMS. Wenn vierteljährlich oder weniger, ist Pay-per-Update kosteneffektiver.

Mit Content und Assets bereit: 3-5 Tage für Basic-Pages, 5-10 Tage für Advanced-Pages mit Custom-Features. Zeitrahmen hängt von Ihrer Reaktionsfreudigkeit und Content-Bereitschaft ab, nicht nur unserer Entwicklungs-Geschwindigkeit.

Schnelle Liefer-Anforderungen: Content vorbereitet (tatsächlicher Text, nicht "TBD"), Bilder und Medien bereit (Fotos, Logos, Videos), klares Ziel definiert (welche Aktion sollen Besucher ausführen?), Brand-Guidelines bereitgestellt (Farben, Schriften, Style-Referenzen) und schnelle Feedback-Zyklen (innerhalb 24 Stunden während Entwicklung antworten). Wenn Clients alles upfront liefern und schnell antworten, liefern wir schnell.

Was Projekte verlangsamt: Auf Content warten ("wir senden Text nächste Woche"), iterative Design-Änderungen (hätte während Brief entschieden sein sollen), Stakeholder-Approval-Delays (mehrere Runden interner Reviews), fehlende Assets (Logo in falschem Format, Fotos zu klein) und Scope-Creep (Features mid-project hinzufügen). Wir sind schnell, wenn Sie schnell sind. Wenn Sie eine Landing-Page in 3 Tagen live für einen Produktlaunch brauchen, können wir es schaffen – aber Sie müssen alles sofort bereit haben und unseren Design-Entscheidungen ohne lange Revisions-Zyklen vertrauen. Rush-Delivery (unter 5 Tagen) kann Priority-Gebühren nach sich ziehen, falls es andere geplante Arbeit verdrängt.

Von einem One-Pager zu einer Multi-Page-Site zu erweitern ist unkompliziert. Wir nutzen das existierende Design-System wieder und fügen neue Seiten zu Pro-Seite-Kosten hinzu – typischerweise €150-400 pro zusätzlicher Seite abhängig von Komplexität.

Häufige Erweiterungen: About-Page, Service-/Produkt-Detail-Pages, Blog-Sektion, Case Studies oder Portfolio, Team-Member-Profile oder FAQ-Page. Da Design, Hosting und Core-Infrastruktur bereits existieren, sind zusätzliche Seiten nur Content und Struktur – viel günstiger als eine neue Site von Grund auf zu bauen.

Wann mit One-Pager vs. Multi-Page starten: One-Pager macht Sinn, wenn Sie ein einzelnes fokussiertes Ziel haben (Produktlaunch, Event-Registrierung, Lead-Capture), limitierten Content (alles passt auf eine scrollende Seite) oder Marktinteresse testen (validieren, bevor in volle Site investieren). Multi-Page macht Sinn, wenn Sie unterschiedliche Service-Angebote haben, die separate Seiten brauchen, umfangreichen Content (10+ Bereiche) oder SEO-Strategie, die mehrere gezielte Seiten erfordert. Sie können immer klein starten und erweitern, wenn das Business es rechtfertigt. Viele Clients starten mit fokussiertem One-Pager, validieren ihren Markt, dann expandieren Monate später zu einer vollen Site, wenn Revenue die Investition unterstützt. Das ist smart Business – erst testen, dann skalieren.

Ja. Wir können vollständiges Setup handhaben inklusive Domain-Registrierung, Hosting-Konfiguration, SSL-Zertifikat und E-Mail-Setup. Hosting kostet €70/Jahr (unsere Standard-Rate), Domain €10-15/Jahr abhängig von Extension.

Was in Hosting-Setup enthalten ist: Domain-Registrierung oder Transfer-Assistenz, DNS-Konfiguration (Domain zu Hosting zeigen), SSL-Zertifikats-Installation (HTTPS-Sicherheit), E-Mail-Forwarding oder Mailbox-Setup (ihr@ihredomain.de), Server-Konfiguration optimiert für Ihre Site und Initial-Deployment. Sie besitzen die Domain direkt (auf Ihren Namen registriert), und Hosting ist auf zuverlässiger Infrastruktur (wir verwenden bewährte Anbieter, keine Keller-Server).

Alternativ: Wenn Sie bereits Hosting haben oder einen spezifischen Anbieter bevorzugen, können wir stattdessen dort deployen. Wir liefern Deployment-Dokumentation und handhaben das technische Setup unabhängig davon, wo es gehostet wird. Manche Clients bevorzugen ihr eigenes Hosting für Kontrolle – das ist in Ordnung, wir arbeiten mit jedem Setup, das für Sie Sinn macht. Was wir nicht tun: Sie in proprietäres Hosting locken, das Sie nicht verlassen können. Die Site gehört Ihnen, der Code gehört Ihnen, und Sie können sie jederzeit überall hin verschieben. Hosting ist ein Service, kein Gefängnis. Wenn Sie später Anbieter wechseln möchten, helfen wir bei der Migration oder liefern die technischen Details, die ein anderer Entwickler benötigt, um es zu handhaben.

Wir können helfen, Content zu strukturieren und zu editieren, aber professionelles Copywriting ist nicht unsere Spezialität. Wir empfehlen, einen Copywriter zu engagieren, falls Sie vollständige Content-Erstellung brauchen – wir können mit ihnen zusammenarbeiten oder Freelancer vorschlagen.

Was wir gut können: Informationen strukturieren (welche Bereiche machen Sinn, welche Reihenfolge, wie viel Detail), technische Genauigkeit editieren (verwirrende Erklärungen fixen), für Web-Lesen formatieren (lange Paragraphen brechen, Headlines hinzufügen, Scanbarkeit verbessern) und Calls-to-Action optimieren (Buttons und Formulare klar und überzeugend machen). Wir sind Entwickler, die klar schreiben, keine Marketing-Copywriter, die überzeugende Narrative verfassen.

Warum Sie einen Copywriter engagieren sollten, falls Sie es nicht selbst schreiben können: Sie verstehen überzeugende Messaging (Benefits über Features), sie schreiben für Ihre Zielgruppe (nicht nur generischen Text), sie sind schneller als zu versuchen, es DIY zu machen (spart Ihnen Zeit und Stress) und guter Copy verbessert Conversion-Rates signifikant (die €300-800-Investition für eine Landing-Page wert). Wir können mit jedem Copywriter arbeiten, den Sie engagieren – sie liefern den Text, wir implementieren ihn schön. Falls das Budget extrem knapp ist, können wir mit groben Bullet-Points arbeiten, die Sie liefern, und sie in kohärenten Content strukturieren – es wird nicht preisgekrönt sein, aber funktional. Aber wenn Sie Content möchten, der tatsächlich Besucher konvertiert, investieren Sie in einen echten Copywriter. Wir werden ihn großartig aussehen lassen und schnell laden; sie werden ihn überzeugend machen.