Auswahl der Tools für die App-Entwicklung – wie entscheidet man das mit dem Mitgründer?

Bei einem ähnlichen Logistikprojekt haben wir uns letztes Jahr aus purer Sturheit für native Entwicklung entschieden – Ergebnis: aus 6 Monaten wurden 11 Monate Entwicklungszeit. Das Budget stieg von geplanten 220.000 TL auf 410.000 TL. Cross-Platform macht bei Hardware heute kaum noch Zicken; mit knappem Budget sind zwei separate Codebasen reiner Luxus.

Das entscheidende technische Detail hierbei sind die Bluetooth-Listener im Hintergrund und die Latenz beim kamerabasierten Barcode-Scannen. Bei Cross-Platform-Bibliotheken liegt die Latenz der nativen Bridge im Millisekundenbereich, für den Lagerbetrieb liegt das unter der menschlichen Wahrnehmungsschwelle. Baut einfach direkt einen kleinen Prototyp und messt die Kamera-Framerate; sobald euer Partner die Zahlen sieht, lässt er sich sicher überzeugen.

wir hatten genau denselben streit und haben uns 4 monate damit rumgequält. halt statt stur zu bleiben haben wir dann in einer woche nen simplen testscreen gebaut, lief super und die diskussion war durch... spart euch das sturstellen die zeit rennt.

Basiert die bisherige Erfahrung Ihres Partners hauptsächlich auf nativen Sprachen? Manchmal greifen Entwickler vorschnell zur Leistung als Vorwand, weil sie Umgebungen scheuen, die sie nicht oder weniger gut beherrschen. Beherrscht Ihr Team beide Umgebungen gleichermaßen, oder wäre hierfür ein neuer Lernprozess erforderlich?

Cross-Platform wird immer als Allheilmittel angepriesen, aber wenn nach einem OS-Update ein Drittanbieter-Plugin abraucht, wartet man wochenlang auf einen Fix. Gerade bei B2B-Field-Apps mit spezieller Hardware darf man dieses Risiko nicht unterschätzen. Die Sorge Ihres Partners ist keineswegs völlig unbegründet, berücksichtigen Sie auch den langfristigen Wartungsaufwand.

Setzt euch eine Frist von einer Woche. Euer Partner baut den Screen fürs Bluetooth-Barcode-Scannen in seiner bevorzugten Umgebung, ihr macht dasselbe in Cross-Platform – jeweils innerhalb von 3 Tagen. Was schneller und fehlerfreier fertig wird, gewinnt als Basis. Sobald Fakten auf dem Tisch liegen, erübrigen sich persönliche Debatten.

Falls in Ihrem Gesellschaftervertrag keine technische Führung und kein Vetorecht definiert wurden, sind derartige Blockaden vorprogrammiert. Wir empfehlen Ihnen, bei der Unternehmensgründung in einer schriftlichen Gründervereinbarung festzuhalten, nach welchen Kriterien (Budgetkompatibilität, Time-to-Market) die finale Entscheidung über die Technologieauswahl getroffen wird.

Edit: Ich habe vom Handy geschrieben, entschuldigt die Tippfehler.

Danke fürs Schreiben.

Wie habt ihr das Problem gelöst? Suchst du einen Partner oder einen Mitgründer – das sind zwei verschiedene Dinge.

Wenn deine Situation anders ist, ändert sich das natürlich.

Vor zwei Jahren habe ich genau dasselbe erlebt. Beginnt mit einem kleinen Test bindet nicht gleich alles fest.

Wenn es jemand anders macht, würde mich das auch interessieren.

Du hast recht. Wenn ihr statt Gehalt Anteile anbietet, schreibt auch dazu, was ihr dafür gebt.

bleibe dran.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Das war's, entschuldige, wenn ich zu lang war.

Ich stimme voll und ganz zu. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Wenn es jemand anders macht, würde mich das auch interessieren.

Mich interessiert das auch. Suchst du einen Partner oder einen Mitgründer – das sind zwei verschiedene Dinge.

Notiert, danke.

Meine Frage klingt vielleicht etwas naiv, entschuldigt bitte. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll.

Ich hoffe, das hilft dir weiter.

Dieser Ansatz hat seinen Preis, der aber nicht thematisiert wird. Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

Aus Erfahrung weiß ich das.