Häufige Fragen
Häufig gestellte Fragen
Alles, was uns zu Softwareentwicklung, mobilen Apps und digitalen Projekten gefragt wird — Ablauf, Technologiewahl, Sicherheit und Budget.
01Projektablauf
Eine Unternehmenswebsite dauert 2–4 Wochen, eine E-Commerce-Plattform 6–8 Wochen, eine mobile App 8–12 Wochen und ein System mit KI-Integration 3–6 Monate. Den Zeitplan bestimmt die Zahl der Integrationen, nicht die der Screens: Zahlung, Identität, Buchhaltung und Unternehmensanbindungen bringen je eigene Testlast. Einen verbindlichen Terminplan geben wir nach der Analyse im ersten Gespräch.
Eine Website gewinnt, wenn Kundinnen Sie über die Suche finden; eine App gewinnt, wenn dieselben Menschen mehrmals pro Woche zurückkehren. Die Website ist stärker bei Reichweite und Sichtbarkeit, die App bei Bindung und Rückholung per Benachrichtigung. Als Faustregel: zuerst die Website — die App lohnt die Investition, sobald wiederkehrende Nutzung messbar ist.
Ja. Ein MVP ist keine kleinere Fassung der ganzen Idee, sondern die erste Version mit genau der Annahme, die es zu prüfen lohnt. Den Umfang grenzen wir gemeinsam ein: ohne welchen Screen das Produkt nicht funktioniert und welcher auf Version zwei warten kann. Ein typisches MVP geht in 6–10 Wochen live, und mit den ersten Nutzerdaten wird die Roadmap gemessen statt geraten.
Ja, und meist ohne Abschaltung. Die neue Version wird vor die alte gesetzt, der Verkehr wandert zunächst mit einem kleinen Prozentsatz hinüber, und ein Rückweg bleibt bei jedem Schritt offen. Ihre Daten, Nutzerkonten und Suchrankings bleiben erhalten, alte URLs werden per dauerhafter Weiterleitung an die neuen gebunden. Wir beginnen mit Messen, nicht mit Codelesen.
Alle zwei Wochen öffnen und testen Sie den lauffähigen Build selbst in einer Testumgebung — das echte Produkt, keine Screenshots. Zum Zyklusende schicken wir schriftlich, was fertig ist, was nicht und was bei Ihnen liegt. Für Zwischenfragen gibt es einen gemeinsamen Kanal. Was eine Entscheidung blockiert, kommt sofort auf den Tisch und nicht erst zum Zyklusende.
Ja, und die Entscheidungspunkte stehen vorab fest. Zuerst besprechen wir den Ablauf an Wireframes, dann zeigen wir zwei unterschiedliche gestalterische Richtungen, und die gewählte wird zum Designsystem. Feedback sammeln wir gebündelt und halten es schriftlich fest; ein freigegebener Screen geht in den Code. Diese Reihenfolge nimmt Designänderungen nach Entwicklungsbeginn ihre Kosten.
Ja — ein erheblicher Teil unserer Projekte läuft so. Wir arbeiten in Ihrem Repository, Ihrem Release-Prozess und Ihrem Meeting-Rhythmus; ein separates Lieferpaket entsteht nicht. Der Grund ist die Übergabequalität, nicht das Tempo: Ein separat arbeitendes Team hinterlässt eine Codebasis, ein gemeinsam arbeitendes die Gewohnheit, sie zu betreiben. Die Rollenaufteilung wird in der ersten Woche schriftlich geklärt.
02Technologie
Im Web Next.js, React und TypeScript; im Backend Node.js, Go und .NET; bei Daten PostgreSQL und MySQL; mobil React Native, Flutter und bei Bedarf Swift/Kotlin. Die Technologiewahl treffen wir nicht nach Mode, sondern nach drei Kriterien: dem Stack, den Ihr Team pflegen kann, dem realen Lastprofil und den Gesamtkosten über fünf Jahre.
Ja, aus einer Codebasis. Eine mit React Native oder Flutter geschriebene App erscheint in beiden Stores, ohne zweites Team und zweite Wartungsrechnung. Für hardwarenahe Module — Kameraverarbeitung, Hintergrundortung, aufwendige Grafik — wechseln wir zu Swift oder Kotlin und binden dieses Modul per Bridge ein; die Wahl ist also nicht entweder-oder, sondern das richtige Werkzeug an der richtigen Stelle.
Wir arbeiten in achtzehn Branchen: Bankwesen, Versicherung, Zahlungsverkehr, Handel, Gesundheit, Pharma, Logistik, Fertigung, Automotive, Energie, Telekommunikation, öffentlicher Sektor, Bildung, Tourismus, Immobilien, Medien, Technologie und Agrar/Lebensmittel. Über die Eignung entscheidet nicht die Branche, sondern die Form des Prozesses: Er muss sich häufig wiederholen, ein messbares Ergebnis haben und bereits Daten erzeugen.
Ja. Lokal binden wir iyzico, PayTR und PayU an, global Stripe und PayPal, inklusive 3-D Secure und Ratenzahlung. Kartendaten gelangen nie in Ihren Shop — die Zahlungsseite liegt beim Anbieter, die Karte wird durch ein Token repräsentiert. Das senkt den PCI-DSS-Aufwand deutlich, und Rückerstattungen, Stornierungen und Abstimmung liegen in einer einzigen Transaktionshistorie.
Technisch brauchen Sie vier Dinge: eine Domain, einen Vertrag mit einem Zahlungsanbieter, eine Versandanbindung und Produktdaten. In der Praxis bremst das vierte: Ein Katalog mit fehlenden Fotos, Beschreibungen oder Varianten geht nicht live. Rechtlich brauchen Sie Fernabsatzbedingungen, eine Widerrufsregelung und eine Datenschutzerklärung. Liegt all das vor, ist ein Start in 6–8 Wochen realistisch.
Ja, wir steuern den gesamten Release: Entwicklerkonto, Store-Texte, Screenshots, Datenschutz-Labels und Antworten im Review. Die meisten Ablehnungen stammen aus Richtlinien, nicht aus Code — fehlender Kontolöschungs-Flow, unbegründete Berechtigungsabfrage, Datenschutz-Labels, die nicht zum tatsächlichen Verhalten passen. Diese Punkte stehen bei uns auf der Pre-Release-Checkliste.
Ja, und wir zielen auf zwei Motoren zugleich. Für die klassische Suche bauen wir technisches Fundament, Geschwindigkeit, strukturierte Daten und Content-Architektur. Für generative Engines werden Seiten so geschrieben, dass ChatGPT, Perplexity und Gemini sie zitieren können: Jede Seite beantwortet eine konkrete Frage, die Antwort steht im ersten Absatz, und Aussagen sind mit Quellen belegt. Diese Website ist genauso gebaut.
Ja — wir richten ein, die Konten laufen aber auf Ihren Namen. Wir arbeiten auf AWS, Google Cloud und DigitalOcean, inklusive Domain, SSL-Zertifikat und E-Mail-Konfiguration. Dass das Konto Ihnen gehört, ist kein Detail, sondern eine Absicherung: Wenn Sie den Dienstleister wechseln, hängt der Zugang zu Ihrer Infrastruktur nie von der Zustimmung eines anderen ab.
Ja. Jede Website kommt mit einem Redaktionsbereich: Beiträge und Seiten anlegen, Bilder tauschen, Menüs bearbeiten und SEO-Felder ausfüllen erfordern kein technisches Wissen. Bei der Übergabe schulen wir Ihr Team live und hinterlassen kurze Bildschirmaufnahmen sowie eine schriftliche Dokumentation. Was die Struktur ändert — ein neuer Seitentyp, eine neue Integration — bleibt bei uns.
03Sicherheit und Rechte
Ihnen. Mit Lieferung und Schlusszahlung gehen Quellcode, Designdateien, Infrastrukturdefinitionen und sämtliche Rechte vollständig über. Da Repositories, Secrets und Cloud-Konten von Anfang an auf Ihren Namen laufen, ist die Übergabe keine Dateiübergabe, sondern die Schlüsselübergabe an ein System, das bereits Ihnen gehört. Abgeschlossen ist der Prozess erst, wenn Ihr Team die Deployment-Pipeline selbst betreibt.
Zuerst wird der Scope verkleinert: Gelangen Kartendaten nie ins System, gibt es auch keine zu schützen. Für den Rest greifen Netzsegmentierung, Ende-zu-Ende-Verschlüsselung, Tokenisierung, Zwei-Faktor-Authentifizierung, unveränderliche Zugriffsprotokolle und regelmäßige Penetrationstests — alle den PCI-DSS-Anforderungen zugeordnet. Umgebungen sind isoliert, und Produktionsdaten werden nie in Testumgebungen kopiert.
Ihre Daten werden nicht zum Modelltraining genutzt: Die Nutzung zu Trainingszwecken wird in den Anbieterverträgen deaktiviert und schriftlich festgehalten. Daten werden verschlüsselt gespeichert und verarbeitet, der Zugriff ist rollenbasiert, und vor Projektbeginn wird eine Geheimhaltungsvereinbarung unterzeichnet. Wo Vertraulichkeit es erfordert, läuft das Modell bei Ihnen oder in Ihrem Cloud-Konto — dann verlässt keine Anfrage Ihr Netz.
Das ist eine Architekturentscheidung und fällt vor Projektbeginn. Wir halten Daten nur in der von Ihnen bestimmten Region; muss sie in der Türkei bleiben, wird eine lokale Region oder eine On-Premises-Installation gewählt. Werden personenbezogene Daten ins Ausland übermittelt, stehen die Voraussetzungen des Gesetzes 6698 und die nötigen Verpflichtungen in der Projektdokumentation — nachträglich löst sich das nicht.
Ja. Websites erhalten einen Monat, mobile Apps zwei Monate kostenlosen Support; in dieser Zeit werden Fehler ohne Zusatzkosten behoben. Danach schließen wir einen Wartungsvertrag mit schriftlich festgelegtem Umfang: Reaktionszeit, Fehlerpriorität und Anzahl der Releases pro Monat. Für Betriebssystem- und Store-Richtlinienänderungen führen wir zudem einen geplanten Release-Kalender.
04Budget und Zahlung
Vier Dinge bestimmen den Preis: Umfang, Zahl der Integrationen, Individualität des Designs und Dauer. Die Zahl der Screens wiegt weniger, als man denkt; das Gewicht bringen Zahlungs-, Identitäts-, Buchhaltungs- und Unternehmensanbindungen. Wir hören uns im ersten Gespräch die Anforderung an, analysieren und erstellen ein positionsweise aufgeschlüsseltes Angebot — inklusive dessen, was nicht im Umfang liegt.
Ein fertiges Lastenheft ist nicht nötig. Drei Dinge genügen: eine Beschreibung des Problems in einem Absatz, eine Liste der anzubindenden Systeme (Buchhaltung, Kasse, Versand, CRM) und, falls vorhanden, ein Zieltermin. Zwei Beispielprodukte, die Ihnen gefallen, beschleunigen es spürbar. Damit erstellen wir das erste Angebot in der Regel innerhalb weniger Werktage.
Die Zahlung wird üblicherweise in drei Stufen geteilt: 40 % zum Start, 30 % bei Design-Freigabe, 30 % bei Auslieferung. Längere Projekte erhalten mehr Stufen, und jede Stufe hängt an einem gelieferten Ergebnis, nicht am Kalender. Wir akzeptieren Karte, Überweisung und Scheck und stellen Unternehmen direkt eine Rechnung. Ändert sich der Umfang, wird die Differenz vor Arbeitsbeginn schriftlich freigegeben.
Die erste Phase ist kostenfrei: ein Monat für Websites, zwei Monate für mobile Apps. In diesem Fenster gefundene Fehler gehören zur Lieferung und kosten nichts extra. Danach ist die Wartung eine eigene Vereinbarung mit schriftlichem Umfang — Reaktionszeit, Fehlerpriorität, Releases pro Monat. Neue Funktionen bleiben von der Wartung getrennt; beides in einer Position zu führen verwischt die Erwartung.
Vier Fragen klären den Großteil der Entscheidung: Wem gehören Quellcode und Konten nach der Lieferung, was ist als nicht im Umfang festgehalten, wie groß ist das Team und wer gehört dazu, und wie wird die Wartung bepreist. Statt Portfolio-Screenshots verlangen Sie ein heute noch laufendes Produkt und sprechen Sie mit dessen Kunden. Wer nicht schriftlich antwortet, führt auch das Projekt nicht schriftlich.
Ihre Frage ist nicht dabei?
Fragen Sie direkt — jemand aus dem technischen Team antwortet innerhalb eines Werktags.