WarStonks
A local-first desktop trading companion for Warframe, built to take a fragmented, high-friction workflow and turn it into one cohesive, decision-ready tool.
project snapshot
the problem
Warframe trading has a surprisingly high operational overhead if you want to do it well. A serious player might need to check live listings, evaluate price history, manage buy and sell orders, plan relic runs, estimate set values, and track whether any of it is actually profitable, often all in the same session.
Most of that work is split between browser tabs, spreadsheets, screenshots, memory, and rough intuition. That creates three specific problems:
Decision latency
Good opportunities are easy to miss when users have to gather information manually across multiple tools before they can act.
Lack of context
Raw prices alone don't explain market posture, liquidity, trend strength, or whether a listing is actually competitive. Data without interpretation is noise.
Workflow fragmentation
Trading, farming, and set planning are closely related decisions, but most tools treat them as separate problems with no connection between them.
the goal
I wanted to design and build a single application that could support the full decision loop: not a passive statistics viewer, but something that actively helps users make better decisions, faster.
The product needed to feel practical rather than theoretical. Every feature had to answer a question a real player actually asks, not just expose the data.
what I built
Instead of organizing the app around raw API responses, I organized it around user intent. Each section answers a specific set of questions.
Home Dashboard
The operational centre: global item search, quick market inspection, watchlist state, and action prompts. One place to check what matters right now without navigating across the whole app.
Market Analysis & Analytics
Deep-dive view for a single item. Split into Quick View for fast orderbook reads, Analysis for entry/exit price, margin, and liquidity, and Analytics for historical structure, trend quality, and execution context.
Watchlist & Alerts
Target-price tracking with alerts when live listings match user-defined conditions. Turns market monitoring from a repetitive manual process into an event-driven one.
Scanners
Scanner-driven opportunity discovery. The Arbitrage Scanner surfaces set-vs-component opportunities. The Relic ROI Scanner ranks relic value and reward quality. Both summarize large datasets into concise, ranked, actionable results.
Opportunities
The layer that turns analysis into instructions. Scanner output, owned inventory, and market context are ranked into concrete moves, complete this set, sell those parts instead, snipe an underpriced listing, each with its reasoning, its confidence, and the exact buys and sells attached. What To Farm Now extends the same idea to relic runs, weighted by what's already in your inventory.
Set Completion Planner
Tracks owned prime components and calculates investment, value, expected profit, and margin per set. Uses relic inventory data to identify missing pieces more intelligently. Includes screenshot-assisted import with explicit confirmation steps.
Trade Management
Live sell and buy order management with editing, removal, and account controls. The Trades Health workflow explains whether a listing is competitive, how much queue is ahead of it, and whether to hold, reprice, or wait.
Portfolio & P&L
Local portfolio layer for reviewing whether a trading strategy is working over time. Trade logs, realized profit, estimated inventory value, and full P&L summaries, designed to evaluate quality, not just activity.
Events & Worldstate
Baro Ki'Teer's stock with exit-price analysis while he's in relay, Prime Resurgence, fissures, Nightwave, Steel Path, and a clock for the open-world cycles. Context that moves prices, kept next to the prices.
the app
product & UX approach
My design approach focused on reducing friction and increasing decision confidence. That meant a few consistent principles across the whole product:
Organize around decisions, not data
I avoided building the app as a collection of disconnected data panels. Instead, I designed major sections around user intent, inspect, monitor, discover, manage, review. The data follows the workflow, not the other way around.
Treat responsiveness as a product requirement
A lot of the work in this product involves background refreshes, queueing, caching, and integration sync. The UI needed to feel alive and responsive regardless of what was happening underneath, never blocking, never waiting visibly.
Prefer clear action language
Wherever possible, I shaped outputs around practical guidance rather than vague status text. That's especially important in places like market posture, listing health, and scanner views, where the value is in the interpretation, not the raw data.
Reduce visual noise as a continuous task
As the app grew, one of the ongoing design tasks was removing redundant labels, duplicate notes, overly noisy pills, and low-signal status text. Letting the highest-value information stand out requires actively removing everything that competes with it.
technical architecture
WarStonks is built as a Tauri desktop application with a split architecture, a React/TypeScript frontend for UI and workflow orchestration, and a Rust backend for everything that needs to be fast, reliable, or persistent.
Frontend: React + TypeScript
Responsible for presenting live and cached data cleanly, managing modal and review flows, keeping background refreshes visually unobtrusive, and translating complex market information into readable context.
Backend: Rust + Tauri
Handles all external API calls, local database reads and writes, scheduler enforcement, analysis and scanner logic, and log and error handling. Keeps the heavy work completely off the UI thread.
Data Layer: SQLite
Local-first caching, persisted scanner and observatory state, owned inventory and relic cache support. Lets the app load useful local data immediately while live refreshes happen in the background.
engineering decisions
Shared request scheduler for Warframe Market
Warframe Market enforces rate limits, and multiple app features can request data concurrently, search, quick view, watchlist refreshes, trades, and scanners all run in parallel. I built a shared priority queue so all requests route through one controlled pathway. Without this, those workflows would compete badly and degrade each other.
Cache-first, refresh-in-background
Where cached data is safe to use, the app loads it immediately, then refreshes in the background. This pattern became especially important for relic inventory, planner data, scanner results, and historical market context, data that's expensive to fetch but doesn't need to be live on every open.
Degraded-mode error handling
I treated error handling as a product quality concern, not just backend stability. Instead of letting features fail hard when a refresh or upstream source has trouble, I built the app to prefer degraded mode where safe, cached data stays usable while the app communicates that a live refresh didn't succeed.
Multi-source data integration
WarStonks combines three external sources: warframe.market for market data and trading operations, warframestat.us for worldstate context, and Alecaframe for inventory-related workflows. One of the core design challenges was deciding where each source is authoritative, where it's advisory, and where local cache should take precedence.
Safety-first trade action flows
Trade-related actions have real consequences if handled poorly. I paid particular attention to confirmation flows, order sequencing, queue priority rules for user-triggered actions, and watchlist reconciliation. The goal was to reduce the chance of the app doing the wrong thing during fast trading sessions.
Localizing an app built on proper nouns
The interface is translated into six languages, but item names are a different problem: they're proper nouns players search and whisper with, and translating them independently would quietly break both. Item names come from Warframe.Market's own translations instead, so the app stays aligned with the source its users are actually trading against.
Open source, but not the name
The app is GPL-3.0: free to study, modify, and redistribute. The name and branding deliberately aren't part of that licence. WarStonks signs into Warframe.Market accounts, so a tampered build wearing the official name is a credential-theft vector; forks are asked to rename so "official" always means the signed release.
challenges
Balancing live data with app responsiveness
The app depends on live market data, but the UI should never feel like it's waiting. Solving this required combining local caching, background refresh patterns, request scheduling, and coalescing repeated work, all working together so the frontend always has something useful to show.
Turning noisy data into actionable insight
The APIs provide a lot of raw information. A major part of the work was designing the interpretation layer, market summaries, scanner scoring, listing health logic, and planning-oriented UI outputs. The value of the app comes from that interpretation, not the retrieval.
Maintaining coherence as the app grew
As WarStonks expanded from market analysis into scanners, planning, trades, and portfolio features, there was a real risk of it becoming a loosely connected collection of tools. I handled this by continually refining the product around one larger loop: discover, act, manage, review, and cutting anything that didn't serve that loop clearly.