So baust du einen Angebotsrechner mit Lovable

Mit Lovable lässt sich ein Angebotsrechner bauen, indem du deine Dienstleistungspreise in feste Regeln gießt, ein mobil optimiertes Formular erstellst und einen Anfrage-Workflow anbindest. Ein scharf umrissenes Pilotprojekt passt locker in ein Wochenende, solange du auf Zahlungen, Terminplanung und komplizierte Integrationen verzichtest. Diese Anleitung liefert dir das Preismodell, den Prompt zum Kopieren, ein Budget und passende Tests.

Die wirklich brauchbare Version ist kein Chatbot, der deine Preise errät. Es ist eine schlanke App für deine Kundschaft, die eine zentrale Kaufentscheidung beantwortet: "Was kostet das ungefähr, und wie frage ich es an?"

Was dein Angebotsrechner können sollte

Starte mit einer Dienstleistung, deren Kalkulation du auf einem Blatt Papier vorrechnen kannst. Gebäudereinigung, Rasenpflege, Hochdruckreinigung oder Fahrzeugaufbereitung eignen sich gut, sofern die Variablen vorhersehbar bleiben.

Ein Renovierungsangebot, das Gegebenheiten vor Ort, Genehmigungen und Subunternehmer einbezieht, ist eine ganz andere Liga. Baue dafür ein normales Erfassungsformular, kein vorgebliches Sofortangebot.

In diesem Beispiel dient ein Reinigungsunternehmen mit festem Einsatzgebiet als Grundlage. Kunden geben ihre Postleitzahl ein, wählen Wohnungsgröße sowie Reinigungsturnus, buchen bei Bedarf eine Backofenreinigung dazu und sehen direkt eine Schätzung. Anschließend können sie ein verbindliches Angebot anfordern.

Der Rahmen für das Wochenende umfasst einen Rechner, ein Anfrageformular und eine Prüfliste fürs Team. Keine Kundenkonten. Kein Kalenderabgleich. Keine automatischen Rabatte, die sich ein Sprachmodell ausdenkt.

Passt dieser Ablauf nicht zu deinem Betrieb, wirf einen Blick auf die Ideen für Kleinunternehmens-Apps, bevor du mit dem Bauen beginnst.

Schreib zuerst die Preisregeln auf

Die folgenden fiktiven Preise veranschaulichen die Struktur. Ersetze sie vor der Veröffentlichung durch deine echten Tarife.

| Eingabe oder Regel | Beispielhafte Preislogik | |---|---| | Basis-Standardreinigung | 120 $ | | Wohnungsgröße: 1-1.000 Quadratfuß | Kein Aufpreis | | Wohnungsgröße: 1.001-2.000 Quadratfuß | Plus 30 $ | | Wohnungsgröße: 2.001-3.000 Quadratfuß | Plus 60 $ | | Wohnungsgröße über 3.000 Quadratfuß | Manuelle Prüfung erforderlich | | Backofenreinigung | Plus 25 $ | | Wiederkehrende Reinigung | 10 % Rabatt nur auf Basispreis und Größenaufpreis | | Außerhalb des Einsatzgebiets | Keine automatische Schätzung |

Für ein Haus mit 1.500 Quadratfuß inklusive Backofenreinigung und Dauerservice lautet die Rechnung:

`($120 + $30) × 0,90 + $25 = $160`

Der Zusatzposten Backofen wird vom Folgerabatt ausgenommen. Genau solche Details sind wichtig. Eine unklare Anweisung wie "Stammkunden bekommen 10 % Rabatt" führt schnell zu einem fehlerhaften Rechner.

Definiere auch Ausschlüsse. In diesem Beispiel sind Grundreinigungen, Gefahrenstellen und Umzugsreinigungen ausgeschlossen. Zeige den Hinweis "Geschätzter Preis, vorbehaltlich Bestätigung" direkt neben dem Ergebnis an, nicht versteckt in der Fußzeile.

Kläre vor dem Start, wie du Steuern abbildest. Das obige Rechenbeispiel enthält noch keine Steuern. Formulierungen und Logik müssen den rechtlichen Vorgaben deines Marktes entsprechen.

Wochenend-Fahrplan und realistische Kosten

Liegt eine fertige Preisliste vor, reichen 12-16 fokussierte Arbeitsstunden für einen Piloten. Wer sich parallel erst in Authentifizierung, Datenbanken und Deployment einarbeiten muss, plant lieber ein zweites Wochenende ein.

