Written for the evening a resource will not start, the week the server starts to feel slow, and the point where you give up waiting and write the thing yourself.
A resource can meet today's needs while leaving tomorrow's customization uncertain. When comparing scripts here, describe the extension you intend to build and check what the product actually exposes. A feature shown in a demonstration is not automatically a supported integration point.
Every article here started as a problem on a live server. They cover getting QBCore up from nothing, reading a console error that names no file and no line, working out what hardware a build actually needs, and keeping a city responsive once every resource on it is fighting for the same tick. Read them in any order. None of them assumes you read the last one.
Most FiveM problems are dependency problems in disguise. A resource that refuses to start, a script throwing on a nil value, a job that works for the owner and for nobody else: those trace back to load order, a missing library or a framework version that moved, far more often than to broken code. Start with the manifest. What fxmanifest.lua declares, and the order it declares it in, explains a surprising share of the failures that look like something else entirely. From there the QBCore troubleshooting guide walks the errors that come up most on a QB build, and the quick reference covers the console messages worth recognising on sight. Players cannot connect at all? Different problem, different checklist.
Performance is about what runs every frame. It is not about how much is installed, which is the assumption that sends owners uninstalling the wrong things. Wait loops are where most of the budget goes, and a badly written resource will bill you frames while absolutely nothing is happening on the map. One guide covers reading resmon honestly instead of trusting the number you hoped for. A longer one covers running heavy scripts beside each other without any of them collapsing. Underneath both sits hosting, which splits in two: the specifications your build genuinely needs, and whether a VPS, a dedicated box or a cloud instance is the right shape for it.
Half of what goes wrong with a paid script is decided before checkout. There is a checklist for vetting one before it touches your server, and it is worth running on the free ones too. Especially the free ones. Escrow versus open source explains what asset protection really stops you doing, and it is a harder trade than the forum arguments make it sound. After installation the habits that save the most grief are dull ones: edit the config so the next release cannot quietly erase your work, and test every update on a staging copy rather than on the server your players are sitting on. First script? Start with the beginner's install guide.
ESX and QBCore split this catalogue. Sooner or later somebody wants to run a resource written for the other one, and the migration tutorial covers what translates cleanly, what has to be rewritten by hand, and the database work people forget about until it bites them halfway through a migration weekend. Beside it sits the ox_lib guide. That shared library is what most of both catalogues now depends on, and it is the most common missing dependency in FiveM by a distance. Already know which side you are on? The QBCore shelf, the ESX shelf and the Qbox shelf are filtered for you.
Plenty of owners started by editing somebody else's resource and finished by writing their own. NUI from scratch builds an in-game panel out of ordinary HTML and a pair of message handlers. The debugging guide gets you into the real Chromium DevTools, which is the only way to find out why a panel came up blank with no error anywhere. The custom phone walkthrough is the long version, with React. Around those sit pcall and stack traces, world UI with blips and markers, skill checks that create tension rather than a loading screen, and keybinds a player can actually remember.
The pieces here are worth reading before you need them rather than after. Protecting a server from exploits is the obvious one. The less obvious one is keeping API keys out of server.cfg and out of your git history, which is how a live Discord token ends up in a public repository and a server ends up belonging to somebody else. There is also a piece on store domains that spell the name correctly and change only the ending. That is how most owners get caught. Came here to install something rather than to read? The full catalogue, the category index and the free shelf are a click away.