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.
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.
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.
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.
reflection
WarStonks is the kind of project I enjoy most — taking a messy, high-friction workflow and turning it into a tool that feels cohesive, useful, and operationally sharp. By the official 3.0.4 release it covered the full loop: market inspection, opportunity discovery, farming guidance, set planning, live order management, and portfolio review.
The most important lesson from the project was that technical correctness alone is not enough. For a product like this, the real value comes from how well the system translates raw data into confidence, speed, and clarity for the user. That's a product problem as much as an engineering one — and it's the part I found most interesting to solve.
It also taught me Rust properly. The borrow checker is unforgiving, but after fighting it long enough, you start writing code differently — more intentional, more aware of ownership. That thinking has carried over into everything I've built since.