Angebot für eine App richtig bewerten: 15 Fragen an Ihren Entwickler

Liegen zwei oder drei Angebote vor Ihnen, hat Sie der Unterschied vermutlich überrascht. Ein Angebot kostet zum Beispiel ein Vielfaches des anderen. Zudem umfasst eines zwei Seiten, das nächste zwanzig. Allerdings beschreiben zwei Angebote selten dieselbe Arbeit. Das eine kalkuliert nur die sichtbare App, das andere auch Server, Verwaltungsoberfläche, Store Prozess und ein Jahr Wartung.

Deshalb haben wir, Talha Aslan und Team, diesen Leitfaden als Checkliste aufgebaut. Am Ende können Sie:

• Fehlende Abschnitte in einem Angebot in wenigen Minuten erkennen.
• Die 15 Fragen an den Entwickler in einer Tabelle sammeln.
• Verstehen, wo ein sehr günstiges Angebot spart.
• Zwei Angebote nach denselben Kriterien bewerten und entscheiden.

Welche Faktoren den Preis bestimmen, erklären wir in einem eigenen Beitrag. Wenn Sie wissen möchten, warum die Zahlen so stark schwanken, lesen Sie was die Kosten der App Entwicklung bestimmt. Dieser Leitfaden konzentriert sich dagegen auf das Dokument, das Sie bereits in der Hand halten.

Welche Bestandteile gehören in jedes Angebot für eine App?

Ein gutes Angebot funktioniert wie ein Vertragsentwurf: Es zeigt, dass beide Seiten dasselbe verstehen. Fehlt also einer der folgenden Abschnitte, kommt die Lücke später meist als Nachtragsrechnung oder Streit zurück.

• Leistungsbeschreibung: was die App tun soll und was ausdrücklich nicht.
• Screenliste: jeder Screen mit Namen und den Aktionen, die Nutzer dort ausführen.
• Plattformen: iOS, Android oder beide, dazu die älteste unterstützte Systemversion.
• Verwaltungsoberfläche und Server: wer Inhalte, Nutzer und Bestellungen pflegt und wie.
• Store Veröffentlichung: wer die Einreichung bei App Store und Google Play übernimmt.
• Tests: welche Geräte, welche Szenarien, wie viele Runden.
• Wartung: Fehlerbehebung und Systemkompatibilität nach dem Start.
• Quellcode: wie Code und Konten an Sie gehen.
• Zahlungsplan: was Sie in welcher Phase zahlen.

In unseren Angeboten zur App Entwicklung stehen diese neun Punkte zum Beispiel einzeln aufgeführt. Denn wenn wir die App entwickeln und auch in die Stores bringen, muss klar sein, wo unsere Verantwortung beginnt und endet. Haken Sie die Punkte in Ihrem Angebot ab. Was fehlt, ist dann Ihre erste Frage an den Entwickler.

Welche 15 Fragen sollten Sie einem App Entwickler stellen?

Die folgende Tabelle können Sie ausdrucken und für jedes Angebot getrennt ausfüllen. So sehen Sie die Antworten "ja", "nein" und "unklar" nebeneinander.

Im Folgenden gehen wir die Fragen in Gruppen durch und zeigen, wie eine gute Antwort jeweils aussieht.

Warum ist die Leistungsbeschreibung die Grundlage des Angebots?

Die Leistungsbeschreibung, also die schriftliche Definition der Arbeit, ist die einzige Stelle, die zeigt, wofür Sie bezahlen. Eine Zeile wie "Registrierung, Produktliste, Warenkorb und Zahlung" genügt nicht. Melden sich Nutzer per E-Mail, Telefon oder Social Login an? Gibt es Passwort zurücksetzen, Konto löschen und Profil bearbeiten? Jeder Punkt ist ein eigener Screen und daher eine eigene Aufgabe.

