Rechnungsstellung als App-Entwickler: Saetze, Konditionen und Vorlagen

Kurzfassung: Strukturieren Sie App-Entwicklungsrechnungen um Sprints oder Meilensteine, die an vorzeigbare Builds gebunden sind, trennen Sie plattformspezifische Arbeit (iOS, Android, Backend) in jeder Zeile, leiten Sie Store-Gebuehren und Cloud-Kosten transparent weiter, und rechnen Sie alle zwei Wochen oder pro Meilenstein ab, um den Cashflow mit der Lieferung abzugleichen.

Mobile- und Backend-Arbeit profitiert von Rechnungen, die Ihren Backlog widerspiegeln: Epics, Sprints oder feste Phasen fuer MVP → v1 → Feinschliff. Das hilft Gruendern, Ausgaben dem Runway zuzuordnen, und Enterprise-PMs, PO-Positionen abzugleichen.

TestFlight-Builds, Store-Screenshots und Analytics sind leicht zu verschenken — setzen Sie sie in Scope-Dokumente und Rechnungspositionen, wenn sie nicht kostenlos sind. Backend-API-Arbeit und Mobile-UI sollten trennbare Positionen sein, wenn verschiedene Sponsoren fuer jeden Track bezahlen. Wear OS oder Apple Watch-Companions werden leicht unterschaetzt — wenn Sie sie bepreist haben, listen Sie die Plattform explizit, damit niemand denkt, "iOS-App" haette jede Bildschirmgroesse standardmaessig eingeschlossen.

Typische Saetze

Time and Materials mit einer Nicht-ueberschreiten-Obergrenze, Festpreis-Meilensteine oder monatliche Team-Retainer sind gaengig. Apple-/Google-Entwicklergebuehren und Cloud-Nutzung koennen Durchlaufposten oder mit Aufschlag sein — geben Sie Ihre Richtlinie an. Fuer Release-Prozess-Kontext, der Zeitplaene beeinflusst, siehe Apples App Store Review Guidelines zur Erklaerung von Ablehnungszyklen auf Rechnungen oder Leistungsbeschreibungen.

Stundenbasiertes T&M (100-200 $+ je nach Stack und Markt) eignet sich fuer laufende Feature-Entwicklung und Bugfix-Auftraege. Festpreis-Meilensteine passen fuer MVP-Builds, bei denen der Umfang in einem Produktanforderungsdokument definiert ist. Sprint-basierte Abrechnung (alle zwei Wochen) passt zu agilen Workflows und haelt beide Seiten bei der Velocity ehrlich. Monatliche Retainer (5.000-20.000 $+) eignen sich fuer laufende Produktentwicklung, bei der Sie als fraktionaler CTO oder eingebetteter Entwickler fungieren.

Erhoehen Sie Saetze, wenn Sie Plattformspezialisierung entwickeln (React Native Cross-Platform, SwiftUI nativ, Flutter), wenn Sie App-Store-Erfolgsmetriken vorweisen koennen (Downloads, Bewertungen, Retention) oder wenn Ihre Pipeline durchgehend gebucht ist. Entwickler mit DevOps- und CI/CD-Faehigkeiten erzielen Aufschlaege, weil sie den Bedarf des Kunden an einer separaten Ops-Einstellung reduzieren.

Security-Review oder Penetrationstest-Behebungsbloecke sollten separate Meilensteine sein, damit die Zahlung nicht von Zeitplaenen Dritter abhaengt, die Sie nicht kontrollieren. CI/CD-Minuten und Device-Farm-Nutzung steigen kurz vor dem Launch — entweder enthaltene Nutzung deckeln oder Mehrverbrauch abrechnen. Offline-First oder sync-intensive Features verdienen explizite QA-Positionen — sie sind nicht "einfach ein weiterer Screen", wenn Regressionstests sich verdoppeln. Push-Notification- und Deep-Link-Plumbing erstreckt sich oft ueber Mobile und Backend — teilen Sie die Stunden ehrlich auf, damit jeder Team-Lead sieht, was er finanziert.

Beispiel-Rechnungspositionen

Wann die Rechnung senden

Fuer sprintbasierte Entwicklung stellen Sie am Ende jedes Sprints (alle zwei Wochen) eine Rechnung, nach der Demo oder dem Sprint-Review. Die Verknuepfung der Rechnung mit einem vorzeigbaren Build gibt dem Kunden ein konkretes Lieferobjekt zum Abgleich mit der Berechnung.

Bei Festpreis-MVP-Projekten rechnen Sie pro Meilenstein ab: typischerweise 30 % bei Projektstart, 40 % bei Beta-Build, 30 % bei App-Store-Einreichung. Passen Sie die Aufteilung basierend auf dem Projektrisiko an — hoehere Vorauszahlungen sind angemessen fuer Neukunden ohne Erfolgsbilanz.

Fuer laufende Retainer und Support stellen Sie am Monatsanfang eine Rechnung mit einer Zusammenfassung der geschlossenen Tickets, ausgelieferten Features und genutzten Stunden. Wenn der Retainer ein Stundenkontingent enthaelt, zeigen Sie Nutzung und verbleibendes Guthaben.

Zahlungsbedingungen

