DEV Community: Alina Mueller

How I Built a FiveM Mod Marketplace with Next.js 16 and Stripe

Alina Mueller — Sat, 11 Apr 2026 20:38:09 +0000

Building a FiveM mod marketplace from scratch is not your typical Next.js project. When I started working on VertexMods, I quickly realized that the usual e-commerce patterns don't fully translate to the gaming modding space. Here's what I learned.

The Stack

Before we dive in, here's the full tech stack:

Next.js 16 (App Router, React Server Components, PPR)
PostgreSQL + Drizzle ORM (75 tables, full-text search via tsvector)
Clerk for authentication
Stripe + Coinbase Commerce for payments
Cloudflare R2 for mod file storage
TypeScript strict mode throughout

Why FiveM Mods Are Different

FiveM is a multiplayer modification framework for GTA V. Server owners run custom Lua scripts (called "resources") that add gameplay features — economy systems, vehicles, jobs, weapons, UI menus. These scripts range from free community projects to premium $50+ packages.

The marketplace has to handle:

Instant digital delivery — buyers expect the download link immediately after payment
Guest checkout — many server owners don't want to create accounts
Two payment methods — traditional Stripe + crypto via Coinbase (the gaming community loves crypto)
Free mods with monetized links — Linkvertise/LinkHub for free downloads

Stripe + Instant Downloads

The trickiest part was the download flow. We use Stripe Checkout sessions with webhook verification:

// src/app/api/webhooks/stripe/route.ts
export async function POST(req: Request) {
  const sig = req.headers.get('stripe-signature')!;
  const body = await req.text();

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch (err) {
    return new Response('Webhook signature verification failed', { status: 400 });
  }

  if (event.type === 'checkout.session.completed') {
    await handleSuccessfulPurchase(event.data.object as Stripe.Checkout.Session);
  }

  return new Response('OK');
}

For guest users, we generate encrypted download tokens with a 7-day expiry:

// Encrypted token for guest downloads — no account needed
const token = await encrypt({
  orderId: order.id,
  productIds: order.items.map(i => i.productId),
  expiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000,
});

Next.js 16 + PPR

We're on Next.js 16 with Partial Pre-Rendering (PPR) enabled via cacheComponents: true. This replaced all the old unstable_cache patterns with "use cache" directives:

// Product listing page — static shell + dynamic personalization
async function ProductGrid({ locale }: { locale: string }) {
  "use cache";
  cacheLife("hours");
  cacheTag("products");

  const products = await getPublishedProducts();
  return <Grid products={products} />;
}

The shop page now serves from cache in ~50ms while the cart/auth state hydrates client-side. That's a real win for Core Web Vitals.

Drizzle ORM + Full-Text Search

PostgreSQL full-text search powers the mod discovery. We use a generated tsvector column with a GIN index:

// schema/products.ts
export const products = pgTable('products', {
  id: uuid('id').primaryKey().defaultRandom(),
  title: text('title').notNull(),
  description: text('description').notNull(),
  searchVector: customType<{ data: string }>({
    dataType: () => 'tsvector',
  })('search_vector').generatedAlwaysAs(
    sql`to_tsvector('english', title || ' ' || description)`
  ),
}, (t) => [
  index('products_search_idx').using('gin', t.searchVector),
]);

Querying is clean:

const results = await db
  .select()
  .from(products)
  .where(sql`search_vector @@ plainto_tsquery('english', ${query})`)
  .orderBy(sql`ts_rank(search_vector, plainto_tsquery('english', ${query})) DESC`);

Cloudflare R2 for Mod Files

R2 stores the actual ZIP files. Presigned URLs expire after 15 minutes to prevent link sharing:

// src/lib/r2.ts
export async function getDownloadUrl(key: string): Promise<string> {
  const command = new GetObjectCommand({ Bucket: process.env.R2_BUCKET_NAME!, Key: key });
  return getSignedUrl(r2Client, command, { expiresIn: 900 }); // 15 min
}

The R2 bucket is private — no public access. Downloads always go through our API which validates the token first.

Multi-Language with next-intl

The marketplace supports 4 locales: English (no prefix), German (/de), French (/fr), and Brazilian Portuguese (/pt-br).

English URLs are canonical without prefix — /shop not /en/shop. This is a common source of SEO bugs; make sure your sitemap, hreflang tags, and middleware all agree on this.

Creator Marketplace

Beyond just selling our own mods, we built a creator platform where independent FiveM developers can list their scripts. Creators earn 70% of revenue, we take 30%. Stripe Connect handles payouts.

The flow:

Creator applies → admin reviews
Creator submits product for review
Admin approves → product goes live
Buyer purchases → creator gets 70% via Stripe Connect payout

Lessons Learned

Webhooks are hard in development. We built a zero-config webhook setup that automatically starts the Stripe CLI listener with pnpm dev and writes the secret to .env.local. No more manual setup.

