MVP Entwicklung für Gründer und kleine Teams: Software und Hardware pragmatisch validieren

Eine MVP Entwicklung hilft Gründern, Solo-Unternehmern und kleinen Produktteams, eine Idee mit überschaubarem Umfang praktisch zu prüfen. Statt sofort ein vollständiges Produkt zu bauen, entsteht zunächst eine nutzbare erste Version für einen klar definierten Anwendungsfall. Das kann eine Web-App, ein SaaS-MVP, ein internes Tool, eine API oder ein IoT-Prototyp sein.

Der Nutzen liegt in der überprüfbaren Grundlage für Entscheidungen: Funktioniert der zentrale Workflow? Versteht die Zielgruppe das Angebot? Sind die technischen Voraussetzungen realistisch? Eine Demo liefert allerdings nur dann aussagekräftige Erkenntnisse, wenn sie mit der richtigen Nutzergruppe, einem geeigneten Test und klaren Messgrößen geprüft wird.

Was ist ein MVP in der Softwareentwicklung?

Ein MVP (Minimum Viable Product) ist eine nutzbare erste Version, die ein konkretes Kernproblem für eine klar definierte Zielgruppe löst. Bei der MVP Software Entwicklung wird nicht das gesamte geplante Produkt in unfertiger Form nachgebaut. Stattdessen wird ein begrenzter Produktbereich umgesetzt, der eine wichtige geschäftliche oder technische Annahme überprüfbar macht.

Für ein tragfähiges MVP-Konzept sind vier Fragen entscheidend:

• Welches Problem soll gelöst werden?
• Wer soll die Lösung nutzen?
• Welcher Ablauf ist für den Nutzen unverzichtbar?
• Welche konkrete Erkenntnis soll der erste Test liefern?

Ein MVP kann beispielsweise einen einzelnen Web-Workflow, eine zentrale SaaS-Funktion, ein Dashboard oder eine technische Schnittstelle abbilden. Bei Hardware kann es als vernetzter Prototyp mit ausgewählten Sensoren, Firmware und einer einfachen Oberfläche entstehen.

Nicht zwingend erforderlich sind in der ersten Version umfangreiche Rollenmodelle, seltene Sonderfälle, komplexe Automatisierungen oder vollständige Skalierungsmechanismen. Diese Bestandteile können später folgen, wenn sie durch Tests, Nutzung oder neue Anforderungen begründet sind.

Wann lohnt es sich, ein MVP entwickeln zu lassen?

Ein MVP entwickeln zu lassen ist besonders sinnvoll, wenn die Geschäftsidee technisch noch unklar ist oder im eigenen Team wichtige Kompetenzen fehlen. Das betrifft beispielsweise Produktpriorisierung, Backend-Entwicklung, Schnittstellen, Integrationen, Embedded Software oder Elektronik.

Ein externer Dienstleister kann dabei helfen,

• den Kern-Use-Case zu präzisieren,
• technische Risiken früh zu bewerten,
• Anforderungen in eine umsetzbare Reihenfolge zu bringen,
• eine funktionierende Demo zu entwickeln,
• Tests und Abnahmekriterien festzulegen und
• Quellcode sowie Dokumentation für die weitere Entwicklung vorzubereiten.

So kann ein MVP ohne eigenes Entwicklerteam entstehen, ohne von Beginn an eine vollständige Anwendung mit allen denkbaren Funktionen zu beauftragen. Wichtig sind dabei klare Anforderungen, direkte Kommunikation und sichtbare Zwischenergebnisse.

Vom MVP-Konzept zur funktionierenden Demo

Eine strukturierte Umsetzung lässt sich in mehrere Schritte gliedern.

1. Problem, Zielgruppe und Lernziel klären

Am Anfang stehen das konkrete Nutzerproblem, die Zielgruppe und der wichtigste Anwendungsfall. Das Lernziel sollte möglichst präzise formuliert werden. Beispiele sind:

• Nutzer können einen bestimmten Prozess vollständig digital durchführen.
• Ein interner Ablauf lässt sich messbar schneller bearbeiten.
• Eine Schnittstelle kann Daten zuverlässig übertragen.
• Ein Sensor erfasst Werte unter definierten Bedingungen.
• Eine Zielgruppe nutzt eine zentrale Funktion wiederholt.

