Häufig gestellte Fragen

Individuelle Entwicklung ist dort sinnvoll, wo es eine einzigartige Logik, spezifische Integrationen oder Anforderungen gibt, die kein fertiges Produkt ohne erhebliche Kompromisse abdecken kann.

Wenn die Aufgabe mit einem vorhandenen Tool gelöst werden kann, das 80% der Anforderungen abdeckt — sagen wir das gleich zu Beginn. Aber wenn das Unternehmen Standardlösungen bereits entwachsen ist oder etwas Außergewöhnliches aufbaut, bietet individuelle Entwicklung volle Kontrolle: Logik, Rollen, Integrationen, Berichte — alles nach Ihren konkreten Anforderungen.

Eine fertige Plattform ist ein schneller Start innerhalb dessen, was sie vorsieht. Solange das Unternehmen in diese Grenzen passt, funktioniert alles. Aber sobald nicht standardmäßige Prozesse, spezifische Logik oder der Bedarf an tiefen Integrationen auftauchen, beginnen Umwege, Plugins und ständige Einschränkungen.

Eine individuelle Lösung wird für Sie gebaut: Sie skaliert mit dem Unternehmen, lässt sich mit beliebigen Services integrieren und ist nicht von den Entscheidungen einer Drittplattform über API- oder Richtlinienänderungen abhängig.

Meist sind das entweder Werkzeuge für die interne Arbeit eines Unternehmens oder Produkte, mit denen Kunden oder Partner interagieren. Zur ersten Gruppe gehören Managementsysteme, Buchhaltungsplattformen und Integrationslösungen zwischen bestehenden Services. Zur zweiten — Web- und Mobile-Apps, Partnerportale, E-Commerce. Oft ist das eine mit dem anderen verflochten: zum Beispiel eine Plattform für Distributoren, die intern mit ERP und Analytik verbunden ist. Der konkrete Umfang hängt immer davon ab, welcher Prozess gelöst werden muss.

Von Komplexität und Umfang. Manchmal lässt sich ein MVP in einem Monat zusammenstellen, ein vollwertiges System in einigen Monaten. Wenn eine tiefe Integration oder die Entwicklung komplexer Analytik von Grund auf erforderlich ist, sind die Fristen länger. Die Entwicklung wird immer in Phasen aufgeteilt, und die ersten Ergebnisse erscheinen, bevor das Projekt vollständig abgeschlossen ist.

Wir beginnen mit der Discovery-Phase. Hier klären wir gemeinsam die eigentliche Aufgabe, die Einschränkungen und die Erfolgskriterien. Das ist der Punkt, an dem wir prüfen, ob die Aufgabe richtig formuliert ist, bevor wir mit ihrer Lösung beginnen.

Danach verläuft die Entwicklung in Iterationen mit einem konkreten Ergebnis in jeder Phase. Sie sehen Berichte, geben Feedback, und die nächste Etappe berücksichtigt Ihre Anmerkungen. So entsteht die Lösung Schritt für Schritt, und Sie haben die Möglichkeit, sie im Prozess zu beeinflussen.

Tägliches Eintauchen ist nicht nötig, aber sich vollständig zurückzuziehen funktioniert auch nicht. Zu Beginn ist es wichtig, den Kontext sauber zu übergeben und Schlüsselfragen zu beantworten. Danach müssen Sie von Zeit zu Zeit Prioritätsentscheidungen treffen, Demos und Berichte ansehen und Feedback geben. Je klarer die Kommunikation in jeder Phase, desto weniger Korrekturen und Missverständnisse am Ende.

Für jedes Projekt gibt es einen dedizierten Manager, der für die Kommunikation mit dem Team, Deadlines, Koordination und Updates für den Kunden verantwortlich ist. Sie sprechen mit einer Person, die den Projektstand besser kennt als jeder andere. Die Methodik wählen wir je nach Kontext: Scrum, Kanban oder ein Hybrid, wenn Sie bereits eigene interne Prozesse haben, an die wir uns anpassen müssen.

Bei T&M fügen sich neue Prioritäten einfach in den nächsten Zyklus ein. Beim Festpreisbudget ist es komplizierter, aber steuerbar: Wir setzen uns zusammen, betrachten den aktuellen Umfang und entscheiden, was jetzt wichtiger ist und was verschoben werden kann. Entscheidend ist, dass keine Entscheidung ohne Ihre Beteiligung getroffen wird. Alles ist transparent, und Sie wissen immer, was sich geändert hat und warum.

Der QA-Ingenieur arbeitet im selben Team und wird bei jeder Funktion einbezogen. Manuelles Testing deckt Szenarien ab, in denen Logik und Nutzererlebnis wichtig sind. Automatisierung kommt dort zum Einsatz, wo regelmäßig dasselbe geprüft werden muss — ohne Fehler durch den menschlichen Faktor.