Frage 1: "Können Sie mir den Umfang Punkt für Punkt schriftlich geben?" Eine gute Antwort enthält also eine Funktionsliste mit kurzer Erklärung je Funktion. Außerdem bietet sie an, den Umfang gemeinsam mit Ihnen zu schärfen.

Frage 2: "Welche Aufgaben liegen außerhalb des Umfangs?" Diese Frage ist oft wertvoller als die erste, weil sie Lücken sichtbar macht. Sind zum Beispiel Mehrsprachigkeit, Dark Mode, Livechat oder Offlinebetrieb nicht enthalten, verhindert ein schriftlicher Hinweis später die Diskussion "Ich dachte, das sei dabei".

Der kürzeste Weg zu einem klaren Umfang ist eine kleine erste Version. Unser Leitfaden was ein Mobile App MVP ist und welche Funktionen zuerst kommen zeigt, welche Funktionen warten können.

Wie sollten Screenliste und Nutzerfluss im Angebot aussehen?

Frage 3: "Können Sie mir Screenliste und Nutzerfluss zeigen?" Die Screenliste nennt zunächst jede Seite der App mit ihrem Zweck. Der Nutzerfluss ist dagegen eine einfache Skizze, die zeigt, welche Screens eine Person vom Öffnen der App bis zur abgeschlossenen Bestellung durchläuft.

In der Praxis erklären diese beiden Dokumente den Unterschied zwischen Angeboten schneller als alles andere. Beispielszenario: Ein Angebot zählt 14 Screens, ein anderes 32. Das scheinbar teure Angebot berücksichtigt womöglich auch Fehlerseiten, leere Zustände, Benachrichtigungseinstellungen und das Löschen des Kontos.

Achten Sie in der Screenliste auf diese Details:

• Login, Registrierung, Passwort zurücksetzen und Konto löschen.
• Leere Listen, Verbindungsfehler und Ladezustände.
• Abfrage der Benachrichtigungen und weitere Berechtigungen.
• Einstellungen, Datenschutztext und Kontaktseite.

Fragen Sie zudem, ob eine Designdatei zum Lieferumfang gehört, also Screenentwürfe aus einem Designtool wie Figma. Ohne Design ändern sich Screens während der Programmierung, und folglich wächst der Zeitplan.

iOS, Android oder beides: Wie fragen Sie nach den Plattformen?

Frage 4: "Für welche Plattformen und mit welcher Technik entwickeln Sie?" Die Antwort verändert nämlich Kosten und Wartungsaufwand direkt, denn sie bestimmt die Zahl der Codebasen. Native Entwicklung bedeutet zwei getrennte Apps, je eine für iOS und Android, jeweils mit den Werkzeugen der Plattform. Ein plattformübergreifender Ansatz erzeugt dagegen beide Apps aus einer gemeinsamen Codebasis.

Beide Ansätze haben ihre Berechtigung, weil Projekte verschieden sind. Steht im Angebot allerdings nur "iOS und Android", können Sie erst vergleichen, wenn Sie wissen, ob eine Codebasis oder zwei Projekte gemeint sind. Eine verbreitete Technik für den gemeinsamen Ansatz erklären wir in was React Native ist.

Fragen Sie außerdem nach der ältesten Systemversion, die die App unterstützen soll, und nach Tabletunterstützung. Ältere Geräte erhöhen den Testaufwand, und ein Tabletlayout braucht ein eigenes Design. Fehlen beide Zeilen im Angebot, gehen Sie davon aus, dass beides nicht enthalten ist.

Enthält das Angebot Verwaltungsoberfläche und Serverseite?

Frage 5: "Ist eine Verwaltungsoberfläche im Preis enthalten?" Zunächst muss jemand die Produkte, Aktionen oder Termine pflegen, die Nutzer in der App sehen. Die meisten Projekte brauchen dafür eine webbasierte Verwaltungsoberfläche. Manche Angebote erwähnen sie gar nicht, denn sie gehen davon aus, dass jemand Daten direkt in die Datenbank schreibt.