2. Anforderungen und Risiken dokumentieren

Das MVP-Konzept beschreibt den Haupt-Workflow, die benötigten Datenquellen, externe Integrationen und technische Abhängigkeiten. Ergänzend werden Abnahmekriterien festgelegt. Sie beantworten die Frage, woran sich ein erfolgreicher erster Test erkennen lässt.

Technische Risiken können beispielsweise Datenqualität, Authentifizierung, Schnittstellen, Funkverbindungen, Messgenauigkeit oder die Verfügbarkeit bestimmter Bauteile betreffen.

3. Umsetzung und Integration

Je nach Vorhaben umfasst die erste Version eine Oberfläche, Backend-Logik, Datenmodell, Authentifizierung und externe Dienste. Bei einem Hardware- und Software-Prototyp kommen unter anderem Sensorik, Firmware, Stromversorgung, Datenübertragung und ein Testaufbau hinzu.

Entwicklung und Integration werden durch geeignete Tests ergänzt. Vor der Übergabe sollte die Demo unter den Bedingungen geprüft werden, unter denen sie auch von Nutzern, Stakeholdern oder internen Teams bewertet wird.

4. Test und nächste Entscheidung

Nach dem Test werden Nutzerfeedback, technische Ergebnisse und definierte Messgrößen ausgewertet. Daraus kann folgen, dass das Konzept angepasst, weiterentwickelt oder nicht weiterverfolgt wird. Eine Demo ersetzt dabei keine Marktanalyse und garantiert keinen späteren Produkterfolg. Sie verbessert lediglich die Entscheidungsgrundlage, wenn die Testbedingungen passend gewählt wurden.

Welcher MVP-Funktionsumfang ist sinnvoll?

Der MVP-Funktionsumfang sollte einen vollständigen Haupt-Workflow abbilden, der für das Kernproblem erforderlich ist. Bei einer einfachen Anwendung können Registrierung, zentrale Aktion und Ergebnisansicht ausreichen. Bei einer API kann der wesentliche Endpunkt mit Authentifizierung, Datenvalidierung und einer dokumentierten Antwortstruktur den relevanten Test ermöglichen.

Eine praktische Priorisierung teilt Funktionen in drei Gruppen:

Kategorie	Bedeutung
Unverzichtbar	Für den Kern-Workflow oder die wichtigste technische Prüfung notwendig
Sinnvoll für den ersten Test	Unterstützt die Nutzung, ist aber nicht für die Grundfunktion zwingend
Später ausbaubar	Erweiterung ohne unmittelbare Bedeutung für das erste Lernziel

Eine Funktion sollte kritisch geprüft werden, wenn sie weder das Kernproblem löst noch eine relevante Annahme testet. Erweiterte Personalisierung, komplexe Auswertungen, viele Rollen, seltene Sonderfälle und umfangreiche Automatisierungen können den Aufwand erhöhen, ohne den ersten Test wesentlich zu verbessern.

Die Begrenzung senkt nicht automatisch alle MVP Kosten. Sie schafft aber eine nachvollziehbare Grundlage, um Aufwand, Risiken und Prioritäten zu steuern.

MVP, Prototyp und Proof of Concept im Vergleich

MVP, Prototyp und Proof of Concept werden häufig gleichgesetzt, verfolgen aber unterschiedliche Ziele.

Ansatz	Hauptziel	Typisches Ergebnis
MVP	Einen zentralen Produkt-Workflow mit einer definierten Zielgruppe prüfen	Nutzbare erste Version
Prototyp	Bedienung, Ablauf, Bauform oder Zusammenspiel von Komponenten untersuchen	Vereinfachte Darstellung oder technische Annäherung
Proof of Concept	Eine zentrale technische Annahme nachweisen	Technischer Machbarkeitstest

Ein Software-Prototyp eignet sich, wenn Bedienung, User-Flow oder Interface noch unklar sind. Bei der Entwicklung eines Software-Prototyps müssen weder alle Datenstrukturen noch alle Betriebsprozesse produktionsnah umgesetzt werden.

Ein PoC ist sinnvoll, wenn ein technisches Risiko im Mittelpunkt steht, etwa eine Schnittstelle, ein Algorithmus, eine Datenübertragung oder ein bestimmtes Hardwareverhalten. Nutzerführung und fertige Produktqualität sind dabei meist nachrangig.