Stand Oktober 2026 solltest du nicht erwarten, dass das Builder-Abo sämtliche Ausgaben für Deployment, Datenbanken oder E-Mails abdeckt. Prüfe Inklusivleistungen und nutzungsbasierte Abrechnungen, bevor du kostenpflichtige Dienste verknüpfst. Die Zahlen unten sind Richtwerte zur Budgetierung, keine offiziellen Paketpreise von Lovable.

| Arbeitsschritt | Zeitansatz | Ergebnis | |---|---:|---| | Freitag: Umfang und Preise klären | 2 Stunden | Preisliste, Ausschlüsse, Akzeptanztests | | Samstag: Rechner aufbauen | 4-5 Stunden | Funktionierendes Formular mit Kalkulation | | Samstag: Speicher für Anfragen anbinden | 2-3 Stunden | Gespeicherte Daten, geschützter interner Zugang | | Sonntag: Testen und nachbessern | 3-4 Stunden | Geprüfte Berechnungen, Rechte, Mobilansicht | | Sonntag: Piloten veröffentlichen | 1-2 Stunden | Live-Link und Teameinweisung |

Finanziell solltest du 30-60 $ für einen Monat Tool-Zugang und Iterationen einplanen, dazu 10-40 $ für Hosting mit wenig Traffic, Datenbank und E-Mail-Dienste. Manche Konfigurationen bleiben komplett im kostenlosen Rahmen. Andere überschreiten diesen Betrag, vor allem wenn du die App mehrfach komplett neu generieren lässt.

Damit liegt ein vorläufiges Softwarebudget für den ersten Monat bei 40-100 $, exklusive Steuern, eigener Arbeitszeit, Domains und externer Unterstützung. Gleiche die tatsächlichen Gebühren mit der Preisübersicht von Lovable und den angebundenen Anbietern ab. Richte überall Warnschwellen für den Verbrauch ein, wo es möglich ist.

Eine eigene Domain ist für den Testlauf optional. Ein einfacher Link auf deiner bestehenden Website genügt, um zu sehen, ob Kunden den Rechner überhaupt nutzen.

Rechne auch deinen eigenen Zeitaufwand mit ein. Bei einem angenommenen Stundensatz von 40 $ kostet ein Projekt von 12-16 Stunden zwischen 480 $ und 640 $ an Arbeitszeit. Wenn ein fertiges Formular-Tool deine Tarife und Weiterleitungen sauber abbildet, ist der Kauf einer fertigen Lösung oft die wirtschaftlichere Wahl.

Lovable lohnt sich dann, wenn du eine maßgeschneiderte Benutzerführung oder Rechenlogik verlangst, an der Standardformulare scheitern. Individuelle Software ist nicht automatisch die günstigere Software.

Den Rechner in Lovable bauen

1. Rechner ohne Integrationen generieren

Beginne mit dem öffentlichen Formular und Beispieldaten. Trenne es von echten Kundendaten, bis die Rechenlogik alle Tests besteht.

Füge diesen Prompt in Lovable ein:

```text Build a mobile-first quote calculator for a fictional house-cleaning business.

Scope:

• Public estimator, no customer login.
• No payments, booking calendar, chatbot, or external integrations yet.
• Use USD and integer cents for all money calculations.
• Keep pricing rules separate from UI components.

Inputs:

• Five-digit ZIP code, stored as text.
• Home size band: 1-1000, 1001-2000, 2001-3000, above 3000 sq ft.
• Frequency: one-time or recurring.
• Oven cleaning: yes or no.

Demo rules:

• Supported ZIP codes: 10001 and 10002.
• Base price: 12000 cents.
• Size surcharge: 0, 3000, or 6000 cents for the first three bands.
• Recurring discount: 10% of base plus size surcharge only.
• Oven cleaning: 2500 cents, never discounted.
• Round discount amounts to the nearest cent.
• Unsupported ZIP or above 3000 sq ft: show manual estimate required.
• Never show a numeric estimate for unsupported requests.

Results:

• Show a clear itemized breakdown.
• Say: Estimated service price, subject to confirmation.
• Explain that deep cleaning, hazardous conditions, and move-out work are excluded.
• Mark tax wording as a pre-launch configuration item.
• Show the estimate before asking for contact details.
• Include a Request confirmation button and a draft contact form.
• Do not claim a request was sent while no backend exists.

Quality:

• Accessible labels, keyboard navigation, visible focus states.
• Preserve inputs after validation errors.
• Include unit tests for all pricing branches.
• Test: 1500 sq ft, recurring, oven selected = 16000 cents.
• List unresolved launch requirements after building.

```

Die Demo-Postleitzahlen sind Platzhalter, kein Adressprüfungs-System. Tausche sie aus und teste Grenzgebiete, bevor du Kunden darauf loslässt.