Frage 6: "Wem gehören Server, Datenbank und Hosting, und wer zahlt die monatlichen Kosten?" Die App läuft zwar auf dem Handy, holt ihre Daten aber von einem Server, denn dort liegen Produkte und Konten. Die Verbindung zwischen beiden heißt API; das Konzept erklären wir in was eine API ist. Serversoftware, Hosting und Drittdienste wie Pushbenachrichtigungen, Karten oder E-Mail gehören jeweils in eine eigene Zeile.

Beispielszenario: Ein günstiges Angebot umfasst nur die Handyapp und beschreibt die Serverseite mit "Anbindung an Ihr bestehendes System". Das Unternehmen hat allerdings kein System, das die App beliefern könnte. Damit liegt die Hälfte der echten Arbeit außerhalb des Angebots. Vergleichen Sie deshalb keine Endsummen, bevor Sie die Zeilen zu Verwaltung und Server gesehen haben.

Deckt Ihr Angebot für eine App die Veröffentlichung im Store ab?

Frage 7: "Wer veröffentlicht die App im App Store und bei Google Play, und auf wessen Namen eröffnen Sie die Konten?" Manches Angebot für eine App endet mit "Übergabe der App". Übergabe und Veröffentlichung sind allerdings nicht dasselbe. Zur Veröffentlichung gehören Entwicklerkonto, Storetexte, Screenshots, Datenschutzangaben und das Prüfverfahren.

Entwicklerkonten auf den Namen Ihres Unternehmens schützen Sie langfristig, weil Sie die Kontrolle behalten. Apple verlangt von Organisationen bei der Anmeldung eine DUNS Nummer, wie die Anmeldeseite des Apple Developer Program erklärt. Google Play verlangt die DUNS Nummer ebenso für Organisationskonten und schreibt für manche App Arten, etwa Finanz oder Gesundheitsapps, ein Organisationskonto vor. Die Kontotypen vergleichen Sie auf der Hilfeseite der Play Console zu Kontotypen.

Zudem verlangt Google Play von neuen privaten Entwicklerkonten einen geschlossenen Test mit einer festgelegten Zahl von Testern über einen festgelegten Zeitraum, bevor sie den Produktionszugang beantragen können. Prüfen Sie die aktuelle Regel auf der Hilfeseite der Play Console zu Testanforderungen und lesen Sie unsere Anleitung zum geschlossenen Test bei Google Play. Fehlt dieser Zeitraum im Plan, ist der Starttermin nicht realistisch.

Was passiert, wenn die App die Storeprüfung nicht besteht?

Frage 8: "Wer behebt eine Ablehnung durch den Store, und zu welchem Preis?" Ablehnungen gehören zum normalen Store Prozess. Entscheidend ist also, ob das Angebot damit rechnet.

Die App Store Review Guidelines nennen einige grundlegende Erwartungen. Hat Ihre App einen Login, müssen Sie dem Prüfteam Zugangsdaten für ein Demokonto geben, und Ihr Backend muss während der Prüfung erreichbar sein. Apps, die eine Kontoerstellung erlauben, müssen außerdem das Löschen des Kontos in der App ermöglichen. Zudem riskieren Apps, die nur eine Website verpacken und sich nicht wie eine App verhalten, eine Ablehnung wegen fehlender Mindestfunktionalität.

Eine gute Antwort lautet etwa: "Ablehnungsgründe zu Funktionen im Umfang beheben wir ohne Aufpreis; braucht die Korrektur eine neue Funktion, erstellen wir ein eigenes Angebot." Eine vage Antwort lautet dagegen "Das sehen wir dann". Eine typische Ablehnung behandeln wir in App Store Richtlinie 4.3 Spam Ablehnung. Fragen Sie vor allem bei Entwicklern, die mit Vorlagen arbeiten, nach diesem Risiko.

Wie sollte das Angebot den Testprozess beschreiben?

Frage 9: "Auf welchen Geräten testen Sie, wie, und wann kann ich die App selbst ausprobieren?" Steht im Angebot nur das Wort "Test", überlässt der Plan den Großteil der Tests vermutlich Ihnen.

