Eine App bestellen – Profi-Fahrplan für Firmen

• Eines sagt, sie würden „alles zusammenstellen" für 3.000 Euro.
• Ein anderes nennt eine Zahl zwischen 8.000 und 10.000 Euro.
• Ein erfahreneres Team spricht von etwa 30.000 Dollar aufwärts.

Alle wirken professionell, zeigen Portfolios, sprechen gut – aber Sie haben ein ungutes Gefühl: Sie wissen nicht, welche Zahl realistisch ist, welches Team mittendrin verschwindet und welches Team tatsächlich etwas liefert, das Ihrem Business nützt.

Bei Olymaris haben wir dieses Szenario unzählige Male erlebt: Ein kluger Auftraggeber, aber ohne Fahrplan. Technische Teams, die die Welt jeweils aus ihrer eigenen Perspektive sehen. Und ein Projekt, das zu einem strategischen Asset werden könnte, aber stattdessen zu einer nervlichen und finanziellen Belastung wird.

Warum wir diesen Artikel geschrieben haben

Dieser Artikel soll Sie nicht zum Programmierer machen, sondern zu einem „klugen und nicht ausnutzbaren Auftraggeber" – jemandem, der genau weiß, wo er anfangen muss, welche Fragen er stellen sollte und was er niemals unterschreiben darf, wenn er mit einem Team (einschließlich Olymaris) verhandelt.

Dies ist der „Hub-Artikel" des App-Clusters. Von hier aus können Sie zu spezialisierteren Artikeln navigieren, wie:

Aber jetzt beginnen wir mit dem Hauptweg.

Schritt Null: Warum wollen Sie überhaupt eine App? (Die Macht beginnt mit dieser Frage)

Die meisten Auftraggeber starten so: „Alle haben eine App, wir sollten auch eine haben." Von diesem Moment an verlieren Sie die Kontrolle. Denn das technische Team wird das Ziel für Sie definieren – und wer das Ziel definiert, kontrolliert das Spiel.

Im ersten Discovery-Meeting bei Olymaris sprechen wir absichtlich noch nicht über Technologie. Wir stellen drei Fragen, die das Herz des gesamten Projekts sind:

1. Welches spezifische Problem in Ihrem Business soll diese App lösen?
2. Wer ist die Hauptzielgruppe der App? Endkunden? VIP-Kunden? Interne Mitarbeiter? Manager?
3. Welche Kennzahl sollte sich sechs bis zwölf Monate nach dem Launch geändert haben, damit Sie sagen: „Diese App war erfolgreich"? Umsatz? Anzahl der Bestellungen? Rücklaufquote? Support-Kosten? Reaktionszeit?

Olymaris-Regel: Solange das Business-Ziel der App nicht messbar ist, ähnelt jedes Gespräch über Kosten, Technologie und Deadlines eher Wahrsagerei als Beratung.

Schritt 1: Eine Idee, die gebaut und getestet werden kann, nicht nur besprochen

Fast alle beginnen mit einem Satz wie diesem: „Ich möchte eine Super-App bauen, etwas wie X, aber vollständiger..."

Eine Idee, die alles und nichts zugleich will, hat drei ernsthafte Probleme: Sie verschlingt das Budget, verlängert die Zeit gnadenlos und die erste Version erreicht nie einen echten Nutzer.

Eine gesunde Idee für eine App-Bestellung hat mindestens diese Eigenschaften:

✓ Klares Problem: z.B. „Terminbuchungen erfolgen jetzt per Telefon und Notizbuch, und wir haben ständig Fehler und Doppelarbeit."
✓ Klare Zielgruppe: Endkunde? Vertriebsteam? Manager? Jeder erfordert eine andere Architektur und UX.
✓ Einfaches Nutzungsszenario: „Login → Registrierung → Service auswählen → Zahlung → Bestätigung erhalten."
✓ Klarer Wertpfad: Direkter Umsatz, Reduzierung der Betriebskosten, Datensammlung, erhöhte Loyalität usw.

