Vor-dem-Kauf-Checkliste: Warnsignale, Lizenzbedingungen & Benchmarks

Einleitung: Das Falsche zu kaufen kostet mehr als Geld

Wenn du das falsche FiveM-Skript kaufst, vergeutest du nicht nur Geld – du erbst Ausfallzeiten, Chargebacks, FPS-Beschwerden und einen Support-Aufwand. Nutze diese Seite als dein Vor-dem-Kauf-Gate: Prüfe den Anbieter, entschlüssele die Lizenz, prognostiziere die Performance und vergleiche Rückerstattungs-/Update-Bedingungen, bevor du einen Cent ausgibst.

Dieser Guide ist Teil unserer umfassenden FiveM-Skripte-Ressource, in der du alle unsere Skriptempfehlungen, Framework-Vergleiche und Kaufratgeber findest.

Verwandte Lektüre (in neuen Tabs öffnen):

• Wie man FiveM-Skripte evaluiert, testet und wartet — Pillar-Prozess für Sandboxing, CI und langfristige Pflege: https://vertexmods.com/blog/maintain-fivem-scripts
• FiveM Asset Escrow: Grenzen, Mythen und Umgehungsmöglichkeiten — was du kannst/nicht kannst, wenn Code gesperrt ist: https://vertexmods.com/blog/pre-purchase-checklist

---

TL;DR — Schnelle Vor-dem-Kauf-Checkliste

Anbieter & Reputation

• Juristische Person aufgeführt (Name, Land, Registrierung oder USt-IdNr.).
• Aktiver Support (Discord/Ticket/E-Mail) mit Antwortzeit < 24h.
• Öffentliches Changelog; letztes Update < 60 Tage.
• Keine ungelösten Betrugs-/Leak-Threads zum Verkäufer.

Lizenz & Richtlinien

• Kommerzielle Nutzung und Multi-Admin-Nutzung auf deinem Server erlaubt.
• Rückerstattungsfenster (≥ 7 Tage) mit objektiven Kriterien.
• Update-Richtlinie (lebenslang oder klare Haupt-/Neben-Regeln).
• FiveM Asset Escrow-Bedingungen dokumentiert; performance-kritische Teile bearbeitbar; kein verstecktes Telemetrie/Remote-Code-Execution ohne Signaturen.

Performance & Kompatibilität

• Resmon Durchschnitt < 0,10 ms, p99 < 0,50 ms unter erwarteter Last.
• Kein DB N+1; wichtige Abfragen indiziert; Timeouts behandelt.
• Framework-Support angegeben (ESX/QBCore/QBOX) und Artifact/Versions-Bereich.
• Keine schweren globalen Event-Handler, keine engen while true-Schleifen.

---

1) Anbieter-Due-Diligence (Warnsignale vs. Positivzeichen)

Positivzeichen

Positivzeichen

• Registriertes Unternehmen, USt-/Steuer-ID, Land auf der Storefront sichtbar.
• Öffentliches Changelog und Issue-Tracker; häufige kleine Updates > seltene große.
• Klare Produktgrenzen (kompatible Frameworks, getesteter Server-Build).
• Support-SLAs: erste Antwort <24h, Bugfix-ETA-Richtlinie, Sicherheits-Patch-Richtlinie.

Warnsignale

• Neuer Shop, keine Identität, nur DMs für Support.
• „Keine Rückerstattungen jemals" + keine Demo und kein Test-Server.
• „Lebenslange Updates"-Behauptung, aber kein Changelog oder aktuelle Commit-Historie.
• Reputation verknüpft mit Leaks, Bans oder massenhaften DMCA-Streitigkeiten.

Übrigens: Wenn ein Skript Open Source ist, ist es meistens von hoher Qualität.

Anbieter-Audit-Vorlage (Kopieren/Einfügen)

Feld | Wert --- | --- Anbietername | Storefront-URL | Discord/Support-URL | Juristische Person / Reg.-Nr. / USt-IdNr. | Land | Alter des Shops (Monate) | Durchschnittliche Antwortzeit | Update-Kadenz (Tage) | Öffentliche Changelog-URL | Preis / Zahlungsmethoden | Abhängigkeiten (ESX/QBCore/etc.) | Getesteter Server-Build | Rückerstattungsrichtlinie (Zusammenfassung) | Garantie / SLA | Risikohinweise |

