What to send before you ask for a quote

"How much for a drug system?" is not a question anyone can answer. Depending on what you meant, it is an afternoon or three weeks. So the developer either asks ten questions, or he prices the worst case. Both cost you time or money.

Five minutes of writing gets you a real number.

The five things that matter

• Your setup. Framework and version, whether you run ox_inventory, ox_lib or ox_target, and anything else the script will have to touch.
• What it does, as a list. Short sentences, one behaviour each. "Player picks up the item at X", "item cannot be sold back within an hour", "police get a notification above quantity Y".
• What it must not do. This is the part people skip and it is where the arguments come from. "Must not use the standard inventory notification", "must not be usable from a vehicle".
• Scale. How many players are online at peak, and how many will be using this at once. A script for 20 players and one for 200 are different scripts.
• Who maintains it after. If it is you, say so, and expect the config to be built accordingly.

Include the failure cases

Half the work in any script is what happens when things do not go cleanly. Say what should happen when the player logs out mid-action, when two people trigger it at the same time, when the database is briefly unavailable, when someone tries it from a vehicle or from inside a wall.

You do not need answers for all of them. Listing the ones you care about tells the developer which edge cases are worth building for and which he can handle with the obvious default.

Pictures beat paragraphs

For anything with an interface, a rough sketch, a screenshot of something similar, or a link to a video of the behaviour you want removes more ambiguity than a page of description. Mark what you want different from the reference. "Like this, but the list is on the left and there is no timer" is a spec.

A template you can copy

• Framework: ESX Legacy, latest, with ox_inventory and ox_lib.
• Peak players: around 60.
• What it does: [list of behaviours, one per line]
• What it must not do: [list]
• Interface: [sketch, screenshot or reference link, with what should differ]
• Edge cases I care about: [logout mid-action, two players at once, ...]
• Who maintains it after delivery: me, so I need the config documented.
• Deadline: [date, or none]
• Budget range: [range, if you have one]

About sharing your budget

There is a common belief that naming a budget means you will be charged all of it. In practice the opposite happens more often: without a range, the developer designs the version he thinks you want, which is usually bigger than the version you would have picked. A range lets him tell you what fits in it, and what the next tier would add.