Wenn Sie diese vier Punkte nicht auf einer A4-Seite aufschreiben können, sind Sie noch nicht bereit, eine App zu bestellen.

Um herauszufinden, ob Ihre Idee überhaupt es wert ist, entwickelt zu werden, sehen Sie sich unbedingt die Checkliste im Artikel „10 Zeichen, dass Ihre App-Idee es wert ist, entwickelt zu werden" an. Dort können Sie Ihre Idee bewerten und entscheiden, ob Sie weitermachen, sie verkleinern oder mutig aufgeben sollten.

Schritt 2: Native, Hybrid oder Web App – Eine Entscheidung, die jahrelang Ihre Kosten beeinflusst

Eine der ersten Fragen nach der Idee ist: „Sollen wir die App nativ entwickeln? Hybrid? Oder reicht eine Web-App?"

Teams empfehlen normalerweise das, worin sie am stärksten sind. Lieben sie Flutter? Sie beantworten alles mit Flutter. Kennen sie nur Native? Alles andere nennen sie „vorübergehend" und „unprofessionell".

Die Wahrheit ist, dass diese Wahl eine wirtschaftliche und strategische Entscheidung ist, keine religiöse. Ganz kurz:

Native

Beste Performance und Benutzererfahrung, aber höhere Kosten und längere Zeit, besonders wenn Sie sowohl iOS als auch Android wollen.

Hybrid / Cross-Platform

Eine Codebasis für mehrere Ausgaben; für 70-80% der Unternehmen ist die Kombination aus Geschwindigkeit/Qualität/Kosten sinnvoll.

Web App / PWA

Schnellere und meist günstigere Entwicklung; ideal für interne Panels, Dashboards und MVPs ohne tiefe Mobile-Hardware-Abhängigkeit.

Bei Olymaris wägen wir drei Dinge ab, bevor der Name einer Technologie auf den Tisch kommt:

1. Intensität und Art der Benutzerinteraktion mit der App (täglich? gelegentlich? intensiv?)
2. Zielplattformen in den nächsten 12 Monaten (nur mobil? mobil + web?)
3. Realistisches Budget für Phase 1

Wenn Sie diese Entscheidung mit Beispielen, Vergleichstabellen und realen Szenarien sehen möchten, lesen Sie unbedingt: Native, Hybrid oder Web App – Welche ist für Sie geeignet?

Schritt 3: App-Entwicklungskosten – Wie man nicht zwischen 3.000 und 60.000 stecken bleibt

Wenn Sie von mehreren Stellen Angebote einholen, hören Sie normalerweise so etwas:

• Kleines Team: „3.000 bis 5.000 Euro, wir stellen alles zusammen."
• Mittelgroßes Unternehmen: „Etwa 15.000 bis 25.000 Euro."
• Seriöseres Team: „Je nach Umfang ab 30.000 Dollar aufwärts."

Oberflächlich betrachtet haben wir zwei „überteuerte" Teams und ein „faires" Team. Die Realität ist, dass jedes etwas anderes bepreist hat.

In Olymaris-Schätzungsmeetings unterteilen wir die Kosten in mehrere Blöcke:

→ Analyse und Produktdesign
→ Maßgeschneidertes UX/UI-Design
→ Backend, Datenbank und API
→ Mobile/Web-Entwicklung
→ Test und Qualitätssicherung
→ Deployment und Launch
→ Wartung und zukünftige Entwicklung

Es reicht, jedes Team zu fragen: „Diese Zahl, die Sie genannt haben – welche Teile deckt sie genau ab und welche nicht?" In 90% der Fälle wird das Bild plötzlich klar: Einer hat UX nicht eingerechnet, einer schreibt Wartung separat, einer hat das Backend nur zur Hälfte gesehen, und das 3.000-Euro-Team klebt eigentlich nur eine Hülle auf einen fertigen Service.