Ein guter Testplan enthält diese Bausteine:

1. Tests auf echten Geräten mit verschiedenen Bildschirmgrößen und Systemversionen.
2. Schriftliche Testszenarien für kritische Abläufe wie Zahlung, Registrierung und Benachrichtigungen.
3. Eine Betaversion, die Sie vor dem Start auf Ihrem eigenen Handy installieren.
4. Eine gemeinsame Liste, in der jeder Fehler und sein Status sichtbar bleibt.
5. Den Abnahmetest, also die letzte Phase, in der Sie sagen: "Ich gebe frei".

Wie die Betaverteilung unter iOS funktioniert, erklären wir in was TestFlight ist. Fragen Sie außerdem schriftlich, wie lange der Abnahmetest dauert und ob das Team die dabei gefundenen Fehler kostenlos behebt.

Gehören Datenschutzangaben und Storeformulare zum Angebot?

Vor dem Start müssen Sie angeben, welche Daten die App erhebt, wofür sie diese nutzt und mit wem sie sie teilt. Google Play fragt das im Abschnitt zur Datensicherheit ab, Apple in den Datenschutzangaben der App. Diese Angaben müssen zudem zum tatsächlichen Verhalten der App passen. Sonst drohen Ablehnung oder Warnung.

Der Haken: Für korrekte Angaben brauchen Sie jemanden, der den Code kennt, weil nur er alle Bibliotheken überblickt. Eine eingebaute Analyse oder Pushbibliothek kann zum Beispiel ebenfalls Daten erheben. Sagt Ihnen der Entwickler das nicht, bleibt Ihr Formular unvollständig.

Suchen Sie deshalb im Angebot eine Zeile wie: "Für die Datenschutzformulare der Stores liefern wir die Datenliste aller eingebauten Bibliotheken." Details finden Sie in Google Play Datensicherheit Formular ausfüllen und App Store Datenschutzangaben vorbereiten. Die rechtliche Verantwortung für personenbezogene Daten liegt bei Ihnen; holen Sie daher für Datenschutzhinweise juristischen Rat ein.

Wer kümmert sich nach dem Start um Wartung und Updates?

Frage 10: "Wie läuft die Wartung nach dem Start, und bieten Sie einen Monats oder Jahresplan an?" Mit dem Start ist die Arbeit also nicht vorbei. iOS und Android erscheinen jedes Jahr in neuen Versionen, die Stores passen ihre Regeln an, und Bibliotheken veralten.

Google Play verlangt zum Beispiel, dass neue Apps und Updates ein aktuelles Android API Level ansprechen. Ältere Apps, die zurückfallen, sind für neue Nutzer auf neueren Geräten mit der Zeit nicht mehr verfügbar. Mehr dazu lesen Sie in unserem Beitrag zur Ziel API Level Anforderung von Google Play. Eine App ohne Wartungsplan ist solchen Warnungen schutzlos ausgesetzt.

Im Wartungsangebot sollten Sie getrennte Zeilen sehen: Fehlerbehebung, Systemkompatibilität, Sicherheitsupdates, Serverüberwachung und neue Funktionen. Der letzte Punkt gehört meist nicht zur Wartung. Deshalb muss die Grenze schriftlich feststehen.

Wer behält Quellcode und Konten?

Frage 11: "Übergeben Sie mir nach Projektende Quellcode, Designdateien und alle Konten?" Diese Frage überspringen Auftraggeber im Angebotsstadium am häufigsten. Trotzdem erweist sie sich oft als die teuerste.

Erhalten Sie den Quellcode nie, kann ein Wechsel des Entwicklers bedeuten, dass Sie die App neu bauen lassen. Ebenso gilt: Hat der Entwickler die Storekonten auf seinen Namen eröffnet, gehört Ihnen die App im Store nicht. Dieselbe Frage betrifft Server, Domain und jedes Konto bei Drittdiensten.