PPR with auth is tricky. Static cache can't include user-specific data. The pattern that works: cache the product data, render auth state client-side with a Suspense boundary.

Guest checkout UX matters. A huge percentage of server owners will abandon checkout if forced to create an account. Guest checkout with email-based download tokens was worth the extra complexity.

The full marketplace is live at vertexmods.com if you want to see it in action.

Questions? Drop them in the comments. I'm happy to go deeper on any part of the stack.

How to Choose Quality FiveM Scripts for Your Roleplay Server

Alina Mueller — Mon, 16 Mar 2026 16:31:05 +0000

You've seen it happen. Someone installs a new script — looks great in the preview video — and suddenly the server is lagging, players are getting kicked, and the console is spewing errors nobody knows how to read. The script gets blamed, gets removed, and an hour of admin time is gone.

Picking FiveM scripts well is a real skill. Here's how to actually do it.

Framework Compatibility First

Before anything else: know your framework and be strict about it.

ESX, QBCore, and QBox are not interchangeable. Scripts written for one often won't work on another without modification, and "conversion" ports range from clean rewrites to barely functional hacks. Always confirm what framework a script targets before you download anything.

A few things to check:

ESX scripts should reference ESX:getSharedObject or exports['es_extended']:getSharedObject(). If you see ESX = nil at the top, that's the old initialization pattern — it works but signals an older, less-maintained codebase.
QBCore scripts use exports['qb-core']:GetCoreObject() or the newer exports.qb-core:GetCoreObject(). Watch for scripts that claim QBCore support but are just ESX conversions with a thin wrapper.
QBox is a fork of QBCore with breaking changes in the item and inventory systems. Scripts that haven't been updated for QBox's item metadata changes will break your inventory.

If a script's README doesn't clearly state framework compatibility and tested version numbers, treat that as a red flag.

Reading Code Quality Signals

You don't need to be a Lua expert to spot problematic code. A few things to scan for:

Database calls in loops. Look for exports.oxmysql:execute or MySQL.Async.execute inside for loops or event handlers that fire frequently. Every loop iteration hitting the database is a performance disaster waiting to happen.

while true do loops without proper waits. Every permanent loop needs a Citizen.Wait() call. A loop with Citizen.Wait(0) runs every frame for every player. This tanks performance. Loops with no wait at all will crash the thread.

Global variable pollution. If the script defines dozens of globals instead of using local variables, that's sloppy code that can conflict with other resources.

No dependency checking. Good scripts verify their dependencies exist at startup and print clear errors if something's missing. Scripts that just silently fail or throw cryptic errors when a dependency isn't loaded waste your time debugging.

The cfx.re forum has decent discussions on what good Lua practices look like — searching for "resource optimization" there turns up useful threads. GitHub is also worth checking: a script with regular commits, a proper issue tracker being used, and a changelog is a much safer bet than one with a single commit from two years ago.

Testing Before Production

Never install directly to a live server. This should be obvious, but a lot of server owners skip this step because setting up a test environment feels like work.

A basic test setup doesn't need to be elaborate — a local FiveM server with the same framework version as your production server is enough. Install the script, connect with a test account, and put it through the full user flow: trigger every event, use every item, run every job. Watch the server console for errors the entire time.

Specifically watch for:

attempt to index a nil value — usually means a framework function or export wasn't found
^1SCRIPT ERROR — any script error in production is a problem, even if it "seems fine"
Resource monitor (resmon command) — check the resource's ms usage during active use. Anything consistently above 0.5ms per frame for a single resource is worth investigating.

Where to Find Scripts Worth Installing

The quality spread is enormous. The free section of the cfx.re forum has everything from excellent community contributions to scripts that haven't been updated since 2019. You'll need to read through the thread, check the release date, see if the author responds to bug reports, and make your own judgment call.

For paid scripts, VertexMods is worth a look — the listings include framework compatibility info and the scripts go through a review process before being sold. Tebex is the other major marketplace; same advice applies: check the reviews, check when it was last updated, check if the seller responds to support questions.

If you want to build jobs without writing code from scratch, the VertexMods Jobs Creator tool generates ESX/QBCore/QBox job configs — useful if you're standing up new jobs quickly. For free mods, vertexmods.com/free-mods has a curated catalog alongside the usual cfx.re forum hunting.

The Shortcuts That Bite You

A few things server owners do that consistently cause problems:

Installing scripts without reading the SQL file. Some scripts add columns to core tables or create tables with the same name as something you already have. Always read the SQL before running it.

Trusting client-side validation. Scripts that only validate actions on the client are exploitable. If a script has no server-side checks on critical actions (giving items, triggering payouts, accessing menus), players will find the exploits.

Skipping the changelog. When you update a script, read what changed. Framework updates sometimes change function signatures or deprecate events. A script that worked fine six months ago might need config changes after an update.

The servers that run smoothly long-term aren't the ones with the most scripts — they're the ones where every installed resource was actually evaluated before it went live.