FiveM Realtor and Property Jobs: Listings, Viewings, Rent and a Housing Market Players Actually Trade

Every server I have watched install a housing script runs the same three weeks. Week one, the dozen players with savings each buy a place from a menu. Week two, everybody else works out that the good ones are gone. Week three, the housing channel in Discord is one long thread asking whether Dave still plays, because Dave owns the Vinewood house and has not logged in since the summer update. The script is fine. The market is dead, and it died because buying a home took one keypress and zero conversation. A fivem realtor job puts a human being back in the middle of that transaction, which sounds like adding friction and is really adding a reason to log in.

This covers what a realtor does that an automated buy menu cannot, the two ways to run the economy underneath it, how to price the entry tier so a week-one player is not locked out, rent as the sink that stops hoarding, keys and tenancy, listings, dormant property, the abuse patterns, and how to bolt all of it onto interiors you already stream.

What a realtor job does that a /buyhouse menu cannot

A menu can transfer money and write a row. That is the entire list. Everything else that makes property interesting is a conversation, and conversations need two players.

Viewings are the obvious one. A realtor meets a buyer outside, opens the door on a timer, walks them through the kitchen, and answers questions about the neighbours. Mechanically this is a temporary access grant that expires, not a key: ten minutes of entry whether or not they buy. That one feature turns an interior from a loading screen into a place someone has stood in and formed an opinion about.

Then there is negotiation. If the listed price is the final price, you have built a vending machine with extra steps. Let the realtor accept offers inside a band, say ten percent either side of list, and two players suddenly have something to argue about with real money attached. Add a contract signed at the office and a deposit held for 48 hours and you have a job with verbs in it instead of a permission flag. Most housing and property systems already store everything you need for this. What they lack is the person.

Server-owned stock or player-to-player resale?

Pick one of these deliberately, because they produce completely different cities and mixing them badly produces neither.

Server-owned stock Player-to-player resale
Who sells The state, at a fixed price Whoever owns the place
Realtor earns Salary plus a per-sale bonus Commission, typically 3 to 5 percent
Price discovery None. You set it in config Emergent, and sometimes silly
Money supply Sales destroy cash, which is good Cash moves sideways, sinks come from tax
Fails when Stock runs out and nothing recycles Four people corner the market

The hybrid holds up longest: the server sells only the entry tier at a fixed price and never buys back at full value, while everything above that is player-to-player with the realtor taking commission. New players keep a route in that no cartel can close, and the interesting stock stays in player hands where the drama lives.

Whichever you choose, pay commission into a society account rather than the realtor’s pocket and let the boss run payroll from it. You get a paper trail for free, and that trail is what saves you during a dispute two months later.

Setting price bands so a new player can afford a flat in week one

Do not copy another server’s price list. Their trucking payout is not your trucking payout, and a number lifted from a forum config is how you end up with a $2,000,000 studio nobody has ever seen the inside of.

Derive it instead. Pull a week of payout logs, find the median hourly earnings across your three most-used jobs, and anchor the entry tier at roughly four to six hours of that. Two evenings of work should be enough to sign for a room. Everything above that is a multiple of the same base number:

-- example only. Replace with numbers derived from YOUR payout logs.
local base = 12000  -- roughly 4 hours of median job income

Config.PriceBands = {
    room     = { min = base * 1,  max = base * 3  },  -- Sandy Shores trailer, shared apartment
    flat     = { min = base * 3,  max = base * 8  },  -- Vespucci, Mirror Park
    house    = { min = base * 8,  max = base * 25 },  -- Rockford, Del Perro
    estate   = { min = base * 25, max = base * 90 },  -- Vinewood Hills, status purchase only
}

The top band is not meant to be affordable, only visible, so the mechanic grinding for a Mirror Park terrace has something to point at. Keep the entry band permanently stocked and never let it sell out, even if that means the server prints a new trailer park in Sandy Shores every few weeks. Grim, realistic, and it keeps the door open.

Rent, keys and what a tenant actually gets

Ownership with no ongoing cost is a ratchet. Property only ever accumulates, and within a month your map is a museum of houses owned by people who quit.

Charge weekly upkeep at one to two percent of purchase price, billed on a real-world timer rather than on login, so nobody dodges it by not playing. Then make the second property cost more than the first. Escalating upkeep is the most effective anti-hoarding lever I know, and it is about four lines of code:

  • First property pays base upkeep.
  • Second pays double.
  • Third pays quadruple, and there is no fourth.
  • Missed payment gives a seven day grace period with a phone notification on day one, day three and day six.
  • After grace, the door locks and the stash freezes. Nothing is deleted, because deleting a player’s belongings over unpaid rent is how you generate a Discord thread with 200 replies.

Frozen is the important state. It is reversible, it is visibly a consequence, and it gives the player a reason to come back and sort it out. Deleted is final and generates a ticket. Frozen generates a story.

