App mit Gratis-Tool selbst designt — an die Agentur übergeben oder komplett neu bauen lassen?

Code aus kostenlosen Tools ist fast immer Spaghetti-Code: vollgestopft mit unnötigen Libraries und extrem speicherhungrig. Wenn die App frühmorgens abschmiert, während die Gastronomen ihre Bestellungen durchdrücken wollen, bist du deine Kunden los. Nimm dein Design als Vorlage, aber lass den Code sauber schreiben.

Wenn du Angebote prüfst, bestehe knallhart auf drei Punkten: 1) Der Source Code gehört ab Tag 1 komplett dir, 2) der Store-Approval-Prozess bei Apple und Google ist im Festpreis enthalten, 3) mindestens drei Monate kostenloser Bugfix-Support nach dem Release.

Wenn der Kollege für 12.000 SAR nach zwei Monaten nicht mehr ans Handy geht, wirst du verstehen, warum die Agentur 40.000 SAR wollte. Wer bei Software billig kauft, kauft immer zweimal.

Mach Screenshots von jedem einzelnen Screen deines Prototyps und pack den Ablaufplan in ein PDF. Schick das als technisches Lastenheft an die Agenturen. So nimmst du ihnen von vornherein den Wind aus den Segeln, wenn sie später mit angeblichen Zusatzaufwänden kommen.

Wir haben in Dschidda eine ähnliche B2B-Logistik-App entwickeln lassen. Weil wir einen fertigen Prototyp mitgebracht haben, ist die Agentur von 55.000 SAR auf 34.000 SAR runtergegangen, da die Konzeptionsphase fast komplett wegfiel. Dein Prototyp ist ein verdammt gutes Verhandlungsargument.

Nach der Gesetzgebung des saudischen Handelsministeriums muss in Softwareverträgen das Eigentum am Quellcode ausdrücklich festgehalten werden. Andernfalls kann der Code als geistiges Eigentum der Agentur gelten. Welches Angebot du auch wählst, lass vertraglich festhalten, dass der Zugang zum Code-Repository auf den Namen deiner Firma läuft.

Brauchen Restaurants wirklich eine mobile App? Würde ein mobil optimiertes Web-Panel für Benachrichtigungen und Abrechnung am Anfang nicht ausreichen? Hast du die Store-Kommissionen und die Kosten für das jährliche Entwicklerkonto mit einkalkuliert?

Gut dass du diesen Thread eröffnet hast. Zwei Wochen Notizen machen liefert bessere Ergebnisse als eine sechsmonatige Schätzung.

An deiner Stelle würde ich so vorgehen.

Das wusste ich nicht.

Ich stimme zu, möchte das sogar besonders betonen. Der Zahlungsplan sollte an die Projektphasen gekoppelt sein, nicht an den Kalender.

Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht. Nur als Notiz, könnte nützlich sein.

mich interessiert das auch.

Gespeichert. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt.

Da ist mir noch ein Punkt unklar. Wenn du das nicht von Anfang an schriftlich festhältst gibt es später Streit.

Wenn keine Abnahmekriterien definiert sind, ist der Abschlusszeitpunkt des Projekts diskussionswürdig. Viel Erfolg.

Da stimme ich zu. Code ohne Installationsanleitung gehört dir nicht, auch wenn du ihn in den Händen hältst.

Gut, dass du diesen Thread eröffnet hast.

Ich würde sagen, lass uns nichts überstürzen. übrigens ein Change-Request-Prozess verlangsamt die Arbeit nicht, sondern beschleunigt sie.

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

Ich fasse das Thema mal zusammen, da es mehrere unterschiedliche Antworten gab. Ein wöchentlicher schriftlicher Fortschrittsbericht ist viel nützlicher als ständiges Nachfragen nach dem Status.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Wie habt ihr das Problem gelöst? Ein Change-Request-Prozess verlangsamt die Arbeit nicht sondern beschleunigt sie.

Je schwerer es ist, eine Entscheidung rückgängig zu machen, desto langsamer solltet ihr sie treffen. Ich hoffe, das hilft dir weiter.