Goldene Regel: Jedes Angebot, das „Arbeitsstunden, Rollen und Projektteile" nicht klar zeigt, ist selbst wenn es günstiger ist, tatsächlich teurer – weil Sie auch Risiko und Unklarheit kaufen.

Wenn Sie realistische Preisspannen für verschiedene KMU-Szenarien sehen möchten (einfache App, App mit Admin-Panel, mehrseitige App usw.), lesen Sie den folgenden Artikel und verwenden Sie ihn als Referenz in Verhandlungen: Was kostet die App-Entwicklung? Preisleitfaden für kleine und mittlere Unternehmen

Schritt 4: Scope – Die echte App, die Sie bauen, nicht die imaginäre in Ihrem Kopf

Scope bedeutet die genaue Liste der Dinge, die in Version 1 gebaut werden, zusammen mit den Dingen, die absichtlich für spätere Versionen aufgehoben werden.

Wenn der Scope nicht klar ist: Jedes Meeting endet mit dem Satz „Lass uns nur dieses eine kleine Feature hinzufügen", Deadlines verschieben sich ständig, Kosten steigen und das Projekt wird zum Sumpf.

Das Modell, das wir bei Olymaris verwenden (und das Sie von jedem anderen Team verlangen können):

1.
Feature-Wunschliste – Schreiben Sie alles ohne Zensur auf.
2.
MoSCoW-Priorisierung:
- • Must have – Ohne diese macht die App keinen Sinn
- • Should have – Besser in Version 1
- • Could have – Wenn Zeit/Budget übrig ist
- • Won't have (for now) – Für spätere Versionen
3.
Scope-Genehmigung Version 1 – Alles, was nicht in diesem Dokument steht, ist standardmäßig nicht Teil der Arbeit. Das Hinzufügen eines Elements bedeutet Änderung von Zeit und Kosten.

Dieses Dokument ist Ihre Verteidigungswaffe, um zu verhindern, dass das Projekt außer Kontrolle gerät.

Schritt 5: UX – Wo der Benutzer entscheidet, zu bleiben oder die App zu löschen

Seien wir ehrlich: Der Benutzer hat keine emotionale Bindung zu Ihnen. Wenn er verwirrt ist, schließt er die App und macht mit seinem Leben weiter.

Ob Ihre App „das Leben anderer vereinfacht oder ihre Nerven strapaziert" hängt mehr von der UX ab als nur vom Programmieren.

Der Prozess, den wir bei Olymaris empfehlen (und den Sie von jedem Team verlangen können):

1. Zuerst nur die Hauptbenutzerszenarien auf Papier, ohne Farbe und Grafik; nur Boxen und Pfeile
2. Dann Wireframe-Design der Seiten
3. Schneller Test mit einigen echten Benutzern
4. Schließlich finales, farbiges UI-Design auf einer durchdachten UX, nicht umgekehrt

Wenn das Team von Anfang an zu farbigen Designs und Grafiken geht und keine Rede von Szenarien und Wireframes ist, wissen Sie, dass Sie auf rutschigem Boden bauen.

Schritt 6: Team-Auswahl – Wie Sie Ihr Schicksal nicht den falschen Leuten anvertrauen

Die Team-Auswahl ist in der Praxis schicksalhafter als die Technologie-Auswahl. Ein paar einfache, aber kritische Checkpoints:

1. Live-Portfolio, nicht nur hübsche Mockups

Links zu veröffentlichten Apps in Stores, mit klarer Erklärung der Team-Rolle: Nur Frontend? Gesamtes Produkt? Haben sie auch Produktberatung gegeben oder nur programmiert?

2. Prozess, nicht nur Versprechen

Fragen Sie: „Wie viele Analyse- und Design-Meetings haben Sie vor dem Programmieren? Wie oft liefern Sie eine Testversion? Wie dokumentieren Sie Anforderungen?" Wenn die Antworten vage und unklar sind, werden Sie in der Praxis auch mit Unklarheit und Überraschungen konfrontiert.

3. Team mit definierten Rollen