Ein MVP passt, wenn bereits ein real nutzbarer Ablauf mit einer klar definierten Zielgruppe geprüft werden soll. Die Auswahl sollte deshalb vom Lernziel abhängen, nicht allein vom verwendeten Begriff.

Web-App, API, internes Tool oder Hardware-Prototyp?

Die passende Form ergibt sich aus der Frage, wo der eigentliche Nutzen entsteht.

Produktform	Geeignet, wenn ...	Typische Schwerpunkte
Web-App	Nutzer einen browserbasierten Ablauf durchführen sollen	Oberfläche, Nutzerführung, Backend, responsive Darstellung
SaaS-MVP	Eine wiederkehrende Leistung für mehrere Nutzer oder Unternehmen angeboten wird	Konten, Datenmodell, Kernfunktion, gegebenenfalls Rollen und Abrechnung
API	Der Nutzen hauptsächlich in einer Systemanbindung oder Datenverarbeitung liegt	Endpunkte, Datenvalidierung, Authentifizierung, Dokumentation
Internes Tool	Ein interner Prozess effizienter oder nachvollziehbarer werden soll	Rollen, Arbeitsablauf, Datenzugriff, einfache Auswertung
Mobile App	Die Nutzung unterwegs oder gerätebezogene Funktionen entscheidend sind	Mobile Bedienung, Gerätefunktionen, Synchronisation
Hardware- oder IoT-Prototyp	Physische Messung, Steuerung oder Datenübertragung erforderlich ist	Sensorik, Firmware, Konnektivität, Backend und Testaufbau

Eine Web-App als MVP ist sinnvoll, wenn der Haupt-Workflow unabhängig von spezieller Hardware im Browser getestet werden kann. Eine API passt besser, wenn bereits andere Systeme oder Geräte als Nutzer der Lösung vorgesehen sind. Ein internes Tool eignet sich für Prozesse, bei denen zunächst der Nutzen im eigenen Unternehmen nachgewiesen werden soll.

Ein Hardware-Prototyp ist erforderlich, wenn die zentrale Annahme nur durch eine physische Messung, Steuerung oder Interaktion geprüft werden kann. Die Oberfläche allein würde in diesem Fall wichtige Risiken ausblenden.

MVP Kosten Deutschland: Welche Faktoren bestimmen den Aufwand?

Die Frage nach den MVP Kosten Deutschland lässt sich nicht seriös mit einem pauschalen Betrag beantworten. Entscheidend sind Produktform, Umfang, technische Risiken und die gewünschte Aussagekraft des Tests.

MVP-Typ	Wichtige Kostenfaktoren
Web-App	UX und Design, Frontend, Backend, Datenmodell, Authentifizierung, responsive Darstellung
SaaS-MVP	Nutzerkonten, Rollen, Mandantenfähigkeit, Kernfunktion, Hosting und gegebenenfalls Abrechnung
API	Schnittstellendesign, Datenvalidierung, Authentifizierung, Dokumentation und Integrationen
Internes Tool	Bestehende Systeme, Datenzugriff, Rollen, Prozesslogik und interne Sicherheitsanforderungen
Dashboard	Datenquellen, Schnittstellen, Datenaufbereitung, Visualisierung und Aktualisierung
Hardware- oder IoT-MVP	Bauteile, Platine, Gehäuse, Sensorik, Stromversorgung, Firmware, Funkverbindung und Testaufbau

Zusätzliche Aufwände können durch Datenschutzanforderungen, externe Dienste, besondere Sicherheitsanforderungen, Testgeräte, Prototypenfertigung oder die Dokumentation entstehen. Bei Hardware ist außerdem zu prüfen, ob Bauteile verfügbar sind und ob das gewählte Entwicklungsboard für den Test genügt.

Wer wissen möchte, wie viel ein MVP in Deutschland kostet, sollte zunächst folgende Informationen zusammentragen:

• Zielgruppe und Haupt-Workflow
• benötigte Plattformen
• unverzichtbare Funktionen
• vorhandene Datenquellen und Systeme
• externe Integrationen
• technische Risiken
• gewünschte Tests und Abnahmekriterien
• Anforderungen an Übergabe, Dokumentation und Betrieb

Wie lange dauert die Entwicklung eines MVP?