Separat testen wir Last, Sicherheit und Grenzfälle. Vor dem Release durchläuft der Kunde einen finalen Abnahmetest am Live-System. Das ist eine vollwertige Prüfung dessen, was gelauncht wird.

In der Backend-Entwicklung arbeiten wir mit PHP (Phalcon, Yii2), Java und Symfony, für Integrationen — REST API und GraphQL. Das Frontend bauen wir meist mit Vue.js, für das Content-Management nutzen wir PIMCore, mobile Lösungen — Swift und Kotlin. All das haben wir in konkreten Projekten für Einzelhandel, E-Commerce, den öffentlichen Sektor, Medien und Produktion eingesetzt.

Der Stack wird immer für die Aufgabe ausgewählt. In einem Projekt steht Performance im Vordergrund, in einem anderen die Flexibilität der Integrationen, im dritten die Skalierbarkeit. Und wir erklären dem Kunden immer, warum wir genau dieses Toolset vorschlagen.

Wir haben Produkte an CRM, ERP, Lagersysteme, Marketingplattformen, Zahlungs-Gateways, E-Mail-Dienste, staatliche APIs und Marktplätze angebunden. Wenn ein System eine offene API hat, verbinden wir uns direkt. Wenn nicht, suchen wir einen anderen Weg: Parser, Proxys, individuelle Konnektoren. Entscheidend ist, dass das Ergebnis in der realen Betriebsumgebung funktioniert.

Code, Dokumentation und Infrastruktur gehen nach der Zahlung vollständig an Sie über. Wir übergeben alles in Ihr Git oder ein anderes System Ihrer Wahl. Keine geschlossenen Module oder versteckten Abhängigkeiten, durch die Sie an uns gebunden wären. Möchten Sie den Dienstleister wechseln oder das Produkt mit eigenem Team weiterentwickeln — keinerlei Hindernisse.

Der Code durchläuft mehrere Prüfebenen, manuelles oder automatisiertes Testing sowie Performance- und Sicherheitschecks. Aber noch wichtiger ist die Konzeptionsphase. Wenn eine Funktion schlecht durchdacht ist oder logisch dem Rest des Systems widerspricht, gelangt sie nicht in die Entwicklung. Architekturentscheidungen nach dem Release zu korrigieren ist weitaus teurer, als zu Beginn die richtigen Fragen zu stellen.

Die Dokumentation schreiben wir im Laufe der Entwicklung. In der Regel sind das eine technische Dokumentation mit Beschreibung der Architektur, Datenstrukturen und API, Anleitungen für Benutzer oder Administratoren sowie eine Wissensdatenbank oder ein Glossar für das Team des Kunden. Das konkrete Format stimmen wir auf Ihre Bedürfnisse ab — je nachdem, wer künftig damit arbeitet.

Die ersten Wochen nach dem Launch sind die aktivste Phase. In der Produktion zeigt sich immer das, was im Test nicht sichtbar ist: Verhalten unter realer Last, untypische Nutzerszenarien, kleine Präzisierungen in der Logik. Wir bleiben in der Nähe, um auf all das schnell zu reagieren. Nach der Stabilisierung übergeben wir das Produkt entweder mit vollständiger Dokumentation an Ihr Team oder gehen in ein langfristiges Support-Format über.

Vom minimalen Monitoring bis zur vollständigen technischen Betreuung — je nachdem, was benötigt wird. Kritische Projekte sichern wir mit einem SLA mit klar definierten Reaktionszeiten ab. Für weniger kritische bieten wir ein flexibles Format nach Vereinbarung. Der Support umfasst Bugfixing, Bibliotheks-Updates, Sicherheit und Optimierung.

Wenn die Architektur mit Blick auf Wachstum entworfen wurde — ja, und genau so bauen wir sie. Neue Module, steigende Last, zusätzliche Integrationen — all das wird auf der Ebene von Entscheidungen verankert, die noch vor der ersten Codezeile getroffen werden. Wir haben Fälle, in denen ein in wenigen Wochen erstelltes MVP zu einer vollwertigen Plattform gewachsen ist, ohne dass das System von Grund auf neu geschrieben werden musste.

Der Stillstand von Geschäftsprozessen durch einen Bug kostet weitaus mehr als eine schnelle Behebung. Deshalb reagieren wir im ersten Monat nach dem Launch maximal schnell. Danach läuft der Support nach einem vereinbarten Zeitplan oder auf Anfrage. Wenn nach uns jemand Änderungen am System vorgenommen hat, klären wir zunächst, was und wo sich geändert hat, und entscheiden dann, wie es zu beheben ist.