JSON-Schema (in deinen Tracker einfügen):

{

"vendorName": "", "storeUrl": "", "support": { "discord": "", "email": "", "slaHours": 24 }, "legal": { "entity": "", "regNo": "", "taxId": "", "country": "" }, "reputation": { "disputesOpen": 0, "notes": "" }, "changelogUrl": "", "updateCadenceDays": 30, "product": { "priceEUR": 0,

    "dependencies": ["ESX", "ox_lib"],
    "artifactTested": ">= 6148",
    "frameworks": ["ESX", "QBCore"]
  },

"policies": { lua

    "refund": { "windowDays": 7, "conditions": ["not as described", "critical bug"] },
    "updates": "lifetime",
```lua
```lua
    "escrow": { "enabled": true, "editableFiles": ["config.lua"] }
  },
  "riskScore": 0,
  "notes": ""
```lua
```lua
}

* * *

## 2) Lizenzklausel-Spickzettel (Entschlüsseln vor dem Kauf)

Klausel | Gut sieht so aus | Warnsignale
--- | --- | ---
**Nutzungsumfang** | Kommerzielle Nutzung auf käufereigenen Servern; unbegrenzte Spieler | „Nur für den persönlichen Gebrauch", Per-IP-Sperre, vages „nicht kommerziell"
**Sitze/Instanzen** | Pro Server/Org mit Offline-Modus bei DRM | Pro-CPU/Maschinen-DRM, bricht bei Host-Migration
**Änderungen** | Konfigurations-Änderungen erlaubt; Quell-Änderungen wo Escrow nicht erforderlich | „Keinerlei Änderungen; Änderungen setzen Support außer Kraft"
**Asset Escrow** | Klare Liste von **unverschlüsselten** Dateien; performance-kritische Teile bearbeitbar; Fallback-Pfad | Alles gesperrt; Remote-Prüfungen; keine Methode zur Performance-Optimierung
**Updates** | Lebenslang oder versionierte Richtlinie ausgeschrieben (z. B. v1.x kostenlos) | „Nach Belieben" bezahlte Updates; kein Sicherheits-Patch-Engagement
**Rückerstattungen** | ≥ 7-Tage-Fenster; objektive Kriterien; Prozess dokumentiert | Pauschal „keine Rückerstattungen", keine Demo/Test-Server
**Telemetrie** | Opt-in, Zwecke & Datenkategorien aufgeführt, Toggle in Konfiguration | Versteckte Telemetrie, Geräte-Fingerprinting, ausgehend beim Start
**Haftung/Garantie** | Bug-/Sicherheitsgarantiezeitraum; Best-Effort-SLA | Vollständiger Haftungsausschluss, jederzeit kündbar, kein Rechtsbehelf
**Kündigung** | Kündigungsfrist + Abhilfefrist | Sofortige Kündigung nach alleinigem Ermessen

## Tipp: Wenn Escrow verwendet wird, bestätigen, welche Lua/NUI-Dateien bearbeitbar bleiben

**Tipp:** Wenn Escrow verwendet wird, bestätigen, **welche Lua/NUI-Dateien bearbeitbar bleiben** (Konfigurationen, Übersetzungen, performance-kritische Schleifen) und ob der Anbieter **Profiling-Ratschläge** gibt. Wenn nicht, Punkte zum Risiko-Score hinzufügen.

* * *

## 3) Rückerstattungs- & Update-Richtlinie — Vergleichs-Arbeitsblatt

**Was festzuhalten ist**