2. Die generierte Berechnung prüfen

Bitte Lovable, die Preisfunktion zu isolieren und deren Eingaben, Ausgaben, Rabattreihenfolge sowie Rundungslogik zu erklären. Vergleiche diese Erklärung mit deiner Preistabelle.

Lass anschließend die Tests laufen. Eine automatisch generierte Test-Suite übernimmt mitunter dieselben Denkfehler wie der erzeugte Code. Prüfe deshalb einige Beispiele von Hand nach.

Halte Änderungen klein: Korrigiere erst die Rabattregel, überprüfe sie und wende dich dann dem Formular zu. Wenn du Hilfe beim Formulieren brauchst, wirf einen Blick in die Prompt-Bibliothek.

3. Speicher für Anfragen und Team-Zugang einrichten

Binde ein Backend an, das zu deiner Projektkonfiguration passt. Supabase bietet sich für Datenbank und Authentifizierung an. Verlass dich dabei nicht auf feste Menüschritte aus alten Tutorials, sondern folge dem aktuellen Ablauf in Lovable.

Speichere die gewählten Optionen, den Schätzbetrag, die Preisversion, den Zeitstempel der Übermittlung, Kundennamen, E-Mail-Adresse, optionale Telefonnummer und den Status der Anfrage. Halte Notizfelder optional und weise Nutzer darauf hin, keine sensiblen Daten einzutragen.

Der Submission-Handler auf dem Server muss die Eingaben zwingend validieren und den Preis serverseitig neu berechnen. Vertraue niemals einem Preis, den der Browser mitschickt. Ein Request lässt sich manipulieren, selbst wenn die Summe auf dem Bildschirm unveränderlich wirkt.

Setzt du auf Supabase, aktiviere Row-Level Security und richte eine strikt begrenzte Mitarbeiterrolle für Lesezugriffe ein. Anonyme Besucher dürfen unter keinen Umständen Kundendaten abrufen. Ein bloßer Login reicht nicht aus, um internen Zugriff zu erhalten.

Lass Lovable diese Beschränkungen einbauen und teste sie mit getrennten Accounts sowie direkten API-Aufrufen. Ein versteckter Admin-Link ist keine Sicherheitsmaßnahme.

Speichere die Anfrage erst vollständig ab, bevor du eine Bestätigung anzeigst. Ein Schutz vor doppelten Einsendungen und serverseitige Ratenbegrenzungen verhindern, dass mehrfaches Tippen oder Bots die Datenbank fluten.

4. Benachrichtigungen ganz zum Schluss

Stelle zuerst sicher, dass neue Anfragen zuverlässig in der geschützten Team-Ansicht landen. Binde erst danach Transaktions-Mails an und behalte API-Schlüssel strikt auf dem Server.

Eine Benachrichtigung ans Team sollte lediglich eine Vorgangsnummer und einen Link zur internen Übersicht enthalten, statt Kundendaten im Klartext per Mail zu verschicken. Schlägt der Mailversand fehl, muss die Anfrage trotzdem sicher gespeichert und einsehbar bleiben.

Die Bestätigung für Kunden sollte präzise beschreiben, was als Nächstes passiert: "Deine Anfrage ist eingegangen. Wir bestätigen den Preis innerhalb eines Werktags." Versprich ein solches Zeitfenster nur, wenn im Betrieb auch jemand verbindlich für diesen Posteingang zuständig ist.

Testen und einen kleinen Piloten starten

Ein schicker Ergebnisbildschirm ist noch kein Beleg für Reife. Erst stimmige Preise, geschützte Daten und sauberes Fehler-Handling machen das System startklar.

Preis-Tests durchführen

Prüfe anhand der fiktiven Regeln folgende Ergebnisse:

| Testfall | Erwartetes Ergebnis | |---|---:| | 800 sq ft, einmalig, kein Ofen | 120 $ | | 1.500 sq ft, einmalig, mit Ofen | 175 $ | | 1.500 sq ft, wiederkehrend, mit Ofen | 160 $ | | 2.500 sq ft, wiederkehrend, kein Ofen | 162 $ | | Über 3.000 sq ft | Manuelle Prüfung erforderlich | | Nicht unterstützte Postleitzahl | Manuelle Prüfung erforderlich |

Prüfe ebenso die Übergänge zwischen den Größenstaffeln. Falls du die Staffeln später durch freie Zahleneingaben ersetzt, teste 1.000, 1.001, 2.000, 2.001, 3.000 und 3.001 ganz gezielt.