Für ein ernsthaftes Projekt sollten mindestens diese Rollen irgendwie abgedeckt sein: Product/Analyst, UX/UI, Backend, Mobile/Web, QA. Wenn alles in einer Hand liegt, mag das für ein sehr kleines Projekt akzeptabel sein, aber für etwas, das ein echtes Business-Asset werden soll, ist es ein schweres Risiko.

4. Finanzielle und vertragliche Transparenz

Stufenweise Zahlung basierend auf Meilensteinen, schriftliche Erklärung zu Kosten außerhalb des Vertrags (z.B. Scope-Änderung) und Bedingungen für zukünftige Wartung und Entwicklung.

Die Olymaris-Struktur ist so aufgebaut, dass Sie, wenn Sie morgen entscheiden, die weitere Arbeit einem anderen Team zu geben, auf dem stehen können, was Sie erhalten haben – nicht mit leeren Händen dastehen.

Schritt 7: Vertrag, Eigentum und versteckte Risiken

Die größten Schläge kommen normalerweise von hier: Der Quellcode gehört Ihnen nicht, Domains und Server sind nicht auf Ihren Namen, jede kleine Änderung wird zum Werkzeug für finanziellen Druck.

Einige Klauseln, bei denen wir bei Olymaris immer streng sind (und Sie sollten es auch sein):

⚠ Quellcode-Eigentum: Nach der Abrechnung gehört der Quellcode Ihnen und wird in einem privaten Repository aufbewahrt
⚠ Domain- und Hauptkonto-Eigentum: Domain, Cloud-Konten und Store-Konten sollten vorzugsweise auf den Namen Ihres Unternehmens registriert werden, nicht auf den des Programmierers
⚠ SLA für Bugs: Z.B. werden kritische Bugs bis zu 3 Monate nach dem Launch kostenlos behoben
⚠ Wartungsplan: Genau welches Niveau an Monitoring, Updates und Support wird zu welchen Kosten angeboten

Um sich mit häufigen Vertragsrisiken und realen Szenarien vertraut zu machen, speichern Sie unbedingt diesen Artikel: 10 häufige Risiken bei App-Projekten, die Zeit und Budget verbrennen

Schritt 8: Entwicklungsprozess, Test und Launch – Was ist normal und was ist ein Warnsignal?

Wenn das Projekt beginnt, sollten Sie zwischen „natürlicher Verzögerung" und „einem Projekt, das untergeht" unterscheiden können.

Ein gesundes Muster, das wir bei Olymaris implementieren, hat normalerweise diese Eigenschaften:

✓ Das Projekt ist in kurze Sprints (z.B. zweiwöchig) unterteilt
✓ Jeder Sprint hat ein klares Ziel und am Ende haben Sie eine sichtbare Demo
✓ Regelmäßige, kurze Berichtsmeetings (wöchentlich oder zweiwöchentlich), nicht langes Schweigen und dann ein Schock
✓ Die Testumgebung ist von der Hauptumgebung getrennt und Sie sehen die Version vor dem Endbenutzer
✓ Der Launch ist schrittweise, nicht ein explosiver Launch ohne Übung

Wenn das Team nur ein endgültiges Lieferdatum gibt und zwischen heute und diesem Tag keinen Meilenstein und keine Zwischenversion definiert, sagt es praktisch: „Vertraue uns, du wirst später sehen, was passiert" – und das ist der gefährlichste Satz in der Softwarewelt.

Wenn Sie ein genaueres Bild der realistischen Zeitpläne für verschiedene Web- und App-Projekte haben möchten, sehen Sie sich unbedingt diesen Artikel an und vergleichen Sie seine Zahlen mit Team-Angeboten: Wie lange dauert es, eine Website oder App zu erstellen?

Schritt 9: Nach dem Launch – Wo kluge Apps die anderen überholen

Viele denken, das Ziel sei „die App zu veröffentlichen". In der Praxis ist der Launch-Tag Tag Null, nicht Tag Hundert.

