SimDex case study | Live market interface
A darker market product built to move from signal to action with less friction.
SimDex combines a live board, a black-terminal Dex Mode, wallet and PnL context, social automation, public company surfaces, and trade-adjacent APIs. The core product idea is simple: show the move, explain the move, then keep the user close to action.
Overview
SimDex becomes differentiated when discovery, explanation, and execution all share the same product language.
Generic scanners stop at discovery
Most tools surface coins and charts but leave the user to build context, trust, and execution flow somewhere else.
One operating surface
SimDex ties runner scoring, wallet context, Dex Mode, social automation, and company positioning into one ecosystem.
More believable operator UX
The product feels closer to a trading cockpit than a marketing-first dashboard or a single-page scanner clone.
My role
I pushed both the product stance and the frontend system harder than a normal dashboard build.
- Defined the board, Dex Mode, company, and why-SimDex route structure
- Shaped the noir visual language and information hierarchy
- Connected public positioning to the live app instead of treating brand pages as an afterthought
- Built around the actual API shape: candidates, trade quote, auth, launch kit, social drafts, and wallet data
Snapshots
More of the product system, including lower-page marketing and explanation surfaces.
Project stack
SimDex is a browser-first product with backend logic, account systems, and market integrations driving the surface.
Backend
Python 3.11, FastAPI, Pydantic Settings, Uvicorn, Authlib, HTTPX, SQLite
Frontend
Static browser UI served from FastAPI with dedicated board, company, why-SimDex, and Dex Mode pages
Integrations
DEX Screener, Phantom wallet, Jupiter quote/build swap flows, Google and Discord OAuth scaffolding
Notable features
These are direct capabilities from the current codebase and route layer.
`/`, `/app`, `/company`, `/company/why-simdex`, `/dex`
The project treats brand, explanation, and live app work as one system instead of separate websites.
Health, candidates, trade quote, build swap, auth, launch kit, social drafts
The UI is backed by real product endpoints, not static mock cards pretending to be a platform.
Bookmarks, wallet connect, trade history, OAuth providers
The account model already supports persistent state and richer post-trade product behavior.
Directional KPIs
If SimDex kept scaling, these are the product numbers I would care about most.
Target repeated board and Dex Mode return behavior for active users.
Target share of active users connecting a wallet and staying inside the SimDex surface.
Target users who request quote previews or swap builds after board exploration.
Target weekly retention once social drafts, rooms, and wallet history deepen the loop.
Timeline
The product matures by layering trust and action on top of the runner board core.
Runner board MVP
FastAPI, browser UI, scoring engine, candidate filters, and the first live board surface establish the product core.
Account and wallet layer
Persistent auth, bookmarks, wallet context, and trade history make the app feel more like a real operating surface.
Dex and action layer
Jupiter quote previews, swap build support, and Dex Mode keep discovery close to actual action.
Public positioning layer
Company pages, why-SimDex comparison, launch kit, and social draft automation explain why the product matters.
Architecture
The architecture keeps ranking, context, and action within the same orbit.
Ingestion
DEX Screener + scoring engine
->
Surface
Board + Dex Mode + token detail
->
Action layer
Wallet + quote + build swap + social drafts
Backend core
FastAPI serves both the route layer and the APIs, with gzip, trusted hosts, session middleware, and deployment hardening.
Market logic
Weighted scoring, risk penalties, candidate filters, token detail views, and portfolio endpoints produce the board’s operating context.
Public layer
Company and why-SimDex routes act as product explanation surfaces, not generic marketing pages disconnected from the app.
Hardest tradeoff
SimDex has to stay dense enough for serious users without turning into a wall of information that only the builder understands.
The main tradeoff was deciding how much raw signal to keep visible at once. I kept the interface dense, but pushed harder on route separation and brand explanation so the product could stay operational without becoming unreadable.
- More density improves trust for serious users but raises onboarding cost
- Wallet and action rails increase product depth but also increase responsibility for clarity
- Public explanation pages are necessary because the live app alone does not tell the whole story
What I would build next
If I kept pushing SimDex, I would focus on making post-discovery decisions even tighter.
Richer wallet behavior intelligence
Push holdings mix, linked-wallet behavior, and historical context further into the decision surface.
Alerts and rescoring workers
Periodic rescoring and alert delivery would make SimDex feel more like a live operator product than a pull-to-refresh tool.
Execution UX and monitoring
Trade confirmation guardrails, explorer/history surfaces, and production monitoring are the next serious maturity step.
Next case study
Jump from the trading cockpit back into the guided Kineo mobile health system.
SimDex shows darker operational density. Kineo shows calmer habit-building, coaching, and premium daily product flow.