Sende eine manipulierte Anfrage mit einer künstlich reduzierten Summe ab. Das Backend muss diesen Betrag ignorieren und selbst nachrechnen. Bei nicht unterstützten Aufträgen sollte das System eine Anfrage zur manuellen Prüfung anlegen, ohne eigenmächtig Fantasiepreise festzusetzen.

Checkliste vor dem Go-Live

• [ ] Alle fiktiven Preise, Postleitzahlen und Unternehmensdaten austauschen.
• [ ] Leistungsausschlüsse, Rabattregeln und steuerliche Angaben gegenprüfen.
• [ ] Das Layout auf einem echten Smartphone testen.
• [ ] Das Formular komplett ohne Maus nur per Tastatur durchspielen.
• [ ] Sicherstellen, dass normale Besucher keine fremden Anfragen einsehen können.
• [ ] Prüfen, dass reguläre Nutzerkonten keinen Zugriff auf interne Team-Daten haben.
• [ ] Verifizieren, dass keine API-Schlüssel oder Secrets im Client-Code landen.
• [ ] Datenbankausfälle, fehlschlagenden Mailversand und doppeltes Absenden testen.
• [ ] Datenschutzerklärung veröffentlichen und Löschfristen festlegen.
• [ ] Optionale Marketing-Einwilligungen sauber von der eigentlichen Service-Anfrage trennen.
• [ ] Eine feste Person im Team für eingehende Anfragen und Reaktionszeiten bestimmen.
• [ ] Bestehende Kontaktkanäle wie Telefon oder Standard-Formulare weiterhin bereithalten.

Schicke den Rechner an fünf bestehende Kunden, bevor du ihn in der Hauptnavigation verlinkst. Bitte sie, ohne Anleitung ein realistisches Szenario durchzurechnen. Achte darauf, wo Größenstaffeln verwirren oder unklar bleibt, welche Leistungen inbegriffen sind.

Lass den Rechner anschließend zwei Wochen lang im Pilotbetrieb laufen. Miss Interaktionen: Wie viele starten den Rechner, wie viele sehen ein Ergebnis, wie viele schicken eine Anfrage ab, wie viele Aufträge entstehen daraus? Vergleiche die Schätzungen mit den finalen Auftragssummen. Namen oder E-Mail-Adressen haben in Tracking-Events nichts verloren.

Nehmen wir an, 100 Nutzer starten den Rechner, 60 sehen eine Schätzung und 12 senden eine Anfrage ab. Das entspricht einer Abschlussquote von 60 % bis zur Schätzung und einer Quote von 20 % von der Schätzung zur Anfrage. Das sind Rechenbeispiele, keine festen Branchen-Benchmarks.

Entscheidend bleibt, ob das Tool qualifizierte Anfragen liefert und deinen manuellen Aufwand senkt. Schau dir die ersten 20 Anfragen im Detail an. Weichen die Endpreise regelmäßig um mehr als deine Toleranzgrenze ab, etwa um 15 %, passe die Regeln an oder wechsle zu einer transparent kommunizierten Preisspanne.

Reagiere auf ein unpassendes Preismodell nicht mit noch mehr KI. Korrigiere stattdessen das Preismodell.

Kann Lovable einen Angebotsrechner ganz ohne Programmierkenntnisse bauen?

Ja, Lovable kann Oberfläche und Rechenlogik rein aus Textanweisungen erstellen. Trotzdem musst du Preise, Backend-Berechtigungen und das Deployment-Verhalten eigenständig kontrollieren. Fehlt dir die Erfahrung, um Zugriffsrechte auf Kundendaten zu beurteilen, zieh vor dem Livegang jemanden mit technischem Hintergrund hinzu.

Sollte eine KI über den Preis einer Dienstleistung entscheiden?

Für diesen Rechner auf keinen Fall. Verlass dich auf deterministische Regeln, die von der Geschäftsführung freigegeben sind. KI eignet sich hervorragend, um die App zu bauen oder erklärende Texte zu formulieren. Zur Laufzeit darf sie jedoch weder Zuschläge, Rabatte noch vertragliche Zusagen frei erfinden.

Kann ein Angebotsrechner in Lovable Zahlungen annehmen?

Ja, über eine passende Payment-Integration ist das machbar. Im ersten Piloten sparst du dir diesen Schritt besser. Sobald die Schätzungen zuverlässig sitzen, kannst du einen separaten Bezahlschritt für den bestätigten Endpreis ergänzen, inklusive transparenter Storno- und Rückerstattungsbedingungen. Belaste Kundenkonten niemals automatisch auf Basis einer unverbindlichen Schätzung.