Die Dauer hängt vor allem vom Produkt-Slice und den Abhängigkeiten ab. Eine einfache Web-Anwendung mit einem klar begrenzten Workflow ist anders zu planen als ein SaaS-MVP mit mehreren Rollen, ein API-Projekt mit externen Systemen oder ein Hardware-Prototyp mit Firmware und Testaufbau.

Eine belastbare Grobschätzung kann in fünf Schritten entstehen:

1. Kern-Workflow und MVP-Funktionsumfang festlegen.
2. Integrationen, Datenquellen und technische Risiken erfassen.
3. Entwicklungs-, Integrations- und Testaufgaben aufteilen.
4. Abhängigkeiten wie Hardware-Lieferzeiten, Zugänge oder Freigaben berücksichtigen.
5. Verfügbare Kapazitäten, Feedbackschleifen und Übergabe einplanen.

Zeitaufwand entsteht nicht nur beim Programmieren. Auch Anforderungsklärung, UX, Einrichtung von Entwicklungs- und Testumgebungen, Qualitätssicherung, Datenschutzprüfung und Korrekturschleifen beeinflussen die Dauer.

Bei einem Hardware-Projekt können zusätzlich Bauteilbeschaffung, Platinenfertigung, Messreihen und Firmwaretests relevant sein. Deshalb ist eine Schätzung erst sinnvoll, wenn Produktform, Umfang und technische Randbedingungen bekannt sind. Pauschale Zeitversprechen ohne diese Informationen sind wenig belastbar.

Welche Technologie eignet sich für ein MVP?

Die Technologie sollte zum Lernziel, zur Zielgruppe und zum wichtigsten Workflow passen. Für eine MVP Web App können etablierte Frameworks und Standardkomponenten sinnvoll sein, wenn sie eine schnelle Anpassung und einen überschaubaren Betrieb ermöglichen. Ein kleines SaaS-MVP benötigt möglicherweise Benutzerkonten, ein passendes Datenmodell und eine klar begrenzte Backend-Logik.

Ein API-first-Ansatz eignet sich, wenn später mehrere Oberflächen, Geräte oder externe Integrationen auf dieselben Funktionen zugreifen sollen. Für einen frühen technischen Test müssen jedoch nicht alle Schnittstellen produktionsreif ausgebaut werden.

Bei Hardware richten sich Mikrocontroller und Einplatinencomputer nach den Anforderungen:

• ESP32: Geeignet für kompakte, vernetzte Geräte mit WLAN oder Bluetooth.
• STM32: Sinnvoll für hardwarenahe Steuerung, Energieeffizienz und kontrollierte Embedded-Systeme.
• Raspberry Pi: Praktisch für Linux-basierte Gateways, lokale Datenverarbeitung, Kameras oder bestimmte Industrieprototypen.

Unabhängig von der Technologie sollten Datenmodellierung, Code-Qualität und Dokumentation nachvollziehbar bleiben. Sicherheitsanforderungen, Datenschutz, vorhandene Teamkenntnisse und die spätere Übergabe des Quellcodes gehören ebenfalls in die Entscheidung.

IoT- und Hardware-Prototyping als MVP

Ein IoT-MVP besteht meist aus mehreren verbundenen Komponenten. Sensorik, Mikrocontroller, Embedded Software, Datenübertragung, Backend und Benutzeroberfläche müssen für den jeweiligen Test zusammenarbeiten. Auch Stromversorgung, Testumgebung und mögliche Gehäuse sollten früh betrachtet werden.

Ein ESP32-Prototyp kann Messwerte erfassen und beispielsweise an eine Weboberfläche übertragen. Beim IoT MVP mit ESP32 stehen häufig Konnektivität, Energiebedarf und die Zuverlässigkeit der Datenübertragung im Vordergrund.

Ein STM32-Prototyp eignet sich eher, wenn hardwarenahe Steuerung, Energieeffizienz oder definierte Echtzeitanforderungen relevant sind. Dann müssen Firmware, Schnittstellen und Testfälle genauer geplant werden.

Ein Raspberry Pi kann als Gateway oder als Plattform für lokale Datenverarbeitung dienen. Vor der Umsetzung sollten Bauteilverfügbarkeit, Funkverbindungen, Messgenauigkeit und spätere Fertigungsfragen geprüft werden. Ein technischer Prototyp soll die relevante Annahme untersuchen, aber noch nicht zwangsläufig die gesamte Serienhardware abbilden.