Einige wichtige Aufgaben nach dem Launch, die wir Kunden empfehlen:

→ Seriöse Analytics installieren: Wissen Sie genau, was Benutzer tun, wo sie stecken bleiben und wo Abbrüche auftreten
→ Strukturiertes Feedback sammeln: Formular in der App, Support-Kanal, Interviews mit einigen Schlüsselbenutzern
→ Plan für zukünftige Versionen: Besser alle 4-6 Wochen eine Version mit Bugfixes und einigen kleinen Verbesserungen zu haben, damit Benutzer spüren, dass die App lebt
→ KI zur richtigen Zeit hinzufügen: Chatbot, Inhalts- oder Produktempfehlungen, Personalisierung der Erfahrung basierend auf tatsächlichem Benutzerverhalten

KI sollte nicht in Version 1 nur zum „modern aussehen" eingeklebt werden; sie sollte auf den Schultern echter Daten aus frühen Versionen aufbauen.

Wie Sie diesen Fahrplan jetzt zu Ihrem Vorteil nutzen können

Bis hierher haben Sie einen vollständigen Fahrplan. Jetzt haben Sie zwei Wege vor sich:

Weg 1: Unabhängige Bewegung mit dieser Checkliste

Speichern Sie diesen Artikel für sich. Jedes Mal, wenn Sie ein Meeting mit einem Team haben, gehen Sie nach diesen Schritten vor:

• Business-Ziel?
• App-Typ und Begründung?
• Scope Version 1?
• UX-Prozess?
• Vertrag und Eigentum?
• Plan nach dem Launch?

Wo immer die Antworten unklar sind, sagen Sie ruhig, aber bestimmt „nein", anstatt emotional zu diskutieren.

Weg 2: Ein Team nutzen, das diesen Weg oft gegangen ist

Bei Olymaris sind diese Schritte nicht nur Artikel-Theorie, sondern das, was wir in echten Projekten umsetzen. Die Zusammenarbeit beginnt normalerweise mit einem fokussierten Discovery-Meeting, wo wir:

• Ihre Idee in Business-Sprache übersetzen
• Mit Ihnen den Scope von Version 1 definieren
• Basierend auf Marktrealität und Ihrem Budget eine logische Empfehlung für den App-Typ geben
• Einen realistischen Zeit-/Kostenplan auf den Tisch legen

Wenn Sie jetzt verstehen möchten, wie Ihre Idee, Ihr Budget und Ihre Timeline in der realen Welt aussehen, ist der einfachste Schritt, über die Olymaris-Website ein kurzes Discovery-Meeting zu buchen und diesmal mit vollen Händen an den Verhandlungstisch zu kommen.

Wichtig ist, dass Sie von nun an nicht mit „Gefühl" in das App-Bestellungsspiel einsteigen, sondern mit „Plan und Macht".

Häufig gestellte Fragen zur App-Bestellung

Frage 1: Wenn ich nur eine rohe Idee habe, wo fange ich an?

Verwandeln Sie die Idee in drei Dinge: das Hauptproblem, die Hauptzielgruppe und ein einfaches Nutzungsszenario. Wenn Sie das alleine nicht können, vereinbaren Sie ein Discovery-Meeting mit einem erfahrenen Team, um diese drei Punkte in 60-90 Minuten gemeinsam zu klären und einen baubaren Kern (MVP) zu definieren. Zur Bewertung der Ideenstärke können Sie die Checkliste im Artikel „10 Zeichen, dass Ihre App-Idee es wert ist, entwickelt zu werden" verwenden.

Frage 2: Wie erkenne ich, ob der vorgeschlagene Preis für die App-Entwicklung sinnvoll ist oder nicht?

Fragen Sie zuerst, auf welche Teile diese Zahl genau aufgeteilt ist: Analyse, UX/UI-Design, Backend, Mobile/Web-Entwicklung, Test, Launch, Wartung? Dann fragen Sie, wie viele Personen wie viele Stunden am Projekt arbeiten und wie die Preisänderungsformel aussieht, wenn sich der Scope ändert. Jedes Angebot, das nicht in wenigen einfachen Sätzen erklären kann, „wohin das Geld genau geht", birgt mehr Risiko, selbst wenn es günstiger ist. Für realistische Preisspannen und numerische Beispiele siehe: Preisleitfaden für App-Entwicklung

