Guide · Updated 15 Sep 2026
How to choose a RedM script: ten checks before you pay for one
Most bad RedM script purchases were avoidable: a "supports RSG" label that meant untested, a config you cannot open, a resource that burns a millisecond a frame doing nothing, or an author who vanished after release. None of that is visible on a product card. All of it can be checked in ten minutes before you pay. These are the ten checks we would run on anyone's script, ours included, with what a good answer looks like.
The ten checks
| Check | A good answer | A red flag |
|---|---|---|
| 1. Framework | Names the frameworks and versions it was tested on | "Works with any framework" with no adapter or test mentioned |
| 2. Dependencies | A short, complete list on the page | Dependencies you find out about from a console error |
| 3. Performance | A resmon reading, idle and in use | "Optimised" with no number |
| 4. Open files | Config and translations readable | Everything escrowed, including the config |
| 5. Versions | A version number and a changelog with dates | No version anywhere |
| 6. Updates | Says how updates arrive and whether they are included | Silence, or a paid "v2" every few months |
| 7. Footage | Unedited in-game video of the real interface | Only mockups or stills |
| 8. Support | A Discord or ticket system with recent answers | A dead server, or support by DM only |
| 9. Database | Tables created or explained; says what it writes | A SQL file that drops or alters tables it did not create |
| 10. Author | A history of releases that are still maintained | A new account with one release and a big discount |
1. Framework claims
"Supports VORP, RSG and QBCore" can mean three very different things: one build that detects the framework at runtime, three separate downloads, or a VORP script with a handful of RSG exports added and never run on RSG. Ask which, and ask whether it has been tested on a live server on each. Money, inventory capacity and job events behave differently on each framework, and a script that has not been run there will find out on your players.
How ours answer: every Poggy script is one build that talks to the framework through the free Poggy Core (Free), which has a separate adapter for VORP Core, RSG Core and QBCore RedM, each proven on a live server. Where a feature is VORP-only, the product page says so under "Works with".
2. Dependencies
Every resource a script needs should be on its page before you buy: inventory, menu library, target system, notification resource, database driver. Each extra dependency is one more thing to keep updated and one more start-order problem. Scripts that depend on unlicensed libraries are a problem you inherit.
How ours answer: Poggy Markets ($99) and Auction House ($29.99) need poggy_core and oxmysql, and nothing else. No vorp_menu, no vorp_inputs; poggy_core draws menus, inputs and notifications itself.
3. Performance
Open the F8 console on a client and type resmon. An idle script should sit at or very near 0.00 ms; anything above 0.10 ms while nothing is happening is polling every frame. Ask the author for a screenshot or a video with resmon open, idle and in use. A script is allowed to cost something while its menu is open; it is not allowed to cost something while you ride past it. RedM server performance covers what to do about the ones you already run.
4. What is left open
Paid scripts are normally escrowed, and that is fine. What matters is what the author left out of escrow. Job names, locations, prices and every player-facing string must be yours to change, so config.lua and translation files should be readable; the interface often is too. A script with an escrowed config is a script you can only run the way its author's server does. Cfx escrow explained goes through what to look for.
How ours answer: config and translation files are never escrowed, and every product page says what is open under "Open where it matters". Poggy Core (Free) and Poggy Storage (Free) are fully readable.
5 and 6. Versions and updates
A version number is the only way to know what you are running and whether a fix has reached you. Look for a changelog with dates. Then look for how an update gets to your server: re-download from the portal and merge by hand, or something better. And check whether updates are included in what you pay, or sold again as a new version.
How ours answer: every script page shows the current version and the date it was last updated, read from the same public update feed poggy_core installs from. Updates are included, and poggy_core installs them with your config merged. See how to update RedM scripts.
7. Real footage
Unedited video of the actual interface in game, with the actual framework's HUD, is hard to fake. Polished renders, mockups and stills of a menu are easy. If a script has no in-game footage at all, ask for some. An author whose script works has it.
8. Support
Join the author's Discord before buying and read the support channel. You are looking for recent questions with answers, not a wall of unanswered pings. Support by DM only means nobody else can see how problems get handled. Support for every Poggy script is in the Rosewood Ridge Discord.
9. What it does to your database
Read the SQL before running it. A script should create its own tables and leave everyone else's alone. DROP TABLE or ALTER TABLE on a framework table is a reason to stop. Take a backup first regardless; how to back up a RedM server covers it.
How ours answer: tables are created or extended automatically when a script starts, with CREATE TABLE IF NOT EXISTS and added columns only, so there is nothing to import and nothing is dropped.
10. The author
A script is a relationship, not a download: it needs updates when the framework changes. An author with two years of maintained releases is a safer bet than a new account with one script at half the usual price.
Leaked and "free" copies of paid scripts
Every popular paid script turns up somewhere for free. It is the most expensive way to get one.
- It breaks the author's licence and Cfx.re's terms. Your server key and account are what is at risk.
- No updates, ever. The first framework change breaks it, and nobody fixes it.
- No support. You cannot open a ticket for a copy you did not buy.
- Backdoors are common. A modified resource can give a stranger console access, read your database credentials from
server.cfg, or wait months before doing anything. You cannot audit an escrowed file, and people who repackage leaks are not doing it for your benefit.
The same caution applies to scripts thrown together quickly and sold on volume: code that was generated or copied and never run on a live server tends to fail on the first edge case, such as a full satchel, a player who disconnects mid-trade, or a second framework. Checks 3, 7 and 8 catch most of it.
If you want free, go properly free
There are good free RedM scripts, released by their authors on GitHub or the Cfx.re forum. Free RedM scripts worth installing lists ours, with the limits of each.
