Ein Angebot für die Entwicklung richtig lesen

Ein Entwicklungsangebot macht aus Ihrem Briefing Zusagen: was gebaut wird, bis wann, für wie viel und was passiert, wenn sich etwas ändert.

Die Faustregel ist einfach: Was nicht aufgeschrieben ist, ist nicht enthalten.

Ein guter Umfang beschreibt, was ein Nutzer tun kann, und nicht nur die Namen von Ansichten. „Nutzer können sich per E-Mail oder Google registrieren und ihr Passwort zurücksetzen“ lässt sich prüfen. „Authentifizierungsmodul“ nicht.

Achten Sie darauf, dass Nutzerrollen, zentrale Abläufe und Adminwerkzeuge getrennt aufgeführt sind. Adminbereiche vergisst man leicht im Briefing und ergänzt sie teuer.

Ein klares Angebot nennt, was nicht enthalten ist – zum Beispiel Texte, Übersetzungen, die Einreichung in App-Stores, Abogebühren für Dienste Dritter oder das Hosting nach dem Launch.

Fehlt ein Abschnitt zu Ausschlüssen, bitten Sie darum. Alles, was Sie für enthalten hielten und was es nicht war, kommt später als Änderungswunsch zurück.

Sie müssen kein Entwickler sein, aber nach dem Lesen sollten Sie diese Fragen beantworten können:

Womit wird gebaut – und warum gerade dieser Stack für Ihr Produkt?

Wem gehören der Code und die Konten: Hosting, Domain, App-Stores, Statistik?

Wo läuft das Produkt, und was kostet das nach dem Launch ungefähr pro Monat?

Wird der Code so dokumentiert, dass ein anderer Entwickler übernehmen kann?

Eine gute Agentur erklärt ihre Entscheidungen in klarer Sprache. „Das nehmen wir immer“ ist kein Grund.

Ein einzelnes Lieferdatum sagt sehr wenig. Suchen Sie nach Schritten, bei denen es jeweils etwas zu sehen gibt: freigegebene Entwürfe, eine lauffähige Version unter einem Testlink, eine startbereite Fassung.

Fragen Sie, wie oft Sie Fortschritt sehen. Ein wöchentlicher Termin ist ein vernünftiger Mindeststandard; eine einzige Vorführung ganz am Ende ist ein Risiko.

Prüfen Sie, ob das Angebot Tests, Geschwindigkeit und Barrierefreiheit erwähnt – oder nur Funktionen.

Achten Sie auf Konkretes: welche Browser und Geräte unterstützt werden, welche Geschwindigkeit das Produkt erreichen soll und wer vor dem Launch testet.

Klären Sie, was der Preis genau abdeckt und wie die Zahlungen verteilt sind. Eine Anzahlung plus Zahlungen an Projektschritte ist Standard; 100% im Voraus nicht.

Suchen Sie den Änderungsprozess. Er sollte erklären, wie neue Wünsche geschätzt und freigegeben werden, bevor jemand damit beginnt.

Viele Angebote enden am Launch-Tag. Fragen Sie, was danach kommt: Gibt es einen Zeitraum für Fehlerbehebung, wie lange dauert er, und wie wird weitere Arbeit abgerechnet?

Ein Launch ohne Plan für Korrekturen und Aktualisierungen ist genau die Stelle, an der viele Produkte still stehen bleiben.

Was genau ist ausgeschlossen?

Wer arbeitet täglich an dem Projekt?

Was passiert, wenn wir den Umfang ändern müssen?

Wem gehören am Ende der Code und alle Konten?

Welche Betreuung ist nach dem Launch enthalten?