Ausschreibung für eine App: Lastenheft, Angebotsvergleich und Auswahl

Drei Angebote können drei verschiedene Apps beschreiben

Ein Unternehmen schreibt eine Termin-App aus. Anbieter A kalkuliert eine Kunden-App samt Mitarbeiterplanung und Administrationsbereich. Anbieter B setzt voraus, dass Termine vollständig aus dem bestehenden ERP kommen. Anbieter C beschreibt vor allem die mobilen Oberflächen. Alle drei Angebote wirken auf den ersten Blick plausibel. Trotzdem lassen sich weder Umfang noch Verantwortlichkeiten sauber vergleichen.

Genau dieses Problem soll eine Ausschreibung lösen. Im internationalen Umfeld ist oft von einem Request for Proposal, kurz RFP, die Rede. Im deutschen Projektalltag trifft man eher auf Lastenheft, Leistungsbeschreibung oder Angebotsanfrage. Die Bezeichnung ist zweitrangig. Entscheidend ist eine gemeinsame Informationsgrundlage, auf der Anbieter ihre unterschiedlichen Lösungswege nachvollziehbar darstellen.

Eine private Ausschreibung muss kein Vergabeverfahren im Kleinformat werden. Sie ist dann nützlich, wenn mehrere Fachbereiche entscheiden, bestehende Systeme angebunden werden oder mehrere Agenturen ernsthaft verglichen werden sollen. Bei einer frühen Gründeridee reicht häufig ein Projektsteckbrief für die Aufwandsschätzung und eine bezahlte Konzeptionsphase. Umfangreiche Unterlagen schaffen keine Sicherheit, wenn das eigentliche Nutzerproblem noch offen ist.

Lastenheft und Pflichtenheft haben unterschiedliche Aufgaben

Das Lastenheft beschreibt aus Auftraggebersicht, was erreicht werden soll und warum bestimmte Anforderungen bestehen. Das spätere Pflichtenheft erläutert aus Auftragnehmersicht, wie die vereinbarte Leistung umgesetzt und geprüft werden soll. Eine Angebotsanfrage verbindet das Lastenheft mit Fragen zum Anbieter, zum vorgesehenen Team und zur Zusammenarbeit.

In der Praxis werden diese Grenzen nicht immer streng gezogen. Die Denkweise bleibt trotzdem hilfreich. Der Auftraggeber sollte keine Architektur erfinden, nur um das Dokument technisch wirken zu lassen. Echte Vorgaben gehören hinein: eine vorhandene SAP-Schnittstelle, ein unternehmenseigener Identitätsdienst, bestimmte Endgeräte, Barrierefreiheit oder Datenschutzanforderungen. Eine bloße Vorliebe für ein Framework sollte als solche gekennzeichnet werden.

Für die interne Produktdefinition eignet sich die PRD-Vorlage für mobile Apps. Wenn Abläufe, Daten und Abnahmekriterien bereits konkret sind, hilft die Vorlage für eine technische App-Spezifikation. Die Ausschreibung verweist auf diese Anlagen, statt sie wortreich zu wiederholen.

Erst Eignung prüfen, dann vollständige Angebote anfordern

Ein fundiertes Angebot bindet Fachleute. Wer dieselben sechzig Fragen an zwanzig Agenturen verschickt, erhält häufig viele Standardtexte und wenig echte Auseinandersetzung.

Eine kurze Vorqualifikation ist effizienter. Auf zwei Seiten genügen Unternehmenskontext, Problem, Zielgruppe, voraussichtlicher Start und zentrale Randbedingungen. Gefragt werden passende Referenzen, Verfügbarkeit, mögliche Teamzusammensetzung, Arbeitssprache und erkennbare Ausschlussgründe. Dabei zählt die operative Ähnlichkeit eines Projekts mehr als das Branchenetikett. Eine Plattform mit Rollen, Auszahlungen und Konfliktfällen kann für einen Marktplatz aussagekräftiger sein als eine optisch ähnliche Katalog-App.

Nur eine kleine Auswahl erhält die vollständigen Unterlagen. Alle bekommen denselben Zeitplan, dieselbe Ansprechperson und denselben Zugang zu Anhängen. Wer nicht passt, kann früh absagen. Wer antwortet, weiß, dass die eigene Arbeit ernsthaft geprüft wird.

Diese Inhalte gehören in die Leistungsanfrage

Ein brauchbares Dokument muss nicht lang sein. Es muss die Stellen benennen, an denen Anbieter sonst stillschweigend unterschiedliche Annahmen treffen.