Access to the place is the other half of tenancy, and it should be a table of grants rather than an item in an inventory. A key item gets dropped, duplicated by a dodgy inventory script, and sold by accident. A row with an owner, a property, a permission level and an expiry does not.

Three tiers cover almost everything. The owner can sell, set rent and grant keys. A tenant can enter, use the stash and store a vehicle, with the grant expiring at the end of the lease. A guest can enter while the grant lasts and touch nothing, which is what a viewing hands out. Wire door access through ox_doorlock or your framework equivalent and check the same grants table for stash access, because the classic bug in every homegrown housing system is the evicted tenant who can no longer open the front door and can still empty the wardrobe. On QBCore, read this deep dive on QBCore housing before you design the schema: qb-houses is deprecated and most servers moved to ps-housing, which already gates property creation behind a job.

Log every grant and revoke with both citizen IDs and a timestamp to a Discord webhook. When someone claims their stuff vanished, that log is worth more than any other feature here.

Where players find listings

A listing nobody reads is not a listing. Publish the same data in two places and make one of them physical.

The office board is the one people underrate. A prop at the realty office with a target zone on it, listing price, district and the realtor to contact, gives players a place to stand and a reason to bump into each other. Rockstar already handed you the in-fiction branding, so lean on Dynasty 8 signage instead of inventing a brand nobody recognises. Put a “For Sale” prop outside the property while it is listed and half your marketing is done.

The phone app is the other half. Most modern phone resources have a marketplace or classifieds section that will take a listings feed, and a weekly newspaper or radio slot gives the realtor a reason to spend money on advertising. Keep one listings table as the source of truth and let every surface read from it. Two tables drift within a fortnight, guaranteed.

What happens when the owner stops logging in

You need a dormancy rule, written down before you need it, and it has to apply to staff. That last part is where most servers detonate.

Something like this works: 45 days without a login flags the property, 60 days posts it to a public reclaim list, 75 days returns it to market. Everything inside the stash moves to an escrow container the player can claim on their next login for another 30 days, and the sale value goes to their bank account rather than evaporating. Nobody loses anything except the address.

Announcing it is a separate skill. Pin the policy weeks before the first reclaim, with the exact day counts in it, and post the pending list publicly seven days ahead so friends can tag the owner. Run the very first pass on a staff member’s house with a screenshot, because a rule the admins are visibly subject to is a rule people argue with far less. Do it quietly and by surprise and you will spend a fortnight explaining yourself instead of running events.

The three abuse patterns, and the admin load behind them

Alt-account hoarding comes first. Cap ownership on the strongest identifier you have rather than per character, and require two identifiers to match before you treat two accounts as separate people. A player with three characters should still be capped across all of them, otherwise multi-character support quietly becomes a property multiplier.

Flipping is second. Somebody will buy every entry-tier unit the instant it lists and resell at triple. Cheap defences stack well here: a resale cooldown of a real week after purchase, a transfer tax around ten percent on player-to-player sales, and a server buy-back paying roughly 70 percent of purchase price so dumping stock is never free money. None of that bans trading. It makes churn cost something.

Realtor self-dealing is third and the one people forget. A realtor who can create a listing, price it and buy it has been handed a money printer with a job title. Block the realtor from buying any listing they created, log every price change with the acting citizen ID, and add a cooling-off window between a listing going up and going live so someone else sees it first.

Behind all three sits the admin load, the real cost of running a property market. Most disputes are seller’s remorse rather than a bug. Write one policy line before launch, close to “trades are final unless the transaction log shows a script error”, and hold it. With both logs in place the average dispute becomes a 90 second lookup instead of a 40 minute argument about who said what in a DM.

Wire it to housing you already have

Do not model interiors. That is a different job, it takes weeks, and the result will be worse than assets that already exist. Point the realtor system at shells for standalone units and at streamed MLOs for apartment blocks and mansions, then spend your time on the market layer. If the difference between the two formats is fuzzy, this breakdown of FiveM shells and MLOs covers what each costs you at runtime, which decides how many properties your server can carry.

For shells, put each instance in its own routing bucket so twenty players in twenty copies of the same interior never see each other. For MLOs, the interior already exists in the world and your job is only the door, the grants check and the stash. Either way the FiveM realtor job stays a thin resource: a listings table, a viewing grant with an expiry, a sale transaction, a commission split, and a logger. That is a weekend of work on top of a housing script you already paid for.

Where to start

Build the FiveM realtor job in this order. Listings table and office board first, so property becomes visible. Viewings second, because that is the feature that creates conversations. Rent third, once there is enough owned property for a sink to matter. Dormancy last, with the policy published a month before the first reclaim.

Get that sequence right and nobody has to ask whether Dave still plays. His old place will be back on the board, with a realtor standing next to it explaining that the neighbours are lovely and the previous owner left in a hurry.