Krenno
All projectsCase study
SaaSGaming2025WebCloud WorkerHeadless Browser

CSGO Item Trading Bot

Give serious CS2 traders a command desk, not another spreadsheet of missed listings.

A supervised trading desk that finds, scores, and acquires CS2 skins before the listing window closes.

Client

Krenno Labs

Engagement

internal product

Duration

16 weeks

Team

3 people

Krenno roleProduct strategyUX and design systemFrontend engineeringBackend and real-time systems+3 more
Positioning

Why this product exists

CSGO Item Trading Bot concentrates strategy, session security, listing intelligence, and one-click start/stop control into a single product. Operators set the rules once. The engine watches the book, prefers the lowest-markup eligible skin, and executes the marketplace withdraw sequence while the trader watches the tape in real time.

CSGO Item Trading Bot proves Krenno can design and ship a complete trading-operations product: authenticated SaaS surfaces, real-time control, and a resilient automation engine that survives messy third-party marketplaces. It shows we can take a high-stakes, time-sensitive workflow and turn it into a polished product a client can run, supervise, and extend. The next client who needs marketplace automation, operator consoles, or fintech-grade control rooms gets that same product discipline.

Built for

  • CS2 skin traders who need disciplined, always-on coverage of peer-to-peer listings
  • Trading desks and inventory operators who manage buy-side rules across price bands
  • Marketplace power users who want supervised automation instead of brittle desktop macros
  • Gaming-economy companies that need a credible trading-ops product with auth, telemetry, and worker isolation
The story

Challenge, approach, solution

01

The Challenge

CS2 skins move on peer-to-peer marketplaces in seconds. Traders compete against other humans and bots while juggling price bands, markup ceilings, session expiry, consent banners, and multi-step withdraw confirmations. A missed overlay or a stale login burns the window. Spreadsheets and ad-hoc scripts cannot give an operator a trustworthy desk: they lack identity, live telemetry, recoverable sessions, and a product surface a team can actually run. The market needed a finished operations platform that treats skin acquisition as a supervised trading workflow, not a hidden script.

02

Our Approach

Krenno split the product into two tightly coupled surfaces. The operator workspace is a Next.js application with authenticated routes, a trading dashboard, strategy configuration, account security, and a live console. The execution layer is an isolated Node.js worker that drives a stealth-hardened headless browser, reads strategy from a shared cloud database, and streams progress over WebSockets. We designed the information architecture first: landing and onboarding, sign-in, command desk, settings, profile, and terminal. Then we engineered the worker as a state machine that can start, pause, recover from overlays, and stop on command without leaving orphaned browsers in the cloud.

03

The Solution

CSGO Item Trading Bot is a live CS2 trading desk. Operators authenticate, configure maximum markup and min/max price, attach a marketplace session, and start the engine from the terminal. The worker loads the withdraw market, proves the session, applies filters, ranks selectable item cards by markup, and walks the checkbox, withdraw, and confirmation dialogs. Every step is visible in the console with connection health, start/stop, reconnect, and color-coded event language. The result is a coherent product: strategy, identity, telemetry, and execution in one system.

Experience

The Experience

A trader lands on a cinematic onboarding surface with product story, tutorial video, and a clear path into the desk. After sign-in they reach a trading dashboard: balance and activity framing, bot status, and shortcuts into the console and settings. In Bot Settings they lock a markup ceiling, price envelope, and session cookie behind an edit/save workflow with toast confirmation. The Trading Bot Console feels like an operations terminal: connection pulse, auto-scroll, start, stop, clear, and reconnect. When the engine is live, the tape fills with login state, popup clearance, filter application, item selection, and purchase confirmation. Profile and recovery flows keep the account side of the product as considered as the trading side.

Product

What we built into the product

Live Trading Operations Console

A full-height operator terminal streams worker events in real time, with connection state, auto-scroll, start/stop command control, reconnect, and semantic coloring for success, warning, and failure so the desk never goes dark during a run.

Rule-Based Acquisition Engine

Operators define maximum markup and a min/max price envelope. The engine applies those rules to the live marketplace book and prefers the lowest-markup eligible listing inside the band.

Marketplace Session Orchestration

Authenticated sessions are stored with the strategy record and injected into a hardened browser context, with explicit login detection so the desk can tell the operator to refresh credentials before a wasted run.

Headless Listing Intelligence

The worker enumerates selectable item cards, extracts markup percentages from the live DOM, ranks opportunities, and retries clicks when the book mutates underneath the cursor.