1. Ausgangslage und Anlass: Geschäft, heutiger Ablauf, erkennbares Problem und Grund für den jetzigen Zeitpunkt.
2. Nutzergruppen und Kernabläufe: Rollen und zwei bis fünf vollständige Wege, die in der ersten Version funktionieren müssen.
3. Erwartete Wirkung: beobachtbares Ergebnis statt Formulierungen wie "moderne Nutzererfahrung".
4. Grenze der ersten Version: Muss-Leistungen, erwünschte Optionen und ausdrücklich ausgeschlossene Themen.
5. Bestehende Landschaft: Backend, Website, ERP, CRM, Zahlungen, Identität, Daten, Inhalte und Designbestand.
6. Verbindliche Rahmenbedingungen: Plattformen, Länder, Sprachen, Sicherheit, Datenschutz, Barrierefreiheit, Offline-Nutzung und Zielgeräte, soweit relevant.
7. Mitwirkung und Zuständigkeit: Leistungen des Auftraggebers und erwartete Verantwortung für Konzeption, UX, Entwicklung, Test, Veröffentlichung und Betrieb.
8. Kontinuität: Repositories, Cloud- und Store-Konten, bearbeitbare Designs, Dokumentation, Fremdsoftware und Übergabe.
9. Verfahrensregeln: Aufbau des Angebots, Rückfragen, Fristen, Präsentation, Bewertung und Entscheidung.

Funktionswörter allein reichen selten. Hinter "Push-Nachrichten" kann eine simple Erinnerung oder ein vollständiges Regelwerk mit Einwilligung, Zeitfenstern, Präferenzen und Fehlerbehandlung stecken. Ein konkreter Ablauf macht den Unterschied sichtbar.

Geben Sie die Struktur der Antwort vor

Die Anbieter dürfen bei der Lösung unterschiedliche Schwerpunkte setzen. Die Grundinformationen sollten dennoch an derselben Stelle stehen. Fordern Sie folgende Kapitel: Verständnis der Aufgabe, vorgeschlagener Umfang, Ausschlüsse, nummerierte Annahmen, Projektphasen, benannte Rollen, Mitwirkung des Auftraggebers, technischer Ansatz, Qualitätssicherung, Veröffentlichung, Risiken, Rechte, Support und kaufmännischer Teil.

Nummerierte Annahmen erleichtern die Klärung erheblich. Stellt sich heraus, dass die bestehende Schnittstelle keine Schreibzugriffe erlaubt, können alle Bieter gezielt Annahme A-08 überarbeiten. Ohne diese Ordnung verteilt sich die Änderung auf Gesprächsnotizen und E-Mail-Verläufe.

Bitten Sie außerdem um eine Kennzeichnung je Anforderung: enthalten, optional, klärungsbedürftig oder nicht empfohlen. Eine begründete Gegenposition ist oft ein gutes Zeichen. Sie zeigt, dass ein Anbieter das gewünschte Produkt und nicht nur die Ausschreibung gewinnen möchte.

Die Bewertungsmatrix entsteht vor den Präsentationen

Die Kriterien werden intern festgelegt, solange noch niemand einen Favoriten hat. Andernfalls werden Gewichte schnell an die überzeugendste Präsentation angepasst.

Die Matrix ist kein Naturgesetz. Bei einer medizinischen Anwendung müssen Datenschutz, Sicherheit und Nachweise stärker zählen. Bei einem begrenzten Pilotprojekt kann die kurzfristige Verfügbarkeit wichtiger sein. Die Gewichtung soll die tatsächliche Entscheidung abbilden, nicht eine scheinbar objektive Zahl erzeugen.

Lassen Sie mindestens zwei Personen zunächst unabhängig bewerten. Besonders aufschlussreich sind große Abweichungen. Vielleicht hat eine Person eine bekannte Marke honoriert, während die andere bemerkt hat, dass das zugesagte Projektteam gar nicht benannt wurde.

Prüfen Sie das Lieferteam an einem schwierigen Fall

Die besten schriftlichen Kandidaten sollten eine reale Ausnahmesituation bearbeiten: Eine Zahlung war erfolgreich, die Buchung wurde aber nicht angelegt. Zwei Mitarbeitende vergeben denselben letzten Termin. Eine Synchronisierung bricht offline ab. Oder ein Administrator muss eine fehlerhafte Aktion nachvollziehbar zurücknehmen.

Am Termin sollten die Personen teilnehmen, die später tatsächlich arbeiten. Eine souveräne Vertriebspräsentation sagt wenig darüber aus, wie Produktdesign, Entwicklung und Projektleitung gemeinsam denken. Gute Teams fragen zunächst nach Nutzer und Betriebsablauf, trennen Wissen von Vermutung und schlagen einen kleinen Nachweis für die größte Unsicherheit vor.

Auch Referenzgespräche werden konkreter, wenn Sie nach Veränderungen nach Vertragsabschluss, unangenehmen Nachrichten, personeller Kontinuität und der Übergabe fragen. Eine Fallstudie belegt einen Start. Sie zeigt selten, wie das Projekt in schwierigen Wochen geführt wurde.