Frage 3: Wie lange dauert es normalerweise, eine App zu entwickeln?

Abhängig vom Scope und der erwarteten Qualität benötigen Sie normalerweise einige Wochen für Analyse, Design und UX, einige Monate für Entwicklung und Test sowie eine Teststart-Phase. Wenn das Team nur ein Enddatum gibt und keine Zwischenstufe (Meilenstein, Testversion, Demo) definiert, ist das ein ernsthaftes Warnsignal. Für genauere Zahlen in verschiedenen Szenarien siehe: Realistische Zeitplanung

Frage 4: Brauche ich von Anfang an sowohl iOS als auch Android?

Nicht unbedingt. Für viele Unternehmen ist es sinnvoller, nur mit einer Plattform zu beginnen (z.B. Android oder eine gute Web-App) und dann schrittweise zu erweitern. Die Entscheidung sollte auf tatsächlichen Statistiken Ihrer Zielbenutzer und Ihrem Budget basieren, nicht nur auf dem Gefühl, „von Tag eins an alles zu haben".

Frage 5: Was ist besser: Native App, Hybrid App oder Web App?

Die richtige Antwort hängt von Ihrem Ziel, Budget und Zeithorizont ab. Wenn Performance und Benutzererfahrung auf höchstem Niveau oberste Priorität haben und die App in den nächsten 3-5 Jahren der Kern des Business sein soll, ist Native sinnvoll. Wenn Sie mit geringerem Budget schneller auf mehreren Plattformen präsent sein möchten, bietet Hybrid oft das beste Gleichgewicht. Wenn Sie keine starke Abhängigkeit von mobiler Hardware haben und ein MVP oder internes Panel erstellen möchten, ist Web App eine starke Option. Für einen detaillierteren Vergleich siehe: Native, Hybrid oder Web App

Frage 6: Was sind die größten Risiken bei App-Projekten und wie verhindere ich sie?

Ständige Launch-Verzögerungen, Scope Creep (endloses Hinzufügen von Features), fehlender Product Owner, unzureichende Tests, schwache UX, Abhängigkeit von einer Person, fehlende Dokumentation und kein Wartungsplan gehören zu den häufigen Risiken. Ihre beste Verteidigung: klarer Scope, definierte Meilensteine, transparenter Vertrag über Eigentum und Dokumentation und ein Team, das diese Risiken ernst nimmt. Für Beispiele und praktische Lösungen siehe: 10 häufige App-Projekt-Risiken

Frage 7: Muss ich von Version 1 an KI in der App haben?

In den meisten Projekten lautet die Antwort „nein". Version 1 sollte das Hauptproblem lösen und echte Benutzer und echte Daten generieren. KI macht Sinn, wenn Sie wissen, welches Verhalten Sie vorhersagen oder personalisieren möchten und genügend Daten dafür haben.

Frage 8: Woher weiß ich, ob das aktuelle Team für die Fortsetzung geeignet ist oder ob ich es wechseln sollte?

Achten Sie auf einige Anzeichen: Haben Sie klare Meilensteine und zeigbare Versionen oder nur Versprechen? Sind Dokumentation, Repository und Zugriffe in Ihrem Besitz? Sind sie sensibel für Risiken, Tests und UX oder verschieben sie alles auf „wir reparieren es später"? Wenn die Antworten auf diese Fragen negativ sind, ist es Zeit, die Zusammenarbeitsstruktur oder das Team selbst zu ändern; je später Sie das tun, desto höher werden die Ausstiegskosten.

Eine App bestellen: Der professionelle Fahrplan für Auftraggeber

App-Bestellung: Der professionelle Fahrplan für Auftraggeber