Unser Schwesterbeitrag wem der Quellcode Ihrer App gehört erklärt die Vertragsklauseln im Detail. Im Angebotsstadium verlangen Sie einfach schriftlich, in welcher Form, in welchem Repository und in welcher Phase der Code zu Ihnen kommt. Hinweis: Dieser Beitrag ist keine Rechtsberatung; prüfen Sie den Vertrag mit Ihrer Anwältin oder Ihrem Anwalt.

Wie koppeln Sie den Zahlungsplan an Meilensteine?

Frage 12: "Welche Lieferungen lösen die einzelnen Zahlungen aus?" Ein gesunder Zahlungsplan verbindet jede Zahlung mit einer konkreten, prüfbaren Lieferung. Somit tragen beide Seiten das Risiko gemeinsam.

Als Beispielszenario eignet sich diese Staffelung:

1. Eine Anzahlung bei Vertragsschluss und Freigabe des Umfangs.
2. Danach eine zweite Zahlung nach Freigabe der Designscreens.
3. Eine dritte Zahlung, sobald Sie die Testversion erhalten.
4. Die Schlusszahlung bei Store Veröffentlichung und Übergabe des Quellcodes.

Prozentsätze nennen wir hier nicht, denn sie hängen von der Projektgröße ab. Achten Sie dennoch auf zwei Signale. Erstens: Ein Plan, der den Großteil vorab verlangt, legt das gesamte Risiko auf Sie. Zweitens: Ein Plan, der die Schlusszahlung an die "Übergabe" statt an die Veröffentlichung knüpft, lässt die Verantwortung für den Store offen.

Ist der Liefertermin im Angebot realistisch?

In der Praxis ist der Liefertermin die Zeile, die sich am leichtesten schreiben und am schwersten einhalten lässt. Ein realistischer Zeitplan enthält neben der Programmierzeit auch Ihre Freigabezeiten, die Storeprüfung und die Testphase.

Suchen Sie im Zeitplan diese Punkte einzeln:

• Zeit für die Freigabe von Umfang und Design.
• Entwicklungszyklen und das lauffähige Teilstück am Ende jedes Zyklus.
• Betatest und Abnahmetest.
• Storeprüfung plus Puffer für Korrekturen nach einer möglichen Ablehnung.
• Pflichtwartezeiten, etwa der geschlossene Test bei privaten Google Play Konten.

Beispielszenario: Ein Angebot nennt nur "8 Wochen", ein anderes teilt dieselbe Arbeit in Design, Entwicklung, Test und Veröffentlichung. Das zweite wirkt länger, zeigt Ihnen aber, wo eine Verzögerung entsteht. Außerdem lässt eine einzelne Zahl offen, wer langsame Freigaben verantwortet. Koppeln Sie deshalb das Ende jeder Phase an eine konkrete Lieferung.

Wie sollten Änderungswünsche berechnet werden?

Frage 13: "Was passiert, wenn ich mitten im Projekt eine neue Funktion oder einen anderen Screen möchte?" Schließlich ändern sich Ideen in jedem Softwareprojekt. Das ist normal; das eigentliche Problem entsteht, wenn niemand vorher festlegt, wie eine Änderung zu bepreisen ist.

Ein gutes Angebot beschreibt einen Prozess für Änderungswünsche. Das heißt, das Team nimmt die neue Anforderung schriftlich auf, schätzt Zeit und Kosten und beginnt erst nach Ihrer Freigabe. Manche Teams nennen dafür einen Stunden oder Tagessatz. Folglich wird nicht jede kleine Änderung zur Verhandlung.

Fragen Sie auch, ob das Team in kurzen Zyklen arbeitet. Ein Team mit zweiwöchigen Zyklen zeigt Ihnen am Ende jedes Zyklus ein lauffähiges Teilstück und erkennt Änderungen früh. Diese Methode beschreiben wir in agiles Projektmanagement mit Scrum und Kanban.