Resilient Marketplace Traversal

Consent banners, overlay dialogs, and withdraw confirmations are handled as first-class steps. The engine clears popups, waits for enabled actions, and completes the I-Understand confirmation so fragile UI does not abort a trade.

Authenticated Operator Workspace

Email registration, session login, protected routes, logout, password recovery, and profile management give the product a complete SaaS identity layer rather than an open control panel.

Strategy Configuration Desk

A dedicated settings surface lets operators edit markup, price bounds, and session material with an explicit edit/save contract, loading states, and success or failure toasts.

Trading Command Dashboard

The home desk frames bot status, recent activity, and operational shortcuts so an operator can read the room before opening the terminal or changing risk parameters.

Supervised Start-Stop Control

WebSocket commands start and halt the worker. The server refuses duplicate runs, tears down the browser on stop, and keeps the console and the control buttons in sync.

Also included

Cloud Worker Isolation

The automation engine runs as its own process with PM2 process management and a Chromium environment tuned for container and PaaS constraints, keeping long-running browsers off the operator's laptop.

Account Security and Recovery

Operators can reset passwords, review account identity, and close sessions from a dedicated profile surface that matches the rest of the product's visual system.

Product Onboarding and Tutorial

A landing experience with hero narrative, guided video, and calls to sign in or create an account teaches the desk before the first live run.

Design System for High-Stakes Ops

A dark glassmorphic system with violet, cyan, and magenta signals, Inter and Poppins typography, and reusable cards, toasts, overlays, and nav patterns keeps a dense trading UI readable under pressure.

BFF Configuration API

Next.js route handlers create, read, and update bot strategy documents, stripping internal fields before they reach the client so the browser never talks to the database as a raw consumer.

Gallery

Product surfaces

Visual placeholders mark where final screens and captures will live. Drop assets at the paths shown on each tile.

Engineering

How it's built

A trader authenticates through Appwrite and lands in the protected Next.js workspace. Strategy reads and writes travel through route handlers into Appwrite Databases. When the operator presses Start, the browser opens a WebSocket to the worker. The worker loads the current strategy document, launches stealth Chromium with PaaS-safe flags, injects the marketplace session, and walks a linear state machine: page load, popup clearance, sort, consent, markup filter, price envelope, then a continuous select-and-withdraw loop. Telemetry frames flow back to the terminal. Stop sets a run flag to false and closes the browser. The operator product and the worker scale on different hosts so a Chromium crash cannot take down the desk.

API-drivenReal-time command and telemetryModular automation state machineSplit UI and worker runtimesSecure session architectureCloud-native process isolation

Decision

Split the operator SaaS from the Chromium worker instead of driving the marketplace from the Next.js server.

Headless Chrome needs a long-lived process, native libraries, and crash isolation. The product UI needs fast deploys and protected routes.

Each runtime can fail, scale, and deploy on its own terms, which is the architecture clients expect for automation products.

Decision

Use WebSockets as the control plane rather than polling HTTP jobs.

A trade run is a conversation: start, stream, stop. Polling would hide mid-flight failures and delay operator intervention.

The desk feels live. Operators see login, filters, and fills as they happen and can halt the browser immediately.

Decision

Store strategy and session material in Appwrite and read it at run start.

The worker should not trust a payload pasted into a socket. The settings form and the engine must share one document.

Configuration is durable, editable, and consistent across UI refresh and worker restart.

Stack

CSGO Item Trading Bot is a split-runtime product: a typed Next.js operator application for identity, strategy, and live control, and a Node.js automation worker that owns headless Chrome and marketplace execution. Appwrite holds accounts and strategy documents. WebSockets bind the desk to the worker. The stack is the one a commercial trading-ops product needs: a polished SaaS surface, a durable worker, and a real-time command channel between them.

Next.js 14 (App Router)React 18TypeScriptTailwind CSSDaisyUIFont AwesomeReact ToastifyNode.jsWebSocket Server (ws)Puppeteer Extra with StealthNext.js Route HandlersExpress-ready Worker ProcessBullMQ-ready Job ModelAppwrite DatabasesAppwrite Account StoreRedisVercelHeroku Worker Dyno
Process