Annahmen sind wichtiger als der Endbetrag

Übertragen Sie alle Angebote in eine gemeinsame Übersicht: Rollen, Plattformen, Backend, Administrationsbereich, Schnittstellen, Design, Migration, Analytics, Test, Store-Veröffentlichung, Dokumentation und Support. Daneben stehen Ausschlüsse und Leistungen, die Ihr Unternehmen liefern soll.

Eine offen benannte Unsicherheit ist kein Mangel. "Wir müssen die API prüfen, bevor wir Offline-Synchronisation zusagen" ist belastbarer als eine sichere Aussage über eine unbekannte Schnittstelle. Vergleichen Sie, wie Anbieter Unsicherheit abbauen: technischer Prototyp, Ablaufworkshop, Datenprobe oder gestufte Entscheidung.

Der Beitrag zu Festpreis und Time and Materials erläutert, wie Vertragsmodelle mit Unsicherheit umgehen. Die Ausschreibung soll diese Unsicherheit früh sichtbar machen, nicht sprachlich überdecken.

Rechte und Übergabe gehören schon in die Anfrage

Fragen Sie, wer Quellcode-Repositories, Apple- und Google-Konten, Backend, Datenbank, Domains, Analytics, Signaturschlüssel und externe Dienste kontrolliert. Definieren Sie außerdem erwartete Liefergegenstände je Abschnitt: Code, bearbeitbares Design, Build-Anleitung, Abhängigkeitsliste, Testergebnisse und bekannte Einschränkungen.

Das WIPO-Handbuch zu App-Verträgen unterscheidet neu erstellten Code, bestehende Bausteine des Dienstleisters, Open Source und Komponenten Dritter. Dafür können unterschiedliche Rechte gelten. Eine Ausschreibung ersetzt keine juristische Prüfung. Sie sorgt aber dafür, dass das Thema nicht erst in der letzten Vertragsrunde auftaucht.

Die Checkliste zur Projektdokumentation und Übergabe beschreibt die technische Abnahme. Für die Vertragsprüfung gibt es die Checkliste zum App-Entwicklungsvertrag.

Kompakte Vorlage für den ersten Entwurf

Ein sinnvoller Aufbau lautet: Unternehmen und Anlass; Nutzer und Kernabläufe; erwartetes Ergebnis; Umfang und Nicht-Ziele; vorhandene Systeme und Unterlagen; Mitwirkung; verbindliche Randbedingungen; Fragen an den Anbieter; geforderte Nachweise; Rückfragenprozess; Antwortstruktur; Bewertung und Zeitplan.

Fügen Sie wenige, aber verständliche Anlagen bei: einen Ablauf, ein Systembild, Beispieldaten oder einen relevanten Analytics-Ausschnitt. Ein großer Ordner ohne Einordnung macht das Vorhaben nicht genauer. Er zwingt nur jeden Anbieter, dieselbe Sortierarbeit erneut zu leisten.

Warnsignale in Angeboten

Vorsicht ist angebracht, wenn ein Angebot die Anforderung nur umformuliert, allen Wünschen ohne Abwägung zustimmt oder eine Technologie ohne Bezug zu den Randbedingungen empfiehlt. Weitere Warnsignale sind Seniorität ausschließlich im Vertrieb, "Qualitätssicherung inklusive" ohne Prüfweg, unklare Zuständigkeit für Konten und Quellcode oder Support, der auf einen späteren Vertrag vertagt wird.

Bitten Sie um anonymisierte Arbeitsproben: ein Abnahmekriterium, einen Risikoeintrag, eine Release-Checkliste oder ein Übergabeverzeichnis. Nicht die Menge der Vorlagen zählt. Sie prüfen, ob der behauptete Prozess im Alltag brauchbare Ergebnisse hinterlässt.

Wie Appfyl auf eine gute Ausschreibung antwortet

Wir prüfen zunächst, ob die gewünschte erste Version ein zusammenhängendes Produkt ergibt. Dazu ordnen wir Nutzerabläufe, Arbeit im Administrationsbereich, Integrationen, Ausnahmen und Mitwirkung des Auftraggebers. Anschließend benennen wir Umfang, offene Punkte und Leistungen, die besser später folgen. Erst daraus ergibt sich die technische Empfehlung.

Fehlt noch eine Ausgangsbeschreibung, erfasst das Appfyl-Schätzwerkzeug Funktionen und freien Kontext. Für Gespräche mit Anbietern ergänzt die Liste der Fragen an eine App-Agentur diese Vorlage.

Sehen Sie, wie Appfyl Funktionsumfang in veröffentlichte Produkte übersetzt. Appfyl Cases ansehen.

Häufige Fragen