Vorauszahlung fuer Sprint 1, dann alle 2 Wochen oder pro Meilenstein; Netto 30 fuer unterschriebene B2B-Vertraege. Einbehalte selten, es sei denn, der Enterprise-Einkauf verlangt sie — spiegeln Sie deren Wortlaut. Fuer Festpreis-MVPs binden Sie 30/40/30-Aufteilungen an vorzeigbare Builds, nicht nur an Kalendermonate. Siehe Rechnungszahlungsbedingungen.

Was enthalten sein sollte

Release- oder Sprint-ID, Features oder Tickets zusammengefasst (lesbar fuer Nicht-Techniker), Stunden × Satz oder pauschale Sprint-Gebuehr, Drittanbieter-Kosten aufgeschluesselt, Tests/QA wenn separat abgerechnet, Steuer, Gesamtbetrag, Faelligkeitsdatum. Ueberpruefen Sie universelle Felder ueber was auf eine Rechnung gehoert.

Vermerken Sie Plattform (iOS, Android, Backend) in jeder Zeile, wenn ein Stakeholder nur die Haelfte des Stacks interessiert. Build-Nummer oder Tag-Referenzen helfen QA und Finanzabteilung, dasselbe Release zuzuordnen.

Haeufige Fehler

Einzelne Zeile "Entwicklung" fuer 20.000 $ — Finanzabteilungen lehnen ab. Scope Creep ohne Nachtraege. Store-Einreichung als enthalten angenommen — berechnen Sie explizit, wenn Sie das Release-Management uebernehmen. Waehrungsfehler bei globalen Kunden — geben Sie die Waehrung in jeder Zeile an. Crashlytics- oder Observability-Kosten stillschweigend absorbiert — entweder in den Retainer einbuendeln oder transparent abrechnen. OWASP-Fixes unter "Bugs" versteckt, obwohl sie Sicherheits-Scope waren — kennzeichnen Sie sie fuer Audit-Trails. Feature Flags und Remote Config-Arbeit unter "Feinschliff" versteckt — sie sind Infrastruktur mit laufenden Kosten; zeigen Sie sie bei der Setup-Abrechnung. App-Store-Screenshot- oder Vorschauvideo-Produktion ist Marketingarbeit — entweder explizit in einem Paket einschliessen oder separat abrechnen.

Keine Trennung von Store-Ablehnungs-Nacharbeit und normaler Entwicklung — wenn Apple den Build ablehnt und Sie 8 Stunden fuer Compliance-Korrekturen aufwenden, ist das entweder durch Ihre Einreichungsmanagement-Position abgedeckt oder als zusaetzlicher Umfang abzurechnen; Mehrdeutigkeit hier untergaebt Vertrauen. Backend-Infrastrukturkosten, die still wachsen ohne Kundenbewusstsein — senden Sie eine monatliche Cloud-Kostenuebersicht, auch wenn Sie sie im Retainer absorbieren; Ueberraschungen bei der Verlaengerung toeten Vertraege. Fehlende Build-Nummer oder Versions-Tag auf jeder Rechnung — Engineering und Finanzen muessen die Rechnung einem bestimmten Release zuordnen koennen; "Sprint 4 Entwicklung" ohne Versionsreferenz ist nicht pruefbar.

FAQ

Sollte ich fuer App-Store-Einreichung und Review-Management abrechnen? Ja. Die Verwaltung des Einreichungsprozesses — Archiv erstellen, Release Notes schreiben, Screenshots verwalten, Pruefer-Fragen beantworten und Ablehnungszyklen managen — ist echte Arbeit. Berechnen Sie es als Pauschale pro Einreichung oder als benannte Position in Ihrem Meilenstein. Kunden, die annehmen, "App bauen" schliesst unendliche Store-Einreichungen ein, werden Ihre Zeit erschoepfen.

Wie gehe ich mit Cloud-Kosten um, die monatlich schwanken? Leiten Sie tatsaechliche Cloud-Kosten mit Beleg oder Cost-Explorer-Screenshot weiter. Wenn Sie Planbarkeit bevorzugen, legen Sie im Vertrag ein monatliches Cloud-Budget fest und berechnen einen Pauschalbetrag, mit Mehrverbrauch zum Selbstkostenpreis. Zeigen Sie in jedem Fall die Cloud-Position separat von der Entwicklungsarbeit, damit der Kunde versteht, dass Infrastruktur eine laufende Verpflichtung ist.

Wie rechne ich am besten mit einem Startup mit begrenztem Runway ab? Nutzen Sie meilensteinbasierte Abrechnung gebunden an vorzeigbare Builds, damit der Gruender Ausgaben direkt dem Fortschritt zuordnen kann. Vermeiden Sie Netto 30 bei Early-Stage-Startups — kassieren Sie vor oder bei jedem Meilenstein. Wenn dem Startup mitten im Projekt das Geld ausgeht, bedeutet Meilenstein-Abrechnung, dass Sie fuer alles bezahlt wurden, was Sie bisher geliefert haben.

Vorlagenlink

Nutzen Sie die App-Entwickler-Rechnungsvorlage fuer Meilenstein- und technische Einzelpositionen.

Speichern Sie Sprint-Zusammenfassungsschnipsel aus Ihrem PM-Tool als Rechnungsmemos, um Copy-Paste-Fehler zu reduzieren.

---

Frueher Zugang beitreten, um App-Arbeit ohne Vorlagenmueudigkeit abzurechnen.