*   **Rückerstattungsfenster & -bedingungen:** objektive Prüfbarkeit („nicht wie beschrieben", reproduzierbarer kritischer Bug).
*   **Update-Richtlinie:** lebenslang vs. Haupt vs. Neben; bezahlte Upgrades; Sicherheits-Patches garantiert.
*   **Übertragbarkeit:** Kannst du die Lizenz übertragen, wenn du den Server verkaufst?
*   **Auto-Updates:** Liefermechanismus und Rollback-Plan.

Anbieter | Rückerstattungsfenster | Bedingungen | Anfragemethode | Update-Richtlinie | Bezahlte Upgrades? | Sicherheits-Patch-Richtlinie | Übertragungen erlaubt? | Hinweise
--- | --- | --- | --- | --- | --- | --- | --- | ---

* * *

## 4) Performance-Risikomodell (Entscheiden vor dem Commit)

**Akzeptanzziele**

*   **Server-CPU (Resmon Durchschnitt):** < **0,10 ms** im Leerlauf & typische Nutzung; **p99 < 0,50 ms** unter Burst.
*   **Client-FPS-Delta:** Baseline vs. mit Ressource **≥ −5 FPS** auf Mid-Range-GPU.
*   **DB-Disziplin:** kein N+1; Indizierung auf Fremdschlüsseln; **Timeouts behandelt**.
*   **NUI:** Input→Paint < **100 ms**; keine blockierenden `fetch`-Schleifen.
*   **Tick-Sicherheit:** keine schwere Arbeit auf globalen Events; `while true do`-Busy-Waits vermeiden; Timer verwenden.

**Vom Anbieter anzufordernde Nachweise**

*   Kurzes **Resmon**-Video/Screenshots unter geskripteten Szenarien (Leerlauf, 8 Spieler führen die [Core](https://vertexmods.com/brand/core/ "Core")-Aktion durch).
*   **Explain/Analyze** für schwerste Abfragen; Index-Plan zeigen.
*   NUI-Performance-Erfassung (DevTools-Performance-Panel).
*   Konfigurations-Toggles, die Draw Calls oder Netzwerk-Spam reduzieren.

* * *

## 5) Sicherheit & Compliance (Keine Backdoor importieren)

## Voraussetzung: Kein Remote-Code-Execution / loadstring

**Voraussetzung:**

*   Kein Remote-Code-Execution / `loadstring` aus HTTP ohne **Signaturverifizierung**.
*   Keine versteckte Analytics oder Geräte-Fingerprinting (nur Opt-in, klare Datenkategorien).
*   Klare [Handhabung](https://vertexmods.com/blog/how-to-change-vehicle-handling "FiveM Vehicle Handling Editor") für Keys/Aktivierung im Offline-Modus.
*   Keine Credential-Sammlung; kein Discord-Token-Harvesting; kein „Anti-Leak", das wie Malware agiert.

**Warnsignale:** Binäre Blobs mit Netzwerkaufrufen, verschleierte HTTP-Endpunkte, „Phone-Home" beim Start oder „Anti-Leak", das Staff/Admin-IPs bannt.

* * *

## 6) Preis & ROI (Total Cost of Ownership)

**TCO-Formel (grob):**
`TCO = Preis + (Bezahlte Updates über 12 Monate) + (Abhängigkeitslizenzen) + (Mitarbeiterzeit für Integration & Tuning) + (Erwartete Ausfallzeitkosten)`

Wenn TCO > Alternative TCO um 30% bei gleichen Features/Perf, nicht kaufen.

* * *

## 7) Entscheidungsrahmen (Bestehen/Nicht bestehen + Risiko-Score)

**Harte Ablehnungen (automatisch abgelehnt)**

*   Kein Rückerstattungsfenster **und** kein Demo/Test-Server.
*   Versteckte Telemetrie oder Remote-Code ohne Signaturen.
*   Letztes Update > 6 Monate für geschäftskritische Ressourcen.

**Risiko-Score (0–100, niedriger ist besser)**
Jede Achse 0–20 bewerten, summieren:

1.  Anbieter & Reputation
2.  Lizenz & Richtlinien
3.  Performance & DB-Disziplin
4.  Sicherheitsposition
5.  Kompatibilität & Wartung

> **Go/No-Go-Regel:** Nur kaufen, wenn **Score ≤ 40** und **keine harten Ablehnungen**.

* * *

## 8) Druckfertige Checklisten & Arbeitsblätter

Du kannst direkt aus den obigen Tabellen arbeiten oder das strukturierte Workbook herunterladen (mehrere Blätter: **Checkliste**, **Anbieter-Audit**, **Lizenzklauseln**, **Rückerstattungen\_Updates**, **Performance-Risiken**):

[fivemx-prepurchase-checklist](https://cdn.vertexmods.com/wp-content/uploads/2025/08/fivemx-prepurchase-checklist.xlsx)[Herunterladen](https://cdn.vertexmods.com/wp-content/uploads/2025/08/fivemx-prepurchase-checklist.xlsx)

## Damit Anbieter nebeneinander vergleichen und Nachweise aufbewahren

Damit Anbieter nebeneinander vergleichen und Nachweise (Screenshots, Test-Clips) aufbewahren.

* * *

## 9) Wie Ansprüche nach dem Kauf validiert werden

*   Dem End-to-End-Test-Flow in **[Wie man FiveM-Skripte evaluiert, testet und wartet](https://vertexmods.com/blog/maintain-fivem-scripts)** folgen — eine **Test City**-Sandbox aufbauen, Baseline vs. Ressourcen-Metriken erfassen und ein Changelog führen.
*   Wenn Escrow vernünftiges Tuning blockiert, den Risiko-Score überprüfen und **[FiveM Asset Escrow](https://vertexmods.com/blog/pre-purchase-checklist)** für sichere Umgehungsmöglichkeiten einsehen.

* * *

## Anhang A — Kopieren/Einfügen „Vor-dem-Kauf-Checkliste" (kompakt)

\- \[ \] Anbieteridentität verifiziert (juristischer Name, Land, USt-IdNr./Reg.-Nr.)
\- \[ \] Aktiver Support & SLA (<24h erste Antwort)
\- \[ \] Öffentliches Changelog; letztes Update <60 Tage
\- \[ \] Klare Frameworks & Artifact-Versionen angegeben
\- \[ \] Lizenz: kommerzielle Nutzung erlaubt; Instanzen geklärt
\- \[ \] Lizenz: Änderungen erlaubt (Konfiguration + performance-kritische Bereiche)
\- \[ \] Asset-Escrow-Bedingungen dokumentiert (bearbeitbare Dateien aufgelistet)
\- \[ \] Rückerstattungsfenster ≥7 Tage mit objektiven Kriterien
\- \[ \] Update-Richtlinie definiert (lebenslang/haupt/neben), Sicherheits-Patches garantiert
\- \[ \] Keine versteckte Telemetrie; kein Remote-Code ohne Signaturen
\- \[ \] Resmon Durchschnitt <0,10 ms; p99 <0,50 ms
\- \[ \] Kein DB N+1; Indizes auf FKs; Timeouts behandelt
\- \[ \] NUI Input→Paint <100 ms; keine blockierenden Schleifen
\- \[ \] Keine schweren globalen Handler; keine heißen `while true`-Schleifen
\- \[ \] TCO innerhalb von 30% der besten Alternative

* * *

## Anhang B — Lizenzklausel-Überprüfung (Ausfüllen)

| Klausel | OK? | Hinweise |
| --- | --- | --- |
| Kommerzielle Nutzung erlaubt |  |  |
| Sitze/Instanzen klar |  |  |
| Änderungen erlaubt |  |  |
| Asset-Escrow-Umfang klar |  |  |
| Rückerstattungsfenster & -prozess |  |  |
| Update-Richtlinie & Sicherheits-Patches |  |  |
| Telemetrie nur Opt-in |  |  |
| Haftung/Garantie angegeben |  |  |
| Kündigung mit Abhilfefrist |  |  |

* * *

## Abschicken: Checkliste ausführen, Risiko-Score zuweisen

**Abschicken:** Checkliste ausführen, Risiko-Score zuweisen und nur fortfahren, wenn er besteht. Wenn etwas vage wirkt, ist es ein **Nein**.

## Bonus: Vertrauenswürdige Tebex-Shops

> [Die besten Tebex-Shops für FiveM](https://vertexmods.com/blog/best-tebex-shops)