From brief to shipped product

  1. 01Discovery

    We mapped the real CS2 buy-side workflow: watch the P2P book, filter by markup and price, win the click, survive overlays, and confirm withdraw. Interviews and marketplace walkthroughs showed the failure modes were session expiry, popup storms, and the absence of a supervised control surface.

  2. 02Design

    We designed a dark operations system first: landing story, authenticated desk, dashboard, settings, terminal, and profile. Tokens for violet, cyan, magenta, and glass cards were locked so marketing and the command room feel like one product. The terminal was designed as a first-class surface, not a debug drawer.

  3. 03Development

    Frontend and worker were built against a shared strategy model. Route handlers and Appwrite documents landed first so the form and the engine never drifted. The worker was implemented as discrete functions behind a start/stop flag, then hardened with stealth, cookie inject, and Chromium flags for PaaS.

  4. 04Testing

    We exercised login-failure detection, overlay storms, empty books, disabled withdraw buttons, and mid-run stop. Console messaging was treated as a test artifact: if the operator cannot tell what happened, the run is not done.

  5. 05Launch

    The operator app and the worker shipped as separate runtimes with environment-specific Appwrite projects, PM2 process names, and a documented session-refresh path so a live desk can be handed to an operator without a developer sitting next to it.

Challenges

Hard problems, clear outcomes

Making a hostile marketplace UI behave like an API

Problem

The withdraw market is a client-rendered application with consent banners, overlay stacks, disabled buttons, and item cards that appear and vanish. A naive click script dies on the first modal.

Approach

We built a traversal layer: repeated overlay closers, consent handling, explicit waits for selectable cards and enabled withdraw actions, and retry around click races. Each step reports into the console.

Outcome

The engine completes the full path from filter to I-Understand confirmation and keeps running when the book is noisy instead of aborting on the first overlay.

Keeping a long-running worker under human command

Problem

A marketplace run lasts longer than a request. Operators need to start, watch, and stop without orphan Chromium processes or a second run stacking on the first.

Approach

A WebSocket command server owns a single-flight run flag, streams events, and closes the browser on stop or error. The console mirrors that contract with disabled stop until the worker is actually live.

Outcome

The desk is supervised. Operators can halt a run and trust that the browser is gone.

Session authenticity without a password in the worker

Problem

The marketplace authenticates with browser cookies. Stale or missing sessions waste a full Chromium launch and confuse the operator.

Approach

Session material lives on the strategy document, is injected at page load, and is verified by probing for the login control. Failure is a console message: update the session, do not guess.

Outcome

The product treats credentials as rotatable configuration and fails loudly when the desk is not actually logged in.

Choosing the right skin on a moving book

Problem

Eligible cards carry different markups and the DOM can change between read and click. Clicking the first card is not a strategy.

Approach

The selector scans selectable cards, parses markup text, tracks the minimum percentage, and retries the click path when the node is stale.

Outcome

The engine consistently prefers the lowest-markup eligible listing inside the operator's rules, which is the behavior a trader would perform by hand if they were faster.

Running Chromium on a constrained cloud host

Problem

PaaS images do not ship a full desktop Chromium stack. Default Puppeteer flags crash or exhaust shared memory.

Approach

We shipped an Aptfile of native libraries, postbuild Chromium cache placement, and launch flags for no-sandbox, /dev/shm, GPU, and single-process operation, plus PM2 for process supervision.

Outcome

The worker runs as a real cloud process, which is the difference between a local toy and a product an operator can leave on.

Proof

What this work proves

CSGO Item Trading Bot gives CS2 traders a finished operations product: identity, strategy, live control, and a worker that can authenticate, filter, score, and complete marketplace withdraws while the operator watches. The work demonstrates that Krenno can productize brittle third-party workflows into a coherent SaaS desk with a design system worthy of a trading floor. Clients see a path from idea to a dual-runtime system they can supervise, extend to more venues, and white-label as their own trading ops platform.

SaaS product designReal-time operator consolesAuthentication and session architectureHeadless browser automationMarketplace systems integrationTrading and risk-rule workflowsCloud worker orchestrationDesign systems for dark operational UIsAPI-driven configurationFintech-adjacent control roomsResilient third-party UI traversalSplit frontend and worker architecture

What's next

Multi-venue trading adapters

Extend the same strategy model and console to additional CS2 venues so an operator can run one desk across several books instead of one marketplace.

Portfolio and fill analytics

Add historical fills, realized markup, and inventory views so the dashboard that already frames activity becomes a true performance desk.

Intelligent pricing guidance

Layer external market indexes and learned markup bands onto the existing scorer so the engine can explain why a listing is a take.

Have something in mind?

Tell us about your product and we'll help you ship something worth putting on this page.

→Start a project

Next project

DC Pay

A global wallet for instant payments, swaps, and on-chain earning.

View case study