DSGVO, Datenschutz und Datensicherheit früh planen

Auch ein begrenztes MVP muss grundlegende Datenschutzanforderungen berücksichtigen. Für eine datenschutzkonforme Planung sollte zuerst geprüft werden, welche personenbezogenen Daten für den Kern-Workflow tatsächlich erforderlich sind.

Wichtige Punkte sind:

• Datenminimierung und Zweckbindung
• sichere Übertragung und angemessene Speicherung
• Rollen und Zugriffsrechte
• Authentifizierung
• Lösch- und Aufbewahrungskonzept
• Protokollierung im angemessenen Umfang
• Absicherung der Kommunikation zwischen Gerät, Backend und Oberfläche

Bei Analyse-, Sensor- oder Standortdaten können zusätzliche Anforderungen entstehen. Die konkrete rechtliche Einordnung sollte vor der Entwicklung mit fachkundiger Beratung geklärt werden. Sicherheitsmaßnahmen müssen zum Risiko des Projekts passen, sollten aber auch nicht ohne Grund eine vollständige Enterprise-Infrastruktur voraussetzen.

Woran erkennt man eine geeignete MVP-Agentur?

Eine geeignete MVP Agentur sollte die fachliche Idee, den Nutzer-Workflow und die technischen Risiken verständlich zusammenführen können. Sichtbare Arbeitsproben und nachvollziehbare technische Ergebnisse sind dabei aussagekräftiger als allgemeine Versprechen.

Vor dem Projektstart sollten mindestens folgende Punkte dokumentiert werden:

• Problem und Zielgruppe
• Haupt-Workflow
• MVP-Funktionsumfang
• technische Annahmen und Risiken
• Abnahmekriterien
• Zuständigkeiten und Kommunikationswege
• Umgang mit Änderungswünschen
• Übergabe von Quellcode, Dokumentation und Zugangsdaten

Je nach Vorhaben sollten Erfahrungen mit Web-Apps, SaaS, APIs, Embedded Software oder Hardware-Prototypen nachweisbar sein. Bei unklarer Machbarkeit ist außerdem wichtig, dass der Dienstleister technische Unsicherheiten offen benennt und nicht vorschnell eine vollständige Lösung verspricht.

TinyBuild: Leistungen und Zusammenarbeit

TinyBuild beschreibt sich als unabhängiges Software- und Hardware-Entwicklungsteam für Gründer und kleine Teams. Zum beschriebenen Vorgehen gehören eine kostenlose Erstberatung, die Klärung von Kernproblem und Zielgruppe sowie die Planung eines passenden technischen Produkt-Slices.

Je nach Vorhaben kann TinyBuild an einer Web-App, einem SaaS-Tool, Dashboard, internen Tool, einer API oder einem Embedded- und IoT-Prototyp arbeiten. Die Zusammenarbeit sollte vor Beginn klären, welche Funktionen umgesetzt werden, welche Annahmen geprüft werden und welche Ergebnisse am Ende übergeben werden.

Für eine sachliche Bewertung des Dienstleisters sind insbesondere folgende Punkte relevant:

• Passt die bisherige Arbeit zum geplanten Produktformat?
• Werden technische Risiken und Abhängigkeiten verständlich erklärt?
• Sind Umfang und Abnahmekriterien schriftlich festgehalten?
• Ist geregelt, wie Quellcode und Dokumentation übergeben werden?
• Gibt es einen nachvollziehbaren Prozess für Tests und Feedback?

Kostenlose Erstberatung anfragen, um die Idee, den passenden MVP-Typ und die technischen Rahmenbedingungen zu besprechen.

MVP weiterentwickeln: Von der Demo zum skalierbaren Produkt

Nach dem ersten Test sollte geprüft werden, welche Annahmen bestätigt wurden, wie die Zielgruppe die Lösung tatsächlich nutzt und welche technischen Probleme aufgetreten sind. Erst danach lässt sich sinnvoll entscheiden, ob und wie das MVP weiterentwickeln werden soll.

Mögliche nächste Schritte sind:

• bestätigte Funktionen verbessern,
• zusätzliche Nutzerrollen ergänzen,
• weitere Integrationen anbinden,
• Monitoring und Betrieb vorbereiten,
• Abrechnung oder Verwaltung ergänzen,
• Sicherheits- und Datenschutzmaßnahmen ausbauen,
• technische Schulden gezielt reduzieren.

Ein MVP ist kein fertiges Enterprise-Produkt und ersetzt keine vollständige Skalierungs- oder Betriebsplanung. Es kann jedoch die Grundlage für ein MVP skalierbares Produkt bilden, wenn Architektur, Sicherheit und Betrieb schrittweise an die bestätigte Nutzung angepasst werden. Nicht jede Funktion aus der ursprünglichen Produktvision muss dabei umgesetzt werden.

Fazit: Die passende erste Version planen

Eine gute MVP Entwicklung beginnt mit einem klaren Problem, einer definierten Zielgruppe und einem überprüfbaren Lernziel. Je nach Fragestellung kann die passende erste Version eine Web-App, ein SaaS-MVP, ein internes Tool, eine API, ein Prototyp oder ein IoT-System sein.

Ein begrenzter Funktionsumfang macht Aufwand und technische Risiken besser einschätzbar. Für die Planung der MVP Kosten Deutschland sind Produktform, Integrationen, Datenschutz, Tests und bei Hardware zusätzlich Bauteile, Firmware und Testaufbau entscheidend. Die Entwicklungsdauer sollte aus konkreten Aufgaben, Abhängigkeiten und verfügbaren Kapazitäten abgeleitet werden.

Nach einem geeigneten Test kann das MVP weiterentwickelt, angepasst oder verworfen werden. So entstehen weitere Investitionen auf Grundlage von Nutzerfeedback und technischen Erkenntnissen statt ausschließlich auf Basis einer ursprünglichen Produktidee.

FAQ

Welche Ergebnisse sollte ein MVP-Projekt am Ende liefern?

Am Ende sollten eine nutzbare erste Version, dokumentierte Abnahmekriterien, Testergebnisse sowie der vereinbarte Quellcode und die technische Dokumentation vorliegen. Bei Hardware gehören je nach Umfang auch Firmware, Schaltpläne, Bauteillisten und ein nachvollziehbarer Testaufbau dazu.

Wie misst man den Erfolg eines MVPs?

Der Erfolg wird anhand vorher festgelegter Messgrößen bewertet. Dazu können abgeschlossene Workflows, wiederholte Nutzung, Fehlerraten, Bearbeitungszeit, Datenqualität oder qualifiziertes Nutzerfeedback gehören. Entscheidend ist, ob das MVP die zentrale Annahme belastbar prüft.

Wie viele Nutzer sollte ein MVP testen?

Das hängt von der Fragestellung und Zielgruppe ab. Für erste qualitative Erkenntnisse genügt oft eine kleine, passende Gruppe. Für belastbarere quantitative Aussagen sind mehr Nutzer und klar definierte Vergleichs- oder Messmethoden erforderlich. Die Testgruppe sollte der späteren Zielgruppe möglichst entsprechen.

Was sollte in einem MVP-Angebot einer Agentur festgehalten werden?

Ein Angebot sollte Ziel und Zielgruppe, Haupt-Workflow, enthaltene und ausgeschlossene Funktionen, technische Annahmen, Meilensteine, Abnahmekriterien, Kostenmodell, Zuständigkeiten und Änderungsprozesse nennen. Auch die Übergabe von Quellcode, Zugangsdaten und Dokumentation sollte geregelt sein.

Welche laufenden Kosten entstehen nach der MVP-Entwicklung?

Nach der Entwicklung können Kosten für Hosting, Datenbanken, externe APIs, Lizenzen, Monitoring, Wartung, Support und gegebenenfalls Hardwaretests entstehen. Bei personenbezogenen Daten sind außerdem laufende Aufwände für Sicherheit, Backups und Datenschutzprozesse einzuplanen.

Wie verhindert man, dass ein MVP durch zusätzliche Wünsche zu groß wird?

Jede Funktion sollte darauf geprüft werden, ob sie den Kern-Workflow ermöglicht oder eine zentrale Annahme testet. Wünsche ohne direkten Beitrag zum Lernziel werden zunächst dokumentiert und priorisiert. Ein klarer Scope, feste Abnahmekriterien und regelmäßige Priorisierungsentscheidungen halten den Umfang steuerbar.