Woran erkennen Sie, wer tatsächlich am Projekt arbeitet?

Frage 14: "Wer arbeitet am Projekt, und wie kommunizieren wir?" Eine App braucht meist Design, mobile Entwicklung, Serverentwicklung und Tests. Das Angebot sollte daher zeigen, wer welche Rolle abdeckt.

Gesucht ist hier also Transparenz, nicht eine große Mannschaft. Geht ein Teil der Arbeit an externe Partner, sollte das Angebot das offen sagen. Außerdem erleichtern eine feste Projektleitung und ein regelmäßiger Rhythmus, etwa ein wöchentlicher Statusbericht, den Überblick.

Fragen Sie auch nach Referenzapps. Schauen Sie dabei allerdings nicht nur auf Screenshots, sondern auf Apps, die live im Store sind, regelmäßig Updates bekommen und Bewertungen sammeln. Eine Live App zeigt, dass das Team auch den Store Prozess beherrscht.

Fragen Sie schließlich, was passiert, wenn jemand das Team mitten im Projekt verlässt. Ein gemeinsames Repository und kurze technische Notizen senken dieses Risiko deutlich.

Was deckt die Gewährleistung ab?

Frage 15: "Wie lange gilt die Gewährleistung nach der Übergabe, und welche Fehler deckt sie ab?" Gewährleistung bedeutet kostenlose Korrektur, wenn eine Funktion im Umfang nicht wie beschrieben läuft. Neue Funktionen, Designänderungen und Anpassungen nach einem Systemupdate fallen dagegen meist nicht darunter.

Deshalb sollte die Definition von "Fehler" im Angebot stehen. Ein Absturz im Zahlungsscreen ist zum Beispiel klar ein Fehler. Der Wunsch nach einer anderen Buttonfarbe ist dagegen ein Änderungswunsch. Fragen Sie außerdem, wie schnell das Team je Prioritätsstufe reagiert. Ein kritischer Fehler, der tagelang wartet, kostet eine verkaufende App echtes Geld.

Klären Sie zudem, wann die Gewährleistung beginnt. Manche Angebote starten sie mit der Testversion, andere mit der Store Veröffentlichung. Verschiebt sich der Start um einige Wochen, läuft im ersten Fall ein Teil der Frist ab, bevor Nutzer die App überhaupt sehen. Daher empfehlen wir als Beginn den Tag, an dem echte Nutzer die App laden können.

Welche Risiken birgt ein sehr günstiges Angebot für eine App?

Ein sehr günstiges Angebot für eine App bedeutet nicht automatisch böse Absicht. Häufiger fällt still ein Teil des Umfangs weg. Nach unserer Erfahrung aus der Praxis sparen solche Angebote vor allem an diesen Stellen:

• Eine Vorlage mit wenigen Änderungen, was das Risiko einer Storeablehnung erhöht.
• Verwaltungsoberfläche oder Serverseite fehlen komplett.
• Tests nur auf dem eigenen Handy des Entwicklers.
• Store Veröffentlichung, Kontoeinrichtung und Datenschutzformulare bleiben bei Ihnen.
• Der Quellcode bleibt beim Entwickler oder in seinem Konto.
• Kein Wartungsplan, sodass beim ersten Systemupdate Probleme auftauchen.

Kurz gesagt: Bevor Sie ein günstiges Angebot aussortieren, stellen Sie die 15 Fragen. Überzeugen die Antworten, steht hinter dem niedrigen Preis vielleicht einfach ein effizientes Team. Bleiben sie vage, kommt die Differenz später meist als Nachtragsrechnung zurück. Die Kostenfaktoren wiederholen wir hier nicht; dafür lesen Sie unseren Kostenbeitrag.

Wie vergleichen Sie zwei Angebote direkt miteinander?

Mit den Endsummen zu beginnen, ist der häufigste Fehler. Gleichen Sie stattdessen zuerst den Umfang an und schauen Sie dann auf den Preis. Wir empfehlen diese Reihenfolge:

1. Füllen Sie die Tabelle mit den 15 Fragen für jedes Angebot aus.
2. Bitten Sie bei jedem "nein" oder "unklar" um eine schriftliche Erklärung.
3. Lassen Sie fehlende Punkte vom ersten Anbieter nachkalkulieren oder vergleichen Sie mit dem zweiten Angebot.
4. Vergleichen Sie die Summen erneut, sobald der Umfang übereinstimmt.
5. Bewerten Sie schließlich Zeitplan, Zahlungsplan und Referenzen.

Beispielszenario: Angebot A liegt deutlich unter Angebot B. Allerdings fehlen in A Verwaltungsoberfläche, Store Veröffentlichung und Wartung. Lassen Sie diese Punkte von Anbieter A ergänzen, rücken die Zahlen zusammen, und A kann sogar höher liegen. So entscheiden Sie auf Basis des echten Umfangs.

Was sollten Sie vorbereiten, bevor Sie Angebote anfragen?

Ein klares Angebot hängt also von einer klaren Anfrage ab. Zudem macht dasselbe Dokument für alle Anbieter die Angebote vergleichbar.

• Der Zweck der App in einem Satz und die Zielgruppe.
• Eine kurze Liste der Pflichtfunktionen für die erste Version.
• Beispielapps, die Ihnen gefallen und die Ihnen nicht gefallen.
• Bestehende Systeme, mit denen die App sprechen soll: Website, Lager, Buchhaltung oder Zahlung.
• Ihr Wunschzeitraum für den Start und warum er wichtig ist.
• Auf wessen Namen Sie die Entwicklerkonten eröffnen, dazu Ihre Firmendaten.

Die Liste muss dabei nicht perfekt sein. Trotzdem verkleinert dieselbe Liste für alle Anbieter den Spielraum für "So hatten wir das verstanden" von Anfang an. Legen Sie außerdem ein Antwortdatum fest, damit alle Angebote in derselben Woche eintreffen.

Welche Formulierungen im Angebot sollten Sie aufhorchen lassen?

Manche Formulierungen sind für sich kein Problem. Bleiben sie unerklärt, führen sie allerdings später zu Streit. Bitten Sie bei diesen Mustern um eine schriftliche Erklärung:

• "Standardfunktionen sind enthalten", aber das Angebot zählt sie nirgends auf.
• "Wir unterstützen bei der Veröffentlichung", aber niemand sagt, wer einreicht.
• "Wartung nach Bedarf", aber ohne Stundensatz.
• "Quellcode auf Anfrage", aber ohne schriftliche Bedingungen.
• "Lieferzeit ungefähr", aber ohne Phasentermine.

Kurz gesagt zeigt jede dieser Formulierungen, dass ein Teil der Vereinbarung unbesprochen blieb. Ein Team mit guten Absichten bringt diese Punkte gern zu Papier. Ihre Fragen erleichtern ihm somit sogar die Arbeit.

Wie erstellen Talha Aslan und Team ein Angebot für eine App?

Wir schreiben jedes Angebot für eine App so, dass es die 15 Fragen dieses Leitfadens bereits beantwortet. Konkret führen wir Umfang und Ausschlüsse, Screenliste, Plattformentscheidung, Verwaltungsoberfläche und Server, Store Veröffentlichung, Testplan, Wartungsoptionen, Quellcodeübergabe und einen gestaffelten Zahlungsplan unter eigenen Überschriften auf.

Ihre App entwickeln wir und bringen sie selbst in den App Store und zu Google Play. Von Anfang an planen wir, dass die Entwicklerkonten auf Ihr Unternehmen laufen und der Code an Sie geht. Senden Sie uns eine kurze Projektbeschreibung über unsere Seite zur App Entwicklung als Leistung, dann erstellen wir Ihnen ein klares, vergleichbares Angebot. Haben Sie bereits ein anderes Angebot, legen Sie beide am besten mit denselben 15 Fragen nebeneinander.