Ascendant Traders
Designed and built a complex publishing and signal-tracking system to help operators manage acquisition, conversion, live feeds, channel workflows, and diagnostics.
- Astro
- TypeScript
- Node.js
- Discord API
- +6
Highlights
-
Designed and built a product system across acquisition, conversion, signal publishing, tracking, and reporting
-
Modeled signal states separately from activated trades so reporting reflected actual tracked positions
-
Created browser-safe feed contracts between the static site and runtime engine
-
Built operator diagnostics, monthly recaps, Discord and Telegram distribution, and chart media generation
-
Framed observability, risk communication, and reporting honesty as product features
Context
Ascendant Traders is useful to this portfolio when framed less as a crypto project and more as a complex product-systems case. The work connected a static public website, a Node runtime, signal publishing, trade tracking, Discord and Telegram distribution, public feeds, chart media, and operator diagnostics.
The core design challenge was trust. The product had to communicate live information clearly, separate ideas from activated positions, avoid coupling the marketing site to backend uptime, and give operators enough visibility to understand what the system was doing.
Product System
The public side handled acquisition and conversion:
- Landing page and brand positioning.
- Free signal preview.
- VIP pricing and comparison.
- Affiliate and Whop conversion paths.
- SEO blog structure, education, about, and disclaimer pages.
The runtime side handled delivery and operations:
- Signal scoring and market-data ingestion.
- Discord signal posts and tracker updates.
- Telegram mirroring.
- SQLite-backed signal and trade state.
- Public feed endpoints for the website.
- Chart rendering for signal attachments.
- Acquire
Static Astro pages explain the product, pricing, education content, and conversion paths.
- Preview
Public feed endpoints let the site show recent examples and monthly summaries.
- Publish
The runtime posts signals and tracker events to separate Discord and Telegram channels.
- Track
SQLite stores signal state, trade activation, history, and monthly recap data.
- Diagnose
Read commands and debug endpoints expose state without requiring direct database access.
The important product work was not the algorithm alone. It was the contract between acquisition, delivery, reporting, and operations.
Key Product Decisions
Separate marketing from runtime. The website stays static, fast, and deployable without depending on the signal engine. Public JSON feeds progressively enhance live-looking surfaces without turning the whole site into a server app.
Use feed contracts instead of direct coupling. The website only needs browser-safe JSON from endpoints like signal and market feeds. If a feed is unavailable, the frontend falls back to repo-backed content.
Model state explicitly. I separated posted signals from activated trades because a published setup is not the same as a tracked position. That distinction protects reporting honesty and makes recaps more credible.
Treat observability as UX. Operators needed commands, diagnostics, recaps, and state views that made the system legible without opening SQLite directly.
Trust And Risk Communication
This category requires careful product judgment because users can misread confidence, risk, and performance. I designed the publishing layer to show context rather than only calls to action: source references, live read time, trend indicators, take-profit and stop-loss levels, confluence signals, and recap math.
The system also separates signal posts, activation posts, close posts, and monthly recaps. That structure makes it clearer what happened, what is open, what closed, and what should not be counted as an active trade.
Interaction And Information Design
One part of the product that mattered more than expected was message design. Discord and Telegram posts are product surfaces: they need hierarchy, recognizable states, and enough supporting context to be scanned quickly.
Representative formatter decisions included:
- Signal number, date, pair, direction, entry, TP, and SL always appear in predictable positions.
- Live market context and confluence indicators support the recommendation.
- Activation posts are intentionally short and operational.
- Close posts report whether the trade closed by TP or SL.
- Monthly recaps separate open trades, closed trades, winrate, and total PnL.
Outcome And Learning
The end result was a complete product stack: static acquisition site, free preview experience, VIP pricing surface, signal scoring runtime, persistent tracker, Discord and Telegram publishing, chart media service, public feeds, diagnostics, and lean VPS deployment.
The main lesson was that complex systems become product design work when users and operators need to trust the state of the system. The strongest decisions were about boundaries: static versus runtime, posted versus activated, marketing copy versus reporting, and bot output versus operator diagnostics.