DEV Community: NydarTrading

I Built a $1 Alternative to DeleteMe and Incogni — Here's How It Works

NydarTrading — Sat, 21 Mar 2026 11:58:19 +0000

Data brokers are selling your personal information right now. Your name, address, phone number, email, relatives, employer — it's all on sites like Spokeo, WhitePages, Radaris, and TruePeopleSearch. Anyone with $1 and five minutes can find it.

Services like Incogni ($7.49/month) and DeleteMe ($10.75/month) will find and remove this data for you. They're good products. But they cost $90-130/year, and most of what they do is search public websites and submit opt-out forms — something you can do yourself if you know where to look.

So I built a tool that does the detection half for $1.

What the Tool Does

The Personal Data Exposure Report scans 20+ data broker and people-search sites for your name, email, and phone number. For each site where your data is found, it gives you:

A direct link to your profile on the broker site
What types of data are exposed (address, phone, email, relatives, etc.)
Step-by-step removal instructions specific to that site
A direct link to the site's opt-out page
What you'll need to complete the removal (email, phone, profile URL)
Estimated time to complete the removal
Whether the site is part of a group (one removal covers multiple sites)

Plus a summary with your exposure score, breakdown of easy vs hard removals, and all data types exposed across all sites.

How Detection Works

The actor uses multiple detection methods to maximize coverage:

Brave Search — searches for your name across 29 known data broker domains, finding indexed listings with direct profile URLs
Direct HTTP scanning — checks 6 broker sites that respond to direct requests
Proxy scanning — checks 13 additional protected sites using residential proxies
DataBreach.com — checks if your email appears in known data breaches
Have I Been Pwned — checks email breach exposure (optional, requires API key)

Sites Covered

Tier 1 — Free people-search sites (richest data)

Site	Data Exposed	Removal	Time
TruePeopleSearch	Name, address, phone, age, relatives	Online form	2 min
FastPeopleSearch	Name, address, phone, email, relatives	Online form	2 min
ThatsThem	Name, address, phone, email, IP	Online form	2 min
Nuwber	Name, address, phone, email, age	Email link form	3 min
USPhoneBook	Name, address, phone	Online form	2 min
SearchPeopleFree	Name, address, phone, age	Online form	2 min

Tier 2 — Paywalled sites

Site	Data Exposed	Removal	Time
Spokeo	Name, address, phone, email, social, court records	Profile URL + email confirm	3-5 min
WhitePages	Name, address, phone, relatives, age	Phone call verification	5-10 min
Radaris	Name, address, phone, email, court, property	Account + phone verify	10-30 min
PeopleFinders	Name, address, phone, age, relatives	Online form	3 min
Intelius	Name, address, phone, email, relatives	PeopleConnect suppression	5-10 min

Breach databases

Site	What It Checks
DataBreach.com	Whether your email appears in known data breaches
Have I Been Pwned	Email breach exposure (needs API key — $3.50/month)

The PeopleConnect Trick

Here's something most people don't know: Intelius, ZabaSearch, Instant Checkmate, AnyWho, and Addresses.com are all owned by PeopleConnect. One removal at suppression.peopleconnect.us covers all five sites.

The report flags these automatically so you don't waste time submitting five separate removals when one will do.

What the Output Looks Like

For each site where your data is found:

{
    "site": "Spokeo",
    "found": true,
    "profileUrl": "https://www.spokeo.com/John-Smith/California",
    "dataTypes": ["name", "address", "phone", "email", "social media"],
    "removalUrl": "https://www.spokeo.com/optout",
    "difficulty": "easy",
    "removalSteps": [
        "Find your profile on Spokeo and copy the profile URL",
        "Go to https://www.spokeo.com/optout",
        "Paste your profile URL into the form",
        "Enter your email address",
        "Complete the CAPTCHA and click Submit",
        "Check your email and click the confirmation link",
        "Removal takes 24-48 hours"
    ],
    "removalTime": "3-5 minutes",
    "removalRequires": ["your Spokeo profile URL", "email address"]
}

And a summary at the end:

{
    "type": "summary",
    "sitesScanned": 23,
    "sitesWithData": 9,
    "exposureScore": 39,
    "easyRemovals": 4,
    "mediumRemovals": 3,
    "hardRemovals": 2
}

The Removal Workflow

Step 1: Run the report ($1). Review your exposure score.

Step 2: Handle PeopleConnect sites first. If you're found on any PeopleConnect site, one removal at suppression.peopleconnect.us covers all of them. 5-10 minutes removes you from 5+ sites.

Step 3: Do the easy removals. Sites with difficulty: easy have simple online forms. Most take 2-3 minutes each.

Step 4: Tackle medium removals. These need email or phone verification. Budget 5-10 minutes each.

Step 5: Handle hard removals last. Radaris and VoterRecords have deliberately difficult processes. The report includes fallback options.

Step 6: Re-scan in 30 days. Data brokers re-add data regularly. At $1/scan, monthly monitoring costs $12/year.

Cost Comparison

Feature	This Tool	Incogni	DeleteMe
Price	$1.00 one-time	$7.49/month	$10.75/month
Sites covered	20+ direct + 29 via search	180+	750+
What you get	Exposure report + removal guide	Automated removal	Automated removal + monitoring
Removal included	No (step-by-step guide)	Yes (automated)	Yes (automated)
Annual cost	$12 (monthly scans)	$89.88	$129
Profile URLs	Yes	No	No

When to Use This vs. Incogni/DeleteMe

Use this tool when:

You want to know where your data is exposed before paying for removal
You prefer to handle removals yourself
You want a one-time check, not a subscription
You're evaluating whether paid services are worth it for your situation
You're a business running privacy reports for clients

Use Incogni/DeleteMe when:

You want fully automated removal with no manual work
You need coverage of 100+ sites
You need ongoing monitoring and automatic re-removal

Limitations

Detection + guide, not automated removal. You follow the steps yourself.
US-focused. The sites scanned are primarily US-based people-search engines.
Point-in-time snapshot. Data brokers continuously update. A clean result today doesn't mean clean forever.
Common names. Very common names may show false positives.

Try It

The tool is live on the Apify Store. Enter your name, optionally add email/phone/state for better coverage, and get your exposure report in under a minute.

Full documentation: ApifyForge

Built by ApifyForge — we build data intelligence tools on the Apify platform. More tools at apify.com/ryanclinton.

What 9,000 Search Impressions Taught Us About What Traders Actually Want

NydarTrading — Mon, 16 Mar 2026 19:38:16 +0000

I've been checking the Google Search Console numbers obsessively for the past two months. Not because I love staring at dashboards (well, maybe a bit — I did build a dashboard platform after all), but because the data is telling me something I didn't expect.

This month, Nydar hit 9,638 search impressions. In February, we were barely scraping 300 a day. By mid-March, we're consistently hitting 600+. That's not a hockey stick, but for a solo-built trading platform that's been live for a couple of months, I'll take it.

What's more interesting than the number itself is what people are searching for when they find us.

The queries tell a story

The biggest surprise has been order flow trading. Our learn article on it is sitting at position 7.3 in Google with 136 impressions this month. That's page one for a competitive term. People searching that aren't beginners asking "what is a stock" — they're traders who already know what a candlestick chart is and want to go deeper. They want to understand tape reading, delta divergence, and how institutional orders move through the book before they show up on your chart.

We built the order flow suite because I used these tools at Cowen and couldn't find anything decent outside of a Bloomberg terminal. The institutional platforms charge five figures a year for order flow visualisation. The retail ones give you a basic order book and call it a day. There's a massive gap between "here's the top 5 bids and asks" and "here's how liquidity is actually being consumed across price levels in real time." That gap is where footprint charts, volume delta, and aggregated book depth live.

Turns out a lot of other people were looking for the same thing. The search data confirms it — traders want institutional-grade tools without the institutional price tag. Not a simplified version. The actual tools.

Market microstructure is another one sitting at position 11.5, just off page one, with 54 impressions. That's a niche topic — bid-ask dynamics, latency, maker-taker models, how your order actually gets filled and why you sometimes get worse execution than you expected. The fact that people are finding our content on it tells me there's a real gap in plain-English explanations of how markets actually work under the hood. Most educational content stops at "supply and demand" and never gets into the mechanics. We went deeper because the mechanics are where the edge is.

What I didn't expect

Custom indicators and Pine Script — 40 impressions at position 11.6. I built the Pine Script engine because I personally wanted to run custom scripts against live data without paying for a premium charting subscription. Didn't think many people would search for it specifically, but apparently there's a crowd of traders who've outgrown the built-in indicators on their current platform and want to write their own.

That makes sense when you think about it. Anyone serious about technical analysis eventually hits the ceiling of what RSI and MACD can tell you. They start combining indicators, building composite signals, testing ideas. And then they realise they need somewhere to actually run those ideas against live data without writing a full trading bot from scratch. That's what the Pine Script engine does — it bridges the gap between "I have an idea" and "I can see if this idea works on today's market."

The AI signals page is pulling 100 impressions at position 10.0. That's interesting because AI trading signals is a space absolutely drowning in scams and snake oil. Every other ad on social media is some bloke promising his AI bot will turn £500 into £50,000 by next Tuesday. The fact that our honest breakdown of how the models work is ranking suggests Google is rewarding transparency over hype. We're not promising "guaranteed returns" — we're showing you the XGBoost confidence scores and letting you decide. You can see the model's reasoning, its historical accuracy, and where it gets things wrong.

We published a piece on meta-labelling a while back that explains how we filter out low-confidence signals before they ever reach you. That post didn't get much organic traction, but the people who found it stayed on the page. Quality over quantity — which is the whole philosophy, really.

The CTR problem (and what we're doing about it)

Here's the uncomfortable number: 21 clicks from 9,638 impressions. That's a 0.2% click-through rate. Brutal.

But context matters. Most of those impressions are from pages sitting at positions 15-60 in search results. Nobody clicks on page 6 of Google. The pages that are on page one — the homepage, the order flow article, the AI signals page — have much better CTR. The homepage alone has a 29% click-through rate at position 4.4.

The fix isn't to write more content. It's to make the existing content rank higher. We've been rewriting title tags and meta descriptions across the site — the kind of thankless work that doesn't make for exciting screenshots but moves the needle over weeks. When someone searches "order flow trading" and sees our result on page one, the title and description need to make them click instead of scrolling past.

We've also been dealing with some cannibalization issues — multiple pages competing for the same search term. The glossary is comprehensive (200 terms), and sometimes a glossary entry like fear and greed index competes with the full blog post explaining the same concept. We're sorting that with canonical tags and internal linking rather than deleting content.

What the data is shaping

Nothing dramatic. We're not pivoting based on search queries. But it is shaping priorities.

The pages sitting just outside page one — market microstructure, footprint charts, correlation matrices, funding rate and open interest — those are the ones getting attention right now. More internal links, deeper content, better explanations. The organic traffic will follow if the content deserves it. If it doesn't, at least users who do land on those pages are getting something genuinely useful rather than thin SEO bait.

I've also been spending time on things you can't see in search data. The automated trading bot running internally has been consistently profitable over the past few weeks. It's not public yet, and I'm not going to rush it out until the backtesting is thorough enough that I'd trust it with real size. Which I already do, quietly, in small position sizes. The current strategy uses a trailing stop system that we've been grid-searching to find the optimal parameters — the kind of work that takes weeks of data to validate properly.

Paper trading remains the core of what Nydar does. Everything we build gets tested there first, and it's what most users interact with. The bot, the signals, the order flow tools — they all feed into the paper trading engine before anything touches real money.

A side project is paying the bills

I'm also building something on the side — a separate product that generates revenue from day one. It made $30 before 7am this morning, and it's still early. That matters for Nydar because it removes the pressure to monetise prematurely.

Most indie trading platforms die the same way. They launch free, get some traction, panic about server costs, then slap a paywall on everything and watch their users disappear. Or worse, they start selling their users' order flow data to market makers. That's not happening here.

Having a separate revenue stream means Nydar can stay generous with what's free. It means I can take three months to build the premium features properly instead of shipping a half-baked subscription tier because the AWS bill is due. No "free trial ends in 3 days" pop-ups. No artificial limits on features that cost me nothing to serve.

That's a luxury most indie projects don't have, and I'm not going to waste it by shipping half-baked features just to hit a revenue target.

The content machine

One thing I'm genuinely proud of is the depth of educational content we've built. 42 learn articles covering everything from scalping strategies to liquidation cascades to iceberg orders and spoofing detection. 200 glossary terms, most of them linking through to deeper learn articles and help pages. 33 blog posts in two months.

None of it is generated filler. Every learn article is written by someone who's actually used these concepts on a trading desk. When I write about order flow, it's because I've sat in front of a Bloomberg terminal watching institutional orders sweep through the book. When I write about position sizing, it's because I've seen what happens when people don't do it.

The content strategy isn't "rank for keywords." It's "explain things properly, and the rankings will follow." So far, that's working. The pages that rank highest are the ones with the most substance, not the ones with the most keyword density.

Taking a breather

I'm off tomorrow for St Patrick's Day. The irony of an Irishman building a trading platform and taking the one day a year the entire world pretends to be Irish as a day off isn't lost on me. Markets are closed anyway for the weekend, so the timing works out — no FOMO about missing a trade while I'm three pints deep in a pub somewhere.

The platform will keep running — it managed a full week without me in hospital, so it can handle a bank holiday. The bot will keep trading crypto (those markets never sleep, even when the Irish do). The data feeds will keep flowing. The API quota management will keep doing its thing, backing off outside market hours and spinning back up when the bell rings.

When I'm back on Wednesday, the focus is on pushing those near-page-one pages over the line. Market microstructure, footprint charts, custom indicators — all sitting between positions 11 and 13. A few well-placed internal links and some content improvements should be enough to nudge them onto page one. There's also work to do on options flow — it's at position 19 with 58 impressions, which means people are searching for it and Google thinks we're relevant. We just need to prove we deserve a higher spot.

The numbers

For anyone tracking along:

9,638 search impressions this month (up from ~5,700 last month, ~2,800 the month before)
21 clicks (low, but trending up — was 3 a month ago)
Average position improving — from 71.4 to 25.5 over the past 28 days
33 blog posts published since January
200 glossary terms — all interlinked with learn articles and help pages
42 learn articles covering every major trading concept
63 help pages — one for every widget and feature

It's still early. We're nowhere near profitable from the platform itself, the click numbers are still small, and there's a lot of work to do on CTR. But the trajectory is in the right direction. The content is ranking, the platform works, people are finding us through genuine searches for topics we actually know something about. That's the foundation.

Everything else gets built on top of it.

Curious what all the fuss is about? Try the dashboard — no sign-up required, start paper trading in seconds.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

We Built an AML Screening Tool That Replaces $100K Enterprise Contracts

NydarTrading — Thu, 12 Mar 2026 15:51:17 +0000

If you work in fintech, you know the drill. Before you can open an account, process a payment, or onboard a business customer, you need to run AML (Anti-Money Laundering) checks. It's not optional — regulators will shut you down if you don't.

The problem is the tooling. Enterprise AML platforms like Refinitiv World-Check, ComplyAdvantage, and LexisNexis cost $15,000 to $100,000 per year. For a startup, a small bank, or a crypto exchange in its early stages, that's a brutal line item for what amounts to searching a few databases.

So we built our own.

What Enterprise AML Tools Actually Do

Strip away the sales decks and the enterprise pricing, and here's what these platforms actually do:

Search sanctions lists — OFAC SDN, EU consolidated list, UN sanctions, OpenSanctions
Search criminal watchlists — Interpol Red Notices, FBI Most Wanted
Check for Politically Exposed Persons (PEPs) — FARA foreign agent registrations, campaign finance records
Verify corporate entities — OpenCorporates, LEI databases, FDIC insurance status
Detect shell companies — Nominee directors, bearer shares, shell haven jurisdictions
Score the risk — Combine signals into a risk tier: Low, Medium, High, or Prohibited

Every single one of these data sources is publicly available. OFAC publishes their SDN list. Interpol has a public API. OpenCorporates is open data. The SEC, CFPB, and FDIC all publish their records.

The enterprise tools charge $100K/year to query public data and put a dashboard on top.

What We Built

Our Financial Crime Screening MCP is a single API endpoint that runs 13 data sources in parallel and returns a structured AML risk classification. It's available as an MCP server, which means any AI agent or LLM client can call it directly.

It exposes 8 tools:

Tool	What It Does
`comprehensive_entity_screen`	Full screening across sanctions, criminal watchlists, and corporate registries
`sanctions_deep_check`	Focused OFAC + OpenSanctions check with fuzzy matching
`criminal_watchlist_scan`	Interpol Red Notices + FBI Most Wanted search
`pep_influence_analysis`	FARA foreign agent + FEC campaign finance check
`corporate_shell_detection`	Shell company indicators, haven jurisdictions, nominee directors
`financial_institution_verify`	FDIC insurance status + consumer complaint analysis
`proximity_to_crime_score`	Multi-signal convergence scoring across all categories
`aml_risk_classification`	Full 13-source AML risk tier classification

How It Scores Risk

The full classification runs every data source and scores across five dimensions:

Sanctions exposure — Any direct sanctions match automatically triggers PROHIBITED tier
Corporate transparency — Missing LEI, shell haven registration, nominee directors
Political exposure — FARA registrations, significant campaign finance activity
Financial regulatory standing — FDIC status, consumer complaint volume
Proximity to crime — Signal convergence across multiple adverse categories

The key insight is convergence. A single CFPB complaint doesn't mean much. But if someone has consumer complaints AND shows up in FARA records AND is registered in a shell haven AND has no LEI — that convergence of signals is far more telling than any individual hit.

The output gives you a clear risk tier (LOW / MEDIUM / HIGH / PROHIBITED) with a recommendation for each level — from "standard processing" to "file SAR and escalate to compliance."

Example Output

Here's what a comprehensive entity screen returns:

{
    "entity": "Acme Holdings Ltd",
    "entityType": "company",
    "sanctions": {
        "ofac": { "hits": 0, "records": [] },
        "openSanctions": { "hits": 2, "records": ["..."] }
    },
    "criminalWatchlists": {
        "interpol": { "hits": 0, "records": [] },
        "fbi": { "hits": 0, "records": [] }
    },
    "corporate": {
        "registrations": ["..."],
        "lei": []
    },
    "totalHits": 2
}

Two OpenSanctions hits and no LEI. That's a flag — needs further investigation. The aml_risk_classification tool would score this across all dimensions and return a risk tier with a specific recommendation.

Who This Is For

Fintech startups — You need AML screening to get licensed, but you can't afford $50K/year before you have revenue. This gets you compliant for a few dollars per check.

Crypto exchanges — High volume, low margin. Running sanctions checks on every user at enterprise pricing doesn't work. At $1.50-3 per query, the math works even at scale.

Compliance teams at small banks — You have the regulatory requirement but not the Refinitiv budget. This covers the same data sources at a fraction of the cost.

Legal and advisory firms — KYC/KYB checks for client onboarding. Run a quick screen before engagement, without a six-figure annual contract.

AI agent developers — Because this is an MCP server, any AI agent framework can call it. Build compliance workflows that screen entities automatically as part of a larger pipeline.

Cost Comparison

Solution	Annual Cost	Per-Check Cost
Refinitiv World-Check	$30,000 - $100,000	Included (but you pay regardless)
ComplyAdvantage	$15,000 - $50,000	Included
LexisNexis	$20,000 - $80,000	Included
Our tool	$0 annual fee	$1.50 - $3 per check

No annual contract. No minimum spend. Pay only when you run a check.

For a startup running 500 checks per month, that's $750-$1,500/month vs. $30,000+ upfront for enterprise alternatives. For low-volume use cases (law firms running 50 checks/month), it's $75-$150/month vs. tens of thousands annually.

What This Doesn't Replace

I want to be honest about the limitations:

This is not a compliance program. It's a screening tool. You still need policies, procedures, a compliance officer, and a framework for how you handle hits.
No ongoing monitoring. This runs point-in-time checks. Enterprise tools offer continuous monitoring with alerts. You'd need to schedule periodic re-screening yourself.
No case management. When you get a hit, enterprise tools have workflows for investigation, escalation, and documentation. Here, you get the data — what you do with it is up to you.
Fuzzy matching has limits. Name matching across languages, transliterations, and aliases is hard. Enterprise tools have decades of tuning behind their matching algorithms.

For many use cases — especially early-stage companies, low-volume screening, and developer-built compliance workflows — the tradeoff is worth it. You get 80% of the capability at 2% of the cost.

Try It

The tool is live on the Apify Store. You can connect it as an MCP server from any compatible client (Claude Desktop, Cursor, or your own agent framework).

We also have a Counterparty Due Diligence MCP for corporate KYB screening (18 data sources, beneficial ownership analysis, jurisdiction risk scoring) and an ESG Supply Chain Risk MCP for environmental and labor compliance checks.

If you're building in fintech and spending more on compliance tooling than on your actual product, there's a better way.

We build trading analytics and data infrastructure at Nydar. More on what we're building at dev.to/nydartrading.

How to Scrape Contact Data from 10,000 Websites (for Under $50)

NydarTrading — Thu, 12 Mar 2026 15:48:05 +0000

I got tired of manually researching company contact info.

Not because I'm lazy — because it doesn't scale. If you need emails and phone numbers for 20 companies, sure, spend an afternoon clicking through websites. But when you need contact data for 1,000 companies? 10,000? That's weeks of mind-numbing work that a script can do in minutes.

So I built a tool that does exactly that. You give it a list of URLs, it visits each website, finds the contact and team pages automatically, and gives you back structured data: emails, phone numbers, names, job titles, and social links. One clean record per company.

The Problem With Manual Contact Research

A human researcher follows a predictable pattern:

Open the company website
Look for a "Contact" or "About" page
Write down any emails, phone numbers, and names
Move to the next company
Repeat 999 more times

At maybe 10 companies per hour, that's 100 hours of work for 1,000 companies. At a conservative $20/hour, that's $2,000 in labor — for data that goes stale within months.

The scraper does the same thing, but processes 1,000 websites in about 15 minutes for roughly $5 in compute.

What You Get Back

For each website, you get a single structured record:

{
    "url": "https://buffer.com",
    "domain": "buffer.com",
    "emails": ["hello@buffer.com"],
    "phones": ["+1-555-0123"],
    "contacts": [
        { "name": "Joel Gascoigne", "title": "Founder CEO" },
        { "name": "Caro Kopprasch", "title": "Chief of Staff" },
        { "name": "Jenny Terry", "title": "VP of Finance & Operations" }
    ],
    "socialLinks": {
        "linkedin": "https://www.linkedin.com/company/bufferapp",
        "twitter": "https://x.com/buffer",
        "facebook": "https://www.facebook.com/bufferapp",
        "instagram": "https://www.instagram.com/buffer"
    },
    "pagesScraped": 2,
    "scrapedAt": "2026-02-06T23:48:25.255Z"
}

That Buffer example pulled 48 team members with names and titles from their about page. Every email is deduplicated, every phone number is validated, and social links are extracted from across the site. One row per company, ready for your spreadsheet or CRM.

Quick Start — Python

from apify_client import ApifyClient

client = ApifyClient(token="YOUR_API_TOKEN")

run = client.actor("ryanclinton/website-contact-scraper").call(
    run_input={
        "urls": [
            "https://stripe.com",
            "https://basecamp.com",
            "https://buffer.com",
        ],
        "maxPagesPerDomain": 5,
    }
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"{item['domain']}: {item['emails']}")

Quick Start — JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: 'YOUR_API_TOKEN' });

const run = await client.actor('ryanclinton/website-contact-scraper').call({
    urls: [
        'https://stripe.com',
        'https://basecamp.com',
        'https://buffer.com',
    ],
    maxPagesPerDomain: 5,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach(item => {
    console.log(`${item.domain}: ${item.emails.join(', ')}`);
});

The Real Power: Google Maps → Contact Data Pipeline

Scraping three websites is a demo. The real value is chaining this with other data sources to build a full lead pipeline.

Say you need leads for every dentist in Austin, TX:

from apify_client import ApifyClient

client = ApifyClient(token="YOUR_API_TOKEN")

# Step 1: Get businesses from Google Maps
maps_run = client.actor("compass/crawler-google-places").call(
    run_input={"searchStringsArray": ["dentists in Austin, TX"]}
)

# Step 2: Extract website URLs
websites = []
for biz in client.dataset(maps_run["defaultDatasetId"]).iterate_items():
    if biz.get("website"):
        websites.append(biz["website"])

print(f"Found {len(websites)} business websites")

# Step 3: Scrape contact info from all of them
contacts_run = client.actor("ryanclinton/website-contact-scraper").call(
    run_input={"urls": websites, "maxPagesPerDomain": 5}
)

# Step 4: Full lead database
for item in client.dataset(contacts_run["defaultDatasetId"]).iterate_items():
    emails = ", ".join(item["emails"]) if item["emails"] else "no email"
    names = len(item["contacts"])
    print(f"{item['domain']}: {emails} | {names} contacts found")

You go from "dentists in Austin" to a spreadsheet with names, emails, phone numbers, and social profiles in under 20 minutes. The total cost for 200 businesses is under $2.

Other Pipelines That Work Well

Found names but no emails? Feed the results into Email Pattern Finder. It detects the company's email format (first.last@, f.last@, etc.) and generates email addresses for every team member.

Want to prioritize your leads? Run the results through B2B Lead Qualifier. It scores each company on 30+ business quality signals so you contact the best prospects first.

Want the whole thing automated? B2B Lead Generation Suite chains all three steps — contact scraping, email generation, and lead scoring — into a single run. One input, one output.

Performance and Cost

Websites	Time	Cost
10	~10 seconds	< $0.01
100	~2 minutes	~$0.05
1,000	~15 minutes	~$0.50
10,000	~2.5 hours	~$5.00

The first 100 websites are free. No credit card required to test.

It's fast because it uses HTTP requests instead of spinning up a browser for every page. Most business websites serve their contact info as plain HTML, so you don't need a browser to read it.

What It Won't Do

I want to be upfront about limitations:

JavaScript-heavy sites — If a site renders its contact page entirely with client-side JavaScript (React SPAs with no server rendering), you won't get results. This works for the vast majority of business sites, but not all.
Contact forms only — Some sites have no visible email, just a form. You'll get names and social links but no emails.
Login-protected pages — Public pages only. No authentication or cookie handling.

For bulk lead generation, hitting 85% of sites at a fraction of the cost of browser automation is the right tradeoff. For the remaining 15%, you'd need a browser-based solution.

Who's Using This

The tool has been used for:

Sales teams building prospect lists from industry directories
Recruiters finding hiring managers at target companies
Market researchers building competitive intelligence databases
Agencies enriching client CRM data in bulk
Freelancers finding decision-makers for cold outreach

If you're manually copying emails from websites into spreadsheets, you're doing it wrong.

Try It

The tool is live on the Apify Store. First 100 websites are free — just paste your URLs and hit Start.

For anything more than a one-off run, the API examples above let you integrate it directly into your workflow. Schedule it, chain it with other tools, or pipe the output straight into your CRM.

We build data infrastructure and trading analytics at Nydar. Follow along on dev.to for more on what we're building.

What Is WSB Buying Right Now? How to Track It Without the Noise

NydarTrading — Tue, 10 Mar 2026 15:21:00 +0000

I spent way too long refreshing r/wallstreetbets every morning.

Not because I was trading off the DD posts — most of them are barely literate. But because there's real signal buried in there if you know how to find it. When a ticker goes from 40 mentions a day to 800 in 24 hours, that's not random. Something is happening. The problem is that extracting that signal manually means scrolling through hundreds of posts, memes, loss porn, and "is this a dip or am I just poor" comments.

So we built a tool that does it automatically.

The problem with reading WSB manually

WallStreetBets has 15+ million members. On any given day there are thousands of posts and tens of thousands of comments. The sub moves fast. A ticker can go from zero mentions to the most talked-about stock on the internet in a few hours — GameStop in January 2021 being the obvious example, but it happens on a smaller scale constantly.

If you're checking WSB manually, you're doing it wrong for a few reasons:

You're seeing what's already popular, not what's becoming popular. By the time a ticker is plastered across the front page with rocket emojis and diamond hands, the move has probably started. The value isn't in knowing that everyone's talking about GME — it's in catching the acceleration before it hits the front page.

You're also reading sentiment wrong. A post titled "GME to the moon 🚀🚀🚀" and a post titled "I just lost $47,000 on GME" both count as mentions of GME. Manually, your brain lumps them together. But the sentiment is completely different, and the ratio between bullish and bearish mentions tells you something the raw count doesn't.

And you're wasting time. The median WSB post is not useful. It's a meme, a screenshot of a $200 loss, or someone asking what options are. The actual signal-to-noise ratio is terrible. You could spend 30 minutes scrolling and come away with less information than a single widget gives you in 3 seconds.

What mention velocity actually tells you

Most people think about Reddit sentiment as a simple question: is WSB bullish or bearish on a stock? That matters, but it's not the most useful signal. The more interesting metric is velocity — how fast is the conversation growing?

A ticker with 500 mentions per day that's been stable for a week is popular, but it's not news. A ticker that went from 50 mentions yesterday to 400 today is accelerating. That acceleration is the signal. It means something changed — a catalyst dropped, someone posted a DD that went viral, or shorts started covering and people noticed.

We track this by comparing 24-hour mention counts against the previous 24-hour period. The percentage change gets bucketed into velocity badges:

Rising (50%+ increase) — gaining traction, worth watching
Surging (100%+ increase) — real momentum building
Exploding (200%+ increase) — something significant happened

An "Exploding" badge on a ticker you haven't heard of is much more interesting than a "Rising" badge on TSLA. TSLA is always getting mentioned. The velocity badge helps you filter out the permanently-popular tickers and focus on what's actually changing.

Sentiment is harder than it looks

Scoring whether a Reddit post is bullish or bearish sounds simple but it's genuinely tricky. "GME is going to the moon" is obviously bullish. "Just YOLOed my rent money into GME puts" is bearish — they're betting it goes down. But "I swear if GME drops below $20 again I'm loading the truck" is... bullish? It's talking about a drop but expressing buying intent.

Our widget scores each mention and gives you an aggregate bullish/bearish percentage. It's not perfect — nothing is when you're doing NLP on posts that use "retarded" as a term of endearment — but it's a lot better than trying to gauge the vibe by scrolling.

The sentiment score is most useful when it diverges from velocity. If mentions are exploding but sentiment is turning bearish, that's a different situation than mentions exploding with 80% bullish sentiment. The first might be a sell-the-news event. The second might be early-stage momentum.

What WSB gets right (and wrong)

Here's the thing about WSB that the financial media consistently misunderstands: it's not a monolith. It's 15 million people with different strategies, different risk tolerances, and wildly different levels of experience. Some of the DD posts on there are legitimately excellent — detailed analysis with sources, well-reasoned short squeeze theses, sector research that rivals what junior analysts at banks produce.

And then someone replies "sir this is a Wendy's."

The crowd dynamic is what makes it powerful and dangerous. When WSB collectively identifies a short squeeze setup — high short interest, low float, rising FTDs, cost to borrow spiking — they've occasionally been right in spectacular fashion. GameStop and AMC proved that retail buying pressure, when concentrated enough, can move stocks that institutional investors thought were dead money.

But the crowd is also subject to every behavioral bias in the textbook. Confirmation bias runs rampant — once a ticker becomes a "meme stock," any good news is rocket fuel and any bad news is "hedgie manipulation." The sunk cost fallacy keeps people holding through 80% drawdowns. And social proof means people buy stocks because other people are buying them, not because of any underlying thesis.

This is exactly why tracking the data — velocity, sentiment, mentions — is more useful than reading the posts themselves. The data doesn't have confirmation bias. It just tells you what's happening.

The GME playbook: what velocity looked like in real time

Everyone knows the GameStop story in hindsight. But if you were watching the data in real time, the velocity signal was screaming days before the mainstream media caught on.

In early January 2021, GME mentions on WSB were steady at maybe 200-300 per day. It was a niche play — DFV had been posting his YOLO updates for months, a handful of people were in, but it wasn't front page material. Then around January 11th, when the stock started moving from $19 to $31, mentions jumped to 1,500 in a single day. That's a velocity spike you can't miss. By January 22nd, when the stock hit $65, mentions were over 10,000 per day. The acceleration happened before the $300+ parabolic move, not during it.

AMC told a similar story six months later. The stock sat at $9 in late May 2021 with moderate WSB attention — maybe 400 mentions a day, mostly people comparing it unfavorably to GME. Then on May 24th, mentions tripled overnight. By May 26th, the stock was at $19 and climbing. A week later it hit $62. The people who were watching velocity caught the move at $9-12. The people who read about it on CNBC bought at $50.

The pattern repeats on smaller scales constantly. BBBY in August 2022 — velocity spiked three days before the stock went from $5 to $30. SPRT in August 2021 — mentions went from near-zero to "Exploding" over a weekend, stock ran 700% that month. These weren't all good trades (BBBY holders got destroyed when it collapsed), but the velocity data told you something was happening before price confirmed it.

That's the whole value proposition. Not "this will go up." Just "something changed, and it changed fast."

WSB isn't one strategy

People outside the sub think WSB is just "buy calls on meme stocks and pray." That's like saying a city is one restaurant. There are distinct trading styles on WSB, and the data we track is useful to all of them differently.

The YOLO options crowd. These are the people buying weekly calls with their entire portfolio. They live and die by momentum, and for them, velocity data is basically a targeting system. An "Exploding" ticker with 80%+ bullish sentiment and high call volume is exactly what they're looking for. Whether that's smart is a different question, but the data helps them find the momentum plays faster.

The short squeeze hunters. This is probably WSB's most sophisticated subgroup. They're looking at short interest percentages, cost to borrow rates, days to cover, FTD spikes — the full picture. For them, Reddit velocity is the catalyst trigger. They'll have a watchlist of heavily-shorted stocks and wait for WSB to discover one of them. When velocity spikes on a high-SI name, that's the convergence they're waiting for.

Theta gang. The options sellers. They actually love it when WSB piles into a stock, because implied volatility spikes and they can sell overpriced premiums. For them, an "Exploding" velocity badge means "time to sell puts or covered calls on this thing while IV is through the roof." They're fading the crowd's enthusiasm by collecting premium.

The buy-and-hold value crowd. Yeah, they exist on WSB. They're in PLTR, SOFI, AMD — stocks with actual businesses that also happen to be WSB favorites. For them, sentiment data is a sanity check. If their long-term hold suddenly shows up with crashing sentiment and exploding mentions, they want to know why. Did something fundamental change, or is the sub just having a tantrum because earnings missed by a penny?

Each of these strategies uses the same data differently. That's why we built the widget to show raw metrics — velocity, sentiment, mention count — rather than trying to interpret them for you. Your strategy determines what the numbers mean.

Cross-referencing: where the real edge is

Reddit sentiment on its own is interesting. Reddit sentiment cross-referenced against three other data points is actually useful.

Here's the stack we use on the WSB Trading Floor:

Reddit velocity + short interest. If a ticker is exploding on WSB and has 25%+ short interest, you've got the setup for a squeeze. The Reddit crowd is the demand side. The short sellers who need to cover are the forced buying. Together, that's how you get moves like GME. Without the high short interest, a Reddit velocity spike is just hype — it might push the stock up 10% before fading. With it, you've got the potential for something much bigger.

Reddit sentiment + dark pool volume. Dark pools are where institutions trade when they don't want to move the market. If Reddit sentiment is overwhelmingly bullish on a ticker and dark pool volume suddenly spikes, someone big is positioning. Could be buying alongside the crowd. Could be selling into the strength. Either way, the combination tells you that institutional money is paying attention to the same stock the Reddit crowd is, and that changes the dynamics.

Reddit velocity + options flow. When a ticker's mentions are exploding and you simultaneously see large block trades on call options — especially ones bought at the ask — that's confirmation from a completely different data source. Some random person posting DD on Reddit is one thing. Someone dropping $2 million on weekly calls at the same time is another. The options flow widget shows you whether smart money is aligned with or fading the Reddit narrative.

Reddit velocity + FTDs + cost to borrow. This is the full squeeze checklist. Rising Failures to Deliver mean shares aren't being located for delivery. Spiking cost to borrow means short sellers are paying through the nose to maintain positions. And Reddit velocity means the crowd has found it. When all three are moving together, that's the convergence that preceded every major squeeze in the last five years.

None of these signals work perfectly alone. But when three of them line up on the same ticker at the same time, you're looking at something worth investigating.

How to actually use this data

I want to be clear about something: Reddit sentiment data is not a buy signal. It's context. It's one input alongside price action, options flow, short interest, and whatever other analysis you're doing.

Here's how we use it:

As an early warning system. If a ticker you're holding suddenly shows up with an "Exploding" velocity badge and bearish sentiment, that's worth investigating even if you haven't seen the catalyst yet. The crowd found something before you did.

As a squeeze checklist item. A potential short squeeze needs multiple ingredients — high short interest, high cost to borrow, rising FTDs, and a catalyst. Reddit momentum is often that catalyst. If you've identified a ticker with the right setup and it starts trending on WSB, the missing piece may have just clicked into place.

As a fade signal. This is counterintuitive, but sometimes the most useful thing WSB tells you is when to not follow the crowd. If sentiment is at 95% bullish and the ticker has been mentioned 5,000 times today, you're late. The institutions that were going to cover have covered. The move may already be priced in. Extreme one-sided sentiment has historically been a contrarian indicator.

As a timing tool for exits. This one gets overlooked. If you're already in a position and the ticker suddenly goes from 200 mentions to 5,000, that's not just a signal for new entrants — it's a signal for you to think about your exit. Parabolic mention growth often coincides with the final leg of a move. The last buyers are piling in based on FOMO, and that's usually when the smart money starts selling. Watching velocity on your own holdings tells you when your quiet little trade has become a crowded one.

As entertainment. Honestly, some of us just like knowing what's going on over there. It's the most interesting trading community on the internet and the culture is genuinely funny. Nothing wrong with checking in just to see what's happening, as long as you're not making trading decisions based on the strength of someone's rocket emoji conviction.

The evolution of WSB as a market force

It's worth understanding how much WSB has changed since 2020. Pre-pandemic, the sub had about 1 million members and was mostly a place to post loss porn and joke about going bankrupt on FDs (extremely short-dated options, for the uninitiated). It was niche. Nobody on Wall Street was monitoring it.

That changed permanently in January 2021. The GameStop squeeze proved that a decentralized group of retail traders, coordinated loosely through Reddit, could move a stock hard enough to blow up a hedge fund. Melvin Capital lost 53% in a single month. The financial establishment was genuinely shaken — not because of the dollar amount, but because it challenged the assumption that retail flow is noise.

Post-GME, WSB swelled to 15+ million members. The culture shifted. More newcomers, more people who had no idea what a put option was, more mainstream media attention. The quality of DD posts arguably declined. But the data signal got stronger, not weaker. More members means more mentions, which means velocity spikes are more statistically significant. A ticker going viral on a 1-million-member sub could be a coincidence. A ticker going viral on a 15-million-member sub is an event.

The financial industry adapted too. Hedge funds now monitor Reddit sentiment. There are entire companies built around scraping WSB for alpha. Quant funds include social media velocity in their models. The information asymmetry that existed in January 2021 — where WSB could see something Wall Street couldn't — is smaller now, but it hasn't disappeared. The crowd still finds things first sometimes, especially small-cap names that institutional analysts don't cover.

The widget stack

Our Reddit Sentiment widget is the starting point, but it's designed to work alongside everything else on the WSB Trading Floor. Sixteen widgets total — short interest scanner, dark pool volume, cost to borrow tracker, FTD spikes, congressional trades (yes, Pelosi's portfolio), gamma exposure, max pain, insider transaction clusters, and more.

The idea is that you don't have to alt-tab between six different websites to get the full picture on a ticker. Reddit says it's hot. Short interest says it's squeezable. Options flow says someone big just bought calls. Dark pool says institutions are moving. FTDs are spiking. Cost to borrow is at 80%. That's six data points from six different sources, all on one screen.

You can browse all of it without an account. If you want to add widgets to your dashboard and customise the layout, sign up — takes about 30 seconds, no credit card.

What WSB is talking about right now

I'm not going to list the "top WSB stocks for 2026" because that list goes stale in about 12 hours. That's the whole point of building a real-time tool instead of writing a blog post with tickers in it. Every article you see titled "Top 10 WallStreetBets Stocks to Buy in 2026" was outdated before it was published. The tickers they list were trending when the author checked, which was probably three days before the article went live.

If you want to know what WSB is buying right now — like, actually right now — check the widget. It updates constantly. Whatever I write here will be wrong by tomorrow, and we'd both rather you see the actual live data anyway.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

28 Gaming Stocks We Track and Why Pure-Play Publishers Are the Ones to Watch

NydarTrading — Mon, 09 Mar 2026 14:51:08 +0000

When most people think "gaming stocks," they think EA, Nintendo, maybe Activision before the Microsoft acquisition. The big names. The obvious ones.

But those aren't the stocks that move 10-25% on a single game review. Those are the ones that shrug it off because gaming is one division among many.

We built a tracking system that covers 28 game publishers across 8 global exchanges. After spending months mapping review events to stock reactions, one pattern became very clear: the less diversified the company, the more the stock moves on game reviews. And the companies that move the most are the ones most people haven't heard of.

The tier system

We split the 28 publishers into two tiers based on how much their stock price depends on game review scores.

Tier 1 — pure-play publishers. These are companies where gaming is 80%+ of revenue and one AAA title can represent 30-60% of expected annual earnings. When that title reviews 15 points below expectations, analysts revise sales forecasts down 20-40%, and on a $2B market cap company that's $80-160M wiped off expected revenue before the market even opens.

Tier 2 — diversified publishers. Gaming is significant but not the whole business. EA has FIFA/FC, Madden, and a large live-service portfolio. One bad review for a new IP isn't sinking the stock. The moves are smaller (3-8%), more noise-prone, and harder to trade.

If you're looking at gaming stocks through the lens of review events, Tier 1 is where the signal-to-noise ratio is highest.

Tier 1: The stocks that actually move

CD Projekt (WSE: CDR)

The canonical example. The Witcher and Cyberpunk are essentially the entire company. When Cyberpunk 2077 reviewed at 53 on consoles against an expected 92, the stock fell 9.4% on review day and 75% over the following months. When The Witcher 3 crushed expectations, the stock went on a multi-year run.

CD Projekt is the poster child for review-driven stock moves because there's nowhere to hide. One franchise, one set of expectations, and the entire company rides on it. The Warsaw Stock Exchange listing adds another wrinkle — CDR trades during European hours, and most major review embargoes lift on US time. That delay between information and market reaction is exactly the kind of gap that creates opportunity.

What makes CD Projekt especially interesting is the redemption arc. After the Cyberpunk launch disaster, they went heads-down on patches and the Phantom Liberty expansion. When Phantom Liberty reviewed well, the stock recovered significantly. The lesson: for pure-play publishers, the review-to-stock relationship works in both directions. A bad launch tanks the stock, but a strong follow-up can recover it — and the recovery move can be just as tradeable as the initial drop.

Capcom (TSE: 9697)

Monster Hunter and Street Fighter drive the business. When Monster Hunter: World scored 90 and broke out in Western markets in 2018, Capcom stock more than doubled over the year as sales kept beating forecasts. Capcom is interesting because they've got several strong franchises — Resident Evil, Devil May Cry, Monster Hunter, Street Fighter — but they're all gaming. No semiconductor division, no music label, no financial services absorbing the blow.

Krafton (KRX: 259960)

PUBG. That's the story. Krafton is essentially a single-franchise company trading on the Korean exchange. Their market cap lives and dies with PUBG's global engagement metrics and whatever their next major title looks like. Any new launch is a massive event for this stock.

Krafton is also a good example of why you need to watch the Korean exchanges specifically. KRX has different trading mechanics, different retail investor behaviour (Korean retail is famously active in gaming stocks), and different hours than Western markets. When a PUBG update launches badly and Korean gaming forums light up, the stock can move before any Western analyst has written a note about it.

Embracer Group (OMX: EMBRAC B)

This one's complicated. Embracer went on an acquisition spree — THQ Nordic, Gearbox, Crystal Dynamics, Eidos — and then the Saudi Aramco deal fell through in 2023. The stock got hammered. They're now restructuring and spinning off divisions. But the core thesis holds: when you own that many studios and gaming is the only business, major launch outcomes move the stock.

Embracer is a cautionary tale about what happens when a pure-play publisher's strategy falls apart independent of review scores. The stock collapsed not because of bad reviews, but because the financing disappeared. That's an important reminder: review events are one catalyst among several. Earnings surprises, failed deals, and management changes can all overwhelm the review signal. The review thesis works best when there's no competing narrative.

Team17 (LSE: TM17)

The Overcooked and Worms publisher, plus a growing portfolio of indie publishing deals. Small-cap, UK-listed, and entirely dependent on gaming revenue. The stock is reactive to both their own launches and the broader indie publishing market sentiment.

Small-cap gaming stocks like Team17 are where the review thesis gets most volatile. Lower liquidity means bigger percentage moves on less volume. A surprise hit from one of their indie partners can spike the stock more dramatically than a comparable event at EA, simply because fewer shares are trading. The flip side is that small-cap means wider spreads and harder exits — which matters if you're trying to trade around a review event in real time.

Paradox Interactive (OMX: PDX)

Crusader Kings, Stellaris, Cities: Skylines. Paradox has a loyal niche audience and a DLC-heavy business model. Their stock moves on launch reviews, but also on the post-launch DLC reception — a bad expansion for a live game can drag the stock down weeks after the initial launch.

Cities: Skylines II is the case study here. The first game was a massive success with an 85 Metacritic. The sequel launched to mixed reviews and brutal Steam user scores — "Mostly Negative" at launch due to performance issues. The stock took a hit not just on the review day, but on a slow bleed as negative user reviews kept piling up over weeks. Paradox is unique because their DLC-driven model means the review window never really closes. Every major expansion is another potential catalyst, positive or negative.

Kadokawa (TSE: 9468)

The parent company of FromSoftware. When Elden Ring scored 96 against an expected 90 in 2022, Kadokawa stock rose 15%. They also own media and publishing businesses, but the FromSoftware connection makes them Tier 1 for review events involving Souls-like titles. Armored Core VI was another catalyst.

Kadokawa is an interesting structural case because the company you're actually betting on (FromSoftware) is a subsidiary, not the listed entity itself. This means the stock reaction is somewhat diluted compared to what it would be if FromSoftware traded independently. But it also means the market sometimes underreacts to FromSoftware review events because analysts covering Kadokawa are thinking about the whole conglomerate. That underreaction is where the edge lives.

Tier 2: The big names with built-in shock absorbers

Electronic Arts (NASDAQ: EA)

EA is the classic Tier 2 example. FIFA/FC alone generates billions annually regardless of review scores — it's an annuity business driven by Ultimate Team spending, not critic opinions. When Anthem scored 55 against an expected 80+, the stock dropped 8% that week. Painful, but not catastrophic. EA's diversified enough to absorb one bad launch without an existential crisis. The review thesis works here, but the moves are muted.

Ubisoft (Euronext: UBI)

Assassin's Creed, Far Cry, Rainbow Six — Ubisoft has enough franchises that one bad review doesn't sink the ship. But cumulative bad reviews do. The stock's long-term decline coincided with a string of middling review scores across multiple franchises. Individual launch events create 3-5% swings, not the 10-25% of Tier 1 publishers.

Ubisoft is actually the best argument for why you should track review drift even on Tier 2 stocks. No single Ubisoft game tanked the stock — it was death by a thousand cuts. A 72 here, a 68 there, a cancelled project, another mediocre open-world game. The Review Impact History widget shows this pattern clearly: a string of below-average scores compounding over quarters until the market finally reprices the whole company downward.

Take-Two Interactive (NASDAQ: TTWO)

GTA and NBA 2K dominate the revenue. Take-Two is interesting because GTA launches are so rare and so massive that they're essentially Tier 1 events — a new GTA scoring badly would be catastrophic. But between GTA launches, the stock trades more on 2K Sports revenue and Red Dead engagement, making it a Tier 2 for most review events.

The GTA situation is worth its own paragraph. GTA VI is the single most-anticipated game in the industry. When it finally gets a review embargo date, every gaming stock tracker in the world should be watching — because a GTA launch doesn't just move Take-Two, it moves the entire sector. A 97 lifts all boats. An 80 would send shockwaves. The sympathy correlation during a GTA launch event will be unlike anything else in the dataset.

Nintendo (TSE: 7974)

Hardware-software combo with massive cash reserves. A bad Zelda review would move the stock, but Nintendo's balance sheet and hardware revenue provide cushioning that pure-play publishers don't have. They're also culturally resistant to the kind of quality crashes that hit Western publishers — their internal quality bar prevents most disasters before they happen.

Bandai Namco (TSE: 7832)

Gaming plus toys plus anime. The diversification dilutes review-score sensitivity. Elden Ring was a Bandai Namco-published title, but the stock reaction was smaller than Kadokawa's (the FromSoftware parent) because gaming is one piece of a larger pie.

Sony (TSE: 6758)

PlayStation is a division, not the company. Semiconductors, music, pictures, financial services — a bad PS5 exclusive review doesn't register on Sony's balance sheet the way it would for a pure-play publisher. Sony is relevant to the gaming sector thesis only through cross-correlation: when sector sentiment turns negative, Sony can get dragged along.

The rest of the 28

We haven't covered every company individually, but they all matter to the sector picture:

Asia: Square Enix (TSE: 9684) is a fascinating in-between case — Final Fantasy is massive, but they also have manga, merch, and amusement businesses. A bad Final Fantasy review still moves the stock, but less than it would if Square Enix were pure gaming. Konami (TSE: 9766) has pivoted so far toward fitness clubs and pachislot machines that game reviews barely register anymore, but a new Metal Gear or Silent Hill could change that overnight. Sega (TSE: 6460) has Atlus and Persona/Shin Megami Tensei alongside Sonic, giving them a surprisingly strong franchise roster. Nexon (TSE: 3659) and NCSoft (KRX: 036570) are the Korean online gaming giants — their stocks react more to monthly active user numbers than to critic reviews, but a major new title launch is still a review event.

Europe: Frontier Developments (LSE: FDEV) makes Planet Coaster and Elite Dangerous — small-cap UK, entirely gaming-dependent, and the stock moves violently on launch reviews. Stillfront (OMX: SF) focuses on mobile and free-to-play, which is less review-driven but still trades with the sector.

Americas: Roblox (NYSE: RBLX) is platform-first rather than game-first, so traditional review events don't apply the same way — but it trades with gaming sector sentiment. Zynga got acquired by Take-Two, thinning the US pure-play publisher list further.

The point isn't that all 28 are equally tradeable on review events. It's that tracking all of them gives you the sector-level picture: correlation data, sympathy moves, and momentum indicators that you miss if you're only watching one or two stocks.

The exchanges matter

The 28 companies trade across 8 exchanges in 3 time zones:

Asia (14 companies): Tokyo Stock Exchange, Korea Exchange, KOSDAQ. Japanese and Korean publishers dominate the list — Capcom, Konami, Square Enix, Sega, Nintendo, Nexon, Kadokawa, NCSoft, Krafton, and more. These exchanges open when most Western review embargoes have already lifted, creating a gap between information and price.

Europe (9 companies): Warsaw Stock Exchange, Euronext Paris, OMX Stockholm, Helsinki, London Stock Exchange. CD Projekt, Ubisoft, Embracer, Paradox, Team17, and others. European trading hours overlap with US morning, so review events during this window get priced in across both regions simultaneously.

Americas (5 companies): NASDAQ and NYSE. EA, Take-Two, Activision Blizzard (Microsoft), Roblox, and others. These get the most analyst coverage and institutional attention, which means review events are priced in fastest here.

The time zone arbitrage is real. If a major review drops at 10am Eastern, Tokyo doesn't open for another 14+ hours. You know the signal before the Asian market has a chance to react. Our Gaming Sector widget shows cross-publisher correlation by region so you can estimate the likely sympathy move.

What moves the stock isn't the score — it's the deviation

This is the thing most people get wrong about gaming stocks. A Metacritic 75 isn't automatically bearish. A 92 isn't automatically bullish. What matters is how far the actual score deviates from the franchise's historical average.

If a franchise averages 82 across five entries and the new one scores 92, that's a +10 deviation — bullish. The publisher beat expectations. If the same franchise scores 70, that's -12 — the stock is getting hit.

Same absolute score of 75 can be bullish for a franchise that averages 68 and catastrophic for one that averages 90. The deviation model is why we track franchise expected scores and show the gap in real-time as reviews come in.

Pre-release hype adds another layer. If IGDB follows and trailer views are through the roof, the effective market expectation is higher than the franchise average. An "average" score for a hyped game disappoints because average wasn't what anyone was pricing in.

The social amplifier

A bad review score with 500 Reddit comments in the first hour moves the stock 2-3x more than a bad score with 50 comments. Social buzz is the multiplier that determines whether a review event stays in gaming news or crosses over into financial news.

We track this across Reddit, YouTube, Twitch, and Discord. When a negative review hits the front page of r/games with thousands of upvotes and three major YouTube creators release negative videos within 24 hours, it goes from "niche gaming news" to the kind of story that triggers analyst notes and institutional selling.

The YouTube creator signal is particularly telling. When SkillUp, ACG, and AngryJoe all release negative reviews within the same afternoon, the combined audience reach is in the tens of millions. That's not a niche gaming discussion anymore — that's a consumer sentiment wave. And when those videos start getting picked up by mainstream finance coverage ("Gaming giant's stock tumbles as critics pan new release"), the stock move enters its second leg.

Twitch viewership tells a different story. High day-one viewer counts confirm mainstream interest in the title. But what matters more is the drop-off rate. A game that launches with 300k concurrent Twitch viewers but drops to 20k within 48 hours is signalling that the hype was front-loaded — and the stock often follows the viewer count down over the following week.

Cross-publisher sympathy

One pattern that surprised me: game publishers don't trade in isolation. When one publisher drops on a bad review, peers in the same region often follow within the same week. We call this sympathy trading, and when correlation is running above 60%, a single review event becomes a sector event.

This creates opportunities beyond the direct play. If Publisher A drops 8% on a bad review and Publisher B drops 3% in sympathy despite having no news, Publisher B might be oversold. Or if you have a strong thesis on an upcoming review event and sector correlation is high, you can capture the move across multiple tickers.

Regional clustering makes this more predictable than you'd expect. Japanese publishers correlate more tightly with each other than with European or US publishers — partly overlapping trading hours, partly shared analyst coverage, partly retail investor overlap. When one TSE-listed publisher drops on review news, other TSE gaming stocks often dip the same session. The European cluster behaves similarly — CD Projekt, Ubisoft, Embracer, and Paradox tend to move together during sector events even though they're on different exchanges within Europe.

The Gaming Sector widget quantifies this with same-direction move percentages between every publisher pair, filterable by region. When that number is above 60%, you're not just trading one stock — you're trading a sector.

When none of this matters

There are times when the review thesis goes out the window, and it's worth knowing when to sit on your hands.

Earnings week. If a publisher is reporting quarterly earnings within a few days of a review embargo, the earnings data dominates everything. A great review score won't save a stock that just missed revenue estimates by 15%. Always cross-reference the earnings calendar before committing to a review-event trade.

Macro panic. During broad market selloffs — a Fed rate shock, a banking crisis, a geopolitical escalation — sector correlation goes to 1. Everything drops together. Gaming stocks included. The review signal gets drowned out by macro noise, and even a 95-scoring blockbuster won't help a publisher's stock when the whole market is down 4%.

Live-service transitions. Some publishers are shifting from launch-driven revenue to recurring subscription and microtransaction models. The more a company depends on live-service revenue from existing games rather than launch sales from new titles, the less review scores matter to the stock. EA's shift toward FC Ultimate Team and Apex Legends is a good example — the company's quarterly revenue depends more on engagement metrics than new game scores.

Pre-announced disasters. Sometimes the market prices in a bad review before it happens. If the publisher set a day-one embargo (bad sign), gameplay leaks look rough, and early access coverage is negative — the stock may have already dropped before the embargo lifts. In that case, the actual review might be a "sell the rumour, buy the news" situation where the stock bounces on a score that's bad but not as bad as feared.

Which gaming stocks are worth watching right now?

I'm not going to tell you what to buy. That's not what Nydar does — we're a paper trading and analysis platform, not a financial advisor.

But I will say this: the gaming stocks worth watching are the ones with upcoming AAA launches, short review embargo timelines, and Tier 1 revenue concentration. The Game Releases widget shows upcoming launches with embargo countdowns, franchise expected scores, and IGDB hype data. That's where you find the next review event.

The pattern repeats every time. Embargo lifts, reviews flood in, the score forms, social buzz amplifies it, and the stock moves. Whether it moves up or down depends on the deviation from expected. The learn guide walks through the full playbook.

Twenty-eight stocks. Eight exchanges. Three time zones. One thesis: for pure-play game publishers, review scores are the most predictable catalyst in equity markets, and almost nobody is systematically tracking them.

We are.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

We Built a Tool That Maps Game Review Scores to Stock Moves

NydarTrading — Mon, 09 Mar 2026 13:47:43 +0000

I've been tracking game publisher stocks for years. Not because I'm a huge gamer — I am, but that's beside the point — but because the relationship between review scores and stock prices is one of the most predictable patterns in equity markets, and almost nobody is systematically trading it.

So we built a tool to do exactly that. Seven dedicated widgets, 28 companies tracked across 8 global exchanges, and a data pipeline that pulls from six different sources. As far as I can tell, nothing else like it exists.

The thesis in 30 seconds

For diversified tech companies, a single game title barely registers on the balance sheet. Microsoft isn't going to tank because one Game Pass title scored a 65. But for a pure-play publisher — a company where gaming is 80%+ of revenue — one AAA title can represent 30-60% of expected annual revenue.

When that title reviews 15 points below expectations, analysts revise sales projections down 20-40%. On a $2B market cap company, that's $80-160M wiped off expected revenue before the stock even opens. Fear and momentum amplify the move from there.

The numbers back this up:

Homefront → THQ (2011): Metacritic 70 vs expected 85. Stock fell 26% in one day. THQ filed for bankruptcy the following year.
Cyberpunk 2077 → CD Projekt (2020): Console Metacritic 53 vs expected 92. Stock fell 9.4% on review day, 75% over months.
Elden Ring → Kadokawa (2022): Metacritic 96 vs expected 90. Publisher stock rose 15%.
Apex Legends → EA (2019): Surprise launch, Metacritic 89. Stock rose 16% in one day.
Anthem → EA (2019): Metacritic 55 vs expected 80+. Stock dropped 8% in the week after reviews. The live-service roadmap was eventually abandoned entirely.
Monster Hunter: World → Capcom (2018): Metacritic 90 with massive Western crossover success. Capcom stock more than doubled over the year as sales kept beating forecasts.

The pattern is clear. The question is whether you can spot the signal fast enough to act on it.

Why speed matters

Game reviews don't drop all at once. There's a predictable sequence, and each stage gives you different information. Understanding the timeline is the difference between catching the move and chasing it.

Embargo timing — the first signal

Before a single review publishes, the embargo date itself tells you something. Publishers set review embargoes — the date and time when critics are allowed to publish their scores. When they set it is a signal in itself.

Early embargoes (days before launch) indicate confidence. The publisher wants reviews out there driving preorders. Late embargoes (launch day or later) are a red flag — the publisher is trying to sell copies before the scores hit. We've seen this pattern enough times that embargo timing alone can adjust your thesis before a single review drops.

Both the Launch Health and Game Releases widgets show real-time embargo countdowns in hours and minutes. When the countdown hits zero, reviews start flooding in.

First reviews — where the edge is sharpest

The moment the embargo lifts, major outlets publish simultaneously. IGN, GameSpot, Eurogamer — they've had the game for weeks and their reviews are queued up. But here's the thing: RSS feeds pick up these reviews minutes before they appear on aggregate sites like OpenCritic.

We pull from five outlet RSS feeds. You can literally see individual critic scores appearing in the Review Feed widget before the aggregate Metacritic/OpenCritic number forms. The first 5-10 reviews set the tone, but they're not the final score — and that gap between early signal and final number is where the opportunity lives.

Review drift — the second leg

As more reviews come in over hours and days, the aggregate score moves. We call this review drift, and we track it with a sparkline that shows the running average over time.

A game that starts at 88 and drifts down to 82 as smaller outlets and more critical reviewers weigh in tells a very different story than one that holds steady at 88. The drift direction is often a leading indicator for the stock move's second leg. The initial score sets the direction; the drift determines whether the move extends or reverses.

I've seen cases where the first batch of reviews looked solid — scores in the low 80s, market barely reacted — but the drift sparkline showed a clear downward trend. By the time the aggregate settled at 74, the stock had already started falling. Watching the drift, you could see it coming.

Social amplification — the multiplier

This is the part most people miss. A bad review score with 500 Reddit comments within an hour moves the stock 2-3x more than a bad score with 50 comments. Social buzz is the multiplier.

We track this across four platforms:

Reddit — mention volume across r/games, r/gaming, and r/pcgaming, the three largest gaming subreddits. When a bad review hits the front page with thousands of upvotes, it goes from "niche gaming news" to "mainstream financial news" fast.
YouTube — creator coverage from six major channels (IGN, gameranx, Skill Up, ACG, AngryJoe, Worth A Buy). Multiple negative videos from trusted creators within 24 hours of embargo lift is a strong signal that retail sentiment will turn negative.
Twitch — live viewership and active stream counts. High viewer counts on launch day confirm mainstream interest. Declining viewership within the first week suggests the game isn't retaining attention.
Discord — server member counts, channel counts, and direct invite links. A game with a large, active Discord community has a higher floor for post-launch engagement.

Steam launch data — the reality check

Player counts and user review sentiment provide a second opinion on the critic score. Sometimes critics and users disagree — we call this a contrarian signal. If critics say 85 but Steam reviews are "Mixed," that's a red flag the stock could give back gains. If critics say 72 but Steam users love it, the stock drop might be overdone.

We also scan Steam reviews for disaster keywords — "refund," "broken," "unplayable," "crash" — and track the player count trajectory over the first few days. A game that launches with 200k concurrent players but drops to 40k within 48 hours is a very different picture than one that holds steady.

What we actually built

We didn't build one widget and call it done. The signal requires context, and context requires multiple data sources viewed together. That's why we built seven.

Launch Health — The flagship composite score. Six weighted factors: critic score vs expected (40%), Steam user sentiment (20%), player count trajectory (15%), review velocity (10%), disaster keywords (10%), and Twitch viewership (5%). Produces a single 0-100 score with buy/sell classification. Also shows embargo countdown timers and sentiment trajectory sparklines.

Review Feed — Individual critic reviews as they drop, with a running average, review drift sparkline, velocity badges, and RSS-matched article counts. This is where you watch the score form in real time. The drift sparkline is the key innovation — it shows you whether the score is settling up or down before the final number is public.

Game Releases — Upcoming launches with embargo dates, franchise expected scores based on historical data, IGDB hype counts and follows, community ratings, platform chips, and hype-vs-player conversion signals. The tier filter lets you focus on Tier 1 publishers where the thesis is strongest. DLC counts show post-launch content commitment.

Stock Heatmap — All 28 companies grouped by region (Asia, Europe, Americas). Click any company for a franchise history detail panel: per-franchise average scores, launch counts, stock impact percentages, best and worst launches, and overall company stats. This is the research layer — you use it before an event to understand a publisher's track record.

Review Impact History — Historical score-to-stock events with a scatter chart showing the correlation visually. Full backtest results with win rate, total PnL, return percentage, individual trade breakdowns (wins/losses, average return per trade), and strategy description. Sector momentum banner and cross-publisher sympathy percentage give you the macro context.

Social Buzz — All four social platforms in one view, correlated with the publisher's stock ticker. Reddit mention volume, YouTube creator coverage, Discord member and channel counts with invite links, and Twitch live viewer counts with active streams. Search for any game and see the full social picture.

Gaming Sector — Three views in one widget. The overview shows all 28 stocks by region with catalyst flags and historical event counts. The momentum view shows hit rate, average impact, positive/negative event split, and Tier 1 stats. The correlation view measures same-direction moves between publishers, filterable by region.

The deviation model

This is the core idea and it's worth spelling out clearly, because it's counterintuitive if you've never thought about it this way.

The absolute review score doesn't predict the stock move. The deviation from expected does.

We calculate expected scores from franchise history. If a series has averaged 82 across five entries, the market broadly expects the next one to land near 82. Score 92? That's a +10 deviation — strong buy signal. Score 70? That's -12 — the stock is going to get hit.

Here's why this matters: a Metacritic 75 for a franchise that historically averages 70 is bullish. The publisher beat expectations. The same 75 for a franchise that averages 90 is catastrophic. That's a -15 deviation. Same score, completely opposite stock reaction.

IGDB hype data adds another adjustment layer. A franchise might average 82 historically, but if pre-release hype is through the roof — massive trailer views, IGDB follows spiking, preorder figures leaking high — the effective market expectation is higher than 82. When a hyped game delivers an "average" 82 score, the stock still drops because "average" wasn't what anyone was pricing in. The hype-vs-players conversion signal in the Releases widget catches exactly this: overhyped titles that technically met franchise averages but missed inflated market expectations.

Cross-publisher correlation

One thing that surprised me when I dug into the data: game publishers don't trade in isolation. When one publisher drops on a bad review, peers often follow within the same week. We call this sympathy trading, and we measure it.

The Gaming Sector widget shows same-direction move percentages between publishers during review events, filterable by region (Asia, Europe, Americas). When correlation is high — 60%+ — a single review event becomes a sector event. A bad review for one publisher drags peers down. A hit game lifts the sector.

This creates opportunities beyond the direct play. If Publisher A drops 8% on a bad review and Publisher B drops 3% in sympathy despite having no news of its own, Publisher B might be mispriced. Or if sector correlation is running hot and you have a strong thesis on an upcoming review event, you can size across multiple tickers to capture the sector move rather than concentrating on a single stock.

The region filter matters here. Asian publishers (TSE, KRX) tend to correlate more tightly with each other than with European or US publishers, partly because of overlapping trading hours and shared analyst coverage.

Tier 1 vs Tier 2

Not all publishers are equally sensitive to review scores. We classify them into tiers based on revenue concentration:

Tier 1 — high sensitivity. Pure-play publishers where gaming is the core business and one title can make or break the year. Review events can move these stocks 10-25%. CD Projekt is the canonical example — The Witcher and Cyberpunk are essentially the entire company. Capcom, Krafton, Embracer, Team17, Paradox — these are companies where a single launch outcome materially changes the financial outlook.

Tier 2 — moderate sensitivity. Diversified publishers where gaming is significant but not the only revenue stream. Review scores matter but are diluted by other business lines. EA has FIFA/FC, Madden, and a large live-service portfolio — one bad review for a new IP won't sink the stock. Ubisoft, Take-Two, and Bandai Namco fall here. The moves are smaller (3-8%) and more noise-prone.

The tier filter in the Releases widget lets you focus on Tier 1 publishers where the thesis is cleanest. If you're trading review events, Tier 1 is where the signal-to-noise ratio is highest.

The exchange complication

We track companies on 8 exchanges across 3 time zones: Tokyo, Seoul, Warsaw, Paris, Stockholm, Helsinki, London, and US (NASDAQ/NYSE). This means a review embargo that lifts at 10am Eastern might not impact a Tokyo-listed stock until the next Asian trading session — a 14+ hour delay.

This is actually an advantage if you know how to use it. If a major review drops during US hours and you've already read the signal, you know how Asian-listed peers are likely to open before the market gets there. The Gaming Sector widget's region-based correlation view helps you estimate the likely sympathy move.

Why I think this matters

There's a whole industry built around tracking earnings announcements and analyst upgrades. Entire platforms exist to monitor insider trades and 13F filings. Bloomberg terminals have earnings surprise trackers. Every brokerage app has an earnings calendar.

But review scores? The data is public, the pattern is well-documented in academic literature, and the moves are significant — yet I couldn't find a single tool that systematically maps review events to stock tickers across global exchanges. The information is scattered across OpenCritic, IGDB, Reddit, YouTube, Steam, and Discord. Nobody was pulling it together and connecting it to stock tickers.

So we built one. Twenty-eight companies. Eight exchanges. Three time zones. Six data sources. Seven widgets.

Is it niche? Absolutely. There are maybe 4-5 major review events per year that generate tradeable stock moves. But when they happen, the moves are large, predictable in direction (if not magnitude), and the signal comes before the market has fully priced it in.

When this doesn't work

I'd be lying if I said this was a guaranteed money printer. There are real limitations.

Earnings trump reviews. If the publisher is reporting quarterly earnings within days of a review embargo, the earnings data dominates. A great review score won't save a stock that just missed revenue estimates by 15%. Always check the earnings calendar before trading a review event.

Diversified publishers absorb the hit. Sony isn't dropping 10% because one PS5 exclusive reviewed badly. Their gaming division is one piece of a larger business that includes semiconductors, music, pictures, and financial services. The thesis only works cleanly on Tier 1 pure-play publishers where one title genuinely matters to the bottom line.

Review scores don't always predict sales. Some games sell brilliantly despite mediocre reviews — brand power, franchise loyalty, and limited competition can carry a title commercially. Some games review well but sell poorly because of niche genre appeal, bad marketing timing, or a crowded release window. The review-to-stock connection works because scores correlate with sales, not because they guarantee them.
If you're interested in the full thesis, including the review timeline playbook, risk management around earnings overlap, and how to handle exchange hour mismatches, we wrote a comprehensive guide.

Seven widgets covering the full lifecycle of a review event: from embargo countdown to score formation, social amplification, Steam reality check, sector correlation, and historical backtesting. Add them to your dashboard, pick a Tier 1 publisher with an upcoming embargo, and watch how it plays out.

The feature page has the full breakdown of what's included, and the help docs cover every widget in detail.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

What Happens When a Solo Dev Goes Down

NydarTrading — Fri, 06 Mar 2026 09:37:44 +0000

I built Nydar by myself. No co-founder, no engineering team, no DevOps person on call. Just me, a VPS, and a lot of late nights.

Last week I found out what happens when the "just me" part breaks.

The short version

I got hit with a serious infection. Thought it was COVID at first — it wasn't. Tested negative, got admitted, spent a week on IV antibiotics around the clock. I was too ill to look at my phone, let alone SSH into a server and check logs.

For a solo operation, that's the nightmare scenario. There's no colleague to ping on Slack. No on-call rotation. No "hey can you keep an eye on things while I'm out." It's just... whatever you built, running on its own, for as long as it takes.

What actually happened

Nothing. In the boring sense.

The API server stayed up the entire time. The ML models kept generating signals. The data feeds kept pulling from exchanges. The automated trading bot (not public yet, but it's running internally) executed 25 trades across the week, holding 5 positions when I finally checked in. Market hours caching kicked in as normal — the system backed off overnight and on weekends to conserve API quota, then spun back up at market open.

Nobody emailed me to say the site was down. Because it wasn't.

I'm not saying this to brag. I'm saying it because it surprised me a bit. When you're deep in the weeds every day — fixing bugs, tweaking indicators, optimising API calls — you don't always step back and notice that the thing you built actually works without you touching it constantly.

Why this matters if you're a user

If you use Nydar for paper trading, your positions, your watchlists, your dashboard layouts, your alerts — none of that depends on me being awake. The backend is a single Python process running behind Apache on a Linux box. It's not clever infrastructure. It's just built properly.

That's a deliberate choice. I spent time on the boring stuff that doesn't make good screenshots: API quota management, market hours awareness so the system doesn't burn through rate limits at 2am, proper error handling that degrades gracefully instead of crashing. The kind of work that only pays off when you're not around to manually intervene.

Last week was the first real test of all that, and it passed.

The solo dev tradeoff

There's an honest conversation to have about the risks of a one-person operation. I've worked on institutional systems — I spent years at Cowen on Wall Street, worked on ENNI (a £500M infrastructure programme), and helped deliver IT systems for Ireland's National Children's Hospital (a €2.24B project). I know what "proper" engineering looks like with teams of dozens.

Nydar isn't that. It's one person making every decision, writing every line of code, handling every deployment. The upside is speed and coherence — I can ship a feature in a day that would take a committee three sprints to scope. The downside is that when I'm on a hospital bed with a drip in my arm, nobody's shipping anything.

But here's the thing I keep coming back to: most of the trading platforms people use daily started as solo projects or tiny teams. The early versions of most software you rely on were held together by one or two people who cared enough to get the details right. Scale comes later. Resilience comes from caring about the boring stuff.

What I'm not going to do

I'm not going to pretend this was some profound life lesson. I got sick, I got treated, I'm recovering. The platform kept running because I spent time making it keep running. That's engineering, not philosophy.

I'm also not going to make promises about what's coming next. I'm still recovering and my head's not fully in it yet. When it is, you'll see it in the changelog, not in a blog post full of vague roadmap promises.

The takeaway

If you're evaluating trading tools, ask yourself: what happens when things go wrong? Not "what features does it have" — that's the easy question. What happens when the developer is unavailable, when an API goes down, when it's 3am and nobody's watching?

For Nydar, the answer last week was: everything kept working. I'll take that over a feature list any day.

If you want to see what a resilient trading platform looks like, start paper trading on Nydar — no sign-up required.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

Why Paper Trading Should Be the Default, Not an Afterthought

NydarTrading — Mon, 02 Mar 2026 17:47:41 +0000

There's something broken about how most trading platforms work.

You sign up. You land on a dashboard full of charts, numbers, and buttons. You're immediately prompted to connect a brokerage account or deposit funds. Maybe there's a "demo mode" buried somewhere in the settings, but the entire onboarding flow pushes you toward real money as fast as possible.

This is backwards. And it's not just bad UX — it's genuinely irresponsible.

The industry's incentive problem

Let's be honest about why platforms do this. Most trading platforms make money from commissions, payment for order flow, or spread markups. A user paper trading generates zero revenue. A user depositing $5,000 and placing real trades generates revenue from day one. The financial incentive is to get users into real money as quickly as possible, and every design decision flows from that.

This creates a perverse dynamic where the platform's interests are directly opposed to the user's interests. A new trader depositing money on day one is almost certainly going to lose it. The statistics on this are grim: studies consistently show that 70–80% of retail traders lose money. That number gets worse for traders who skip the learning phase entirely.

The FCA in the UK now requires CFD platforms to display their client loss percentages. Next time you see "76% of retail investor accounts lose money when trading CFDs with this provider" in tiny print at the bottom of a landing page, ask yourself: does this platform's onboarding do anything to reduce that number, or does it just disclose it and move on?

Paper trading doesn't fix the statistics. But it gives people a fighting chance to discover whether they have any aptitude for this before they hand over their rent money.

What "paper trading" actually means

The term comes from the pre-internet era when aspiring traders would literally write hypothetical trades on paper. "Buy 100 shares of IBM at $42." Then you'd check the newspaper the next day and calculate your P&L by hand. No execution, no risk, no real money. Just pencil, paper, and the stock pages.

Modern paper trading is the same concept with real infrastructure behind it. When you paper trade on Nydar, you get $100,000 in virtual capital and access to the same real-time market data, the same charting tools, the same technical indicators, and the same signal analysis that a live trader sees. The only difference is that your orders execute against a simulation engine rather than a real exchange.

This distinction matters more than it sounds. A lot of platforms offer "demo mode" that runs on delayed data, has limited features, or expires after 14 days. That's not paper trading — it's a product trial dressed up as education. Real paper trading means you can stay in simulation mode indefinitely, with the full feature set, using live data. There's no countdown timer pushing you toward a credit card form. There's no feature gating that makes the demo feel like a lesser experience. If you can do it with real money, you can do it with paper money.

Why we built Nydar around paper trading

When we started building Nydar, the question wasn't "should we add paper trading?" It was "why would we let anyone trade real money before they've proven they can trade fake money?"

I spent years in institutional finance — at Cowen Inc on Wall Street and managing large capital projects in London. One thing that's true across every professional trading desk, every asset manager, and every fund I've seen: nobody puts real money on a new strategy without testing it first. Nobody. Not the quant funds, not the discretionary traders, not the prop desks. Everyone simulates before they commit capital.

Prop firms have formalised this into evaluation periods. Before you trade the firm's capital, you trade a simulated account for weeks or months. They measure your drawdown, your consistency, your risk management. If you can't manage fake money, you don't get real money. This isn't controversial in professional trading — it's standard practice.

But retail platforms — the ones serving people with the least experience and the most to lose — push users straight to real money. It's the exact inverse of how the professionals do it. The people who need the most practice get the least.

So we made paper trading the default. When you sign up for Nydar, you start in paper mode with $100,000 virtual capital. Not because we don't want your money (we'll have premium tiers eventually), but because starting with simulation is the right thing to do. You should know how to read a chart, place an order, set a stop loss, and manage a position before a single real dollar is at stake.

What our paper trading engine actually does

Since paper trading is core to the product rather than a bolted-on feature, we invested in making it behave like the real thing. A simulation is only as useful as it is realistic.

Realistic execution. Orders fill at market prices using real-time data from live exchanges. Limit orders sit until the price hits your level — they don't magically fill at whatever price you typed. This matters because understanding order types and execution is half the battle for new traders. If you place a limit buy at $42.00 and the stock bounces off $42.05, your order doesn't fill — just like it wouldn't on a real exchange. You learn that limit orders require patience and that getting filled isn't guaranteed.

Portfolio tracking. Every paper trade flows into a full portfolio view with unrealised P&L, average entry prices, margin usage, and position-level analytics. This is the same data you'd see with a real brokerage connection. The muscle memory of checking your positions, calculating your risk, and deciding whether to add or cut — that all transfers directly to live trading. We track your realised P&L separately so you can see not just where you stand now, but how all your closed trades performed in aggregate.

Persistent state. Your paper trades aren't wiped when you close the browser. They persist across sessions, accumulate a track record, and build a history you can review. This is essential for the learning process. After a month of paper trading, you should be able to look back at your trades and identify patterns: "I keep losing on counter-trend entries" or "my winners run longer than my losers." Without persistent history, every session starts from zero and the learning compounds much more slowly.

Full toolchain access. This is where most demo modes fall short. Paper trading on Nydar isn't a stripped-down experience. You have access to the stock screener to find setups, technical signals to confirm them, the trading journal to record your reasoning, alerts to notify you when prices hit your levels, and the full suite of 105 technical indicators to build your analysis. The paper account is the live account with a different ledger. Nothing is locked behind a paywall or held back for "real" users.

Three markets, three different lessons

You can paper trade crypto, stocks, and forex from the same Nydar account. Most people start with one asset class, but each market teaches you different things — and paper trading is the safest way to discover those differences.

Crypto runs 24/7. There's no closing bell. No market hours. Your positions are live on Saturday morning, on Christmas Day, at 3 AM. This teaches you something stocks can't: overnight risk is real, and it happens while you're sleeping. New crypto paper traders often wake up to 8% drawdowns they never saw happen in real time. That's a valuable lesson to learn on virtual money. You quickly develop opinions about whether to use stop losses overnight (which can get triggered by low-liquidity wicks) or to size positions small enough that overnight moves don't matter.

Forex moves on macro events. Currency pairs react to interest rate decisions, employment data, GDP releases, and central bank speeches — events that stock traders might not pay attention to. Paper trading forex teaches you to check the economic calendar before you open a position. There's nothing quite like getting stopped out of a EUR/USD trade because you didn't know the ECB was announcing rates at 1:45 PM. Better to learn that at zero cost.

Forex also introduces you to session overlaps. The London–New York overlap (1 PM–5 PM GMT) is when EUR/USD and GBP/USD have the tightest spreads and highest volume. The Asian session trades differently. Paper trading across sessions teaches you when your strategy works and when it doesn't — without paying for the education.

Stocks have gaps. The US stock market opens at 9:30 AM and closes at 4 PM Eastern. Between sessions, news happens. Earnings get released. Analyst upgrades come out. When the market reopens, prices can gap up or down significantly from the previous close. If you held a position overnight and the stock gaps down 5% on earnings, your stop loss at 2% below your entry was useless — the price blew right past it.

Paper trading stocks teaches you about gap risk, about the difference between pre-market and after-hours trading, and about why position sizing matters more than stop placement for overnight holds. These are lessons that cost real money if you learn them the hard way.

Paper trading vs backtesting

We get asked this a lot: "If I can backtest a strategy against historical data, why do I need to paper trade it too?"

They're complementary, not interchangeable.

Backtesting tells you whether a strategy would have worked over a historical period. It's powerful for validating an edge — testing whether your RSI oversold bounce strategy actually produces positive expectancy over 500 historical trades. But backtesting has a fundamental limitation: you already know what happened. Even if you're not consciously peeking at future bars, the emotional experience of backtesting is nothing like real-time trading.

Paper trading is forward-looking. You don't know what the next candle will be. You have to make decisions with incomplete information, manage the discomfort of a position moving against you, and resist the urge to override your plan when things get choppy. The data comes at you in real time, just like it will with real money.

The ideal workflow is:

Backtest to validate the strategy's historical edge
Paper trade to validate that you can execute it in real time
Micro-size live trade to validate that you can execute it with real money at stake

Each step tests a different thing. Backtesting tests the strategy. Paper trading tests your execution. Live trading tests your psychology. Skipping any of the three leaves a gap.

The psychology gap (and why we're honest about it)

Here's where we have to be straight with you: paper trading has a real limitation, and anyone who tells you otherwise is selling something.

The limitation is psychology. When you paper trade, there's no fear. A 5% drawdown on virtual money doesn't make your stomach drop. A stop loss getting hit doesn't trigger the impulse to move it further away "just this once." A winning streak doesn't make you overconfident and double your position size.

Real money introduces real emotions, and those emotions are responsible for a huge percentage of trading losses. The strategy that worked beautifully in paper mode falls apart when real money is on the line — not because the strategy changed, but because you changed. You started hesitating on entries, cutting winners early, holding losers too long, and revenge trading after a loss. These are human responses that no amount of simulation can fully prepare you for.

We acknowledge this directly in our paper trading guide. It's not something we hide or gloss over. Paper trading teaches you the mechanics and the strategy. It doesn't teach you the emotional discipline. That comes from small real-money exposure, which is a separate stage.

The right sequence is:

Paper trading — learn the mechanics, test your strategy, build a track record
Micro-size real trading — 10–25% of your intended position size, feel the emotions
Scale gradually — increase size as you prove you can stay disciplined under pressure

Platforms that skip step 1 are setting users up for an expensive step 2.

What "good" paper trading behaviour looks like

After watching how people use Nydar's paper trading over months of development and user feedback, we've noticed patterns that separate the people who eventually trade well from the people who don't.

They treat it like real money. This sounds obvious, but it's the single biggest differentiator. The users who paper trade with realistic position sizes — risking 1–2% per trade on a $100K account, so $1,000–$2,000 per position — learn far more than the users who YOLO their entire balance into a single crypto trade "because it doesn't matter."

It does matter. Not because of the money, but because of the habits. If you paper trade recklessly, you build reckless habits. Those habits don't magically disappear when real money enters the picture. They get worse.

They keep a journal. Our trading journal exists specifically for this. The users who write down why they entered a trade, what they expected to happen, and what actually happened — they improve measurably over weeks. The users who just click buy and sell and check their P&L at the end of the day don't. Journaling forces you to articulate your reasoning, and articulating your reasoning is how you find the holes in it. We wrote about this in more detail in our post on why trading journals matter.

They focus on process, not outcome. A paper trade that followed your plan perfectly but lost money is a good trade. A paper trade that broke every rule but happened to profit is a bad trade. This is counter-intuitive and hard to internalise, but it's the foundation of sustainable trading. Paper trading is the low-stakes environment where you can learn to evaluate trades by process rather than outcome — before the emotional weight of real money makes that evaluation almost impossible.

They give it time. The users who paper trade for a week and then go live are barely better off than the users who never paper traded at all. You need months, not days. You need to experience a market correction, a choppy range, a news-driven spike, and a boring sideways grind. If you've only paper traded during a bull market, you have no idea how your strategy performs when conditions change — and they always change.

They don't reset after a blowup. This one is controversial, but we feel strongly about it. When users blow up their paper account — and many do — the instinct is to hit reset and start fresh with a clean $100K. We think that's a mistake. The blown-up account is the most valuable data you have. Look at it. Study the trades that got you there. Was it one catastrophic position or a slow bleed from a hundred bad decisions? Did you size too aggressively? Ignore your stops? Revenge trade after a losing day?

Resetting erases the evidence. Keep the wreckage. Learn from it. Then adapt your strategy and trade out of the hole — or at least try to. The experience of managing a damaged account is something you'll need if you ever trade real money, because drawdowns happen to everyone.

The "but I learn faster with real money" argument

We hear this one a lot. "I don't take paper trading seriously because there's no real consequence. I need skin in the game to focus."

There's a kernel of truth here. Real consequences do sharpen attention. But this argument is usually used to justify skipping the learning phase entirely, and that's where it falls apart.

You wouldn't learn to fly a plane by skipping the simulator and going straight to a real cockpit. You wouldn't learn surgery by skipping the cadaver lab. The "I learn better with real stakes" crowd isn't wrong about the psychology — they're wrong about the sequencing.

Learn the mechanics first. Learn which buttons do what, how orders work, what support and resistance look like on a live chart, how to read volume, how moving averages behave in different market conditions. Do all of that with fake money. Then, when you switch to real money, the only new variable is the emotional component — and that's hard enough to manage on its own without also trying to figure out how limit orders work at the same time.

There's also a practical argument: mechanical mistakes with real money are expensive and completely avoidable. Buying when you meant to sell. Entering a market order when you meant limit. Setting a stop loss on the wrong side of your entry. Typing the wrong quantity and buying 1,000 shares instead of 100. These are button-pressing errors, not strategy errors, and they happen to everyone at the start. Better to make them on paper.

What we got wrong (and fixed)

Building paper trading as a core feature rather than an afterthought meant we made mistakes that pure-demo platforms never encounter.

Early on, our paper trading engine used slightly delayed prices for order fills — about a 500ms lag between the quoted price and the execution price. We thought this was being realistic about slippage. In practice, it confused users who couldn't understand why their limit order at $42.00 filled at $42.03. We switched to immediate fills at the quoted price for market orders and exact-price fills for limit orders when the price crosses the level. Paper trading should teach you about slippage conceptually, but simulating it with artificial delays just creates frustration without genuine learning.

We also initially capped the paper trading period at 30 days. The thinking was that this would encourage people to move to live trading. What actually happened was that engaged users who were genuinely learning hit the 30-day wall and left the platform entirely. The users who blew up their paper account in 3 days and switched to real money were the ones who should have spent longer practising. We removed the cap entirely. Paper trade for a year if you want. The learning compounds over time, and artificially cutting it short helps nobody.

Another mistake was not building the journal integration from day one. For the first few months, paper trades and journal entries were separate — you could record trades and you could write journal notes, but they weren't linked. Users had to manually cross-reference timestamps to match a journal entry to a specific trade. This friction meant almost nobody journaled their paper trades, which meant they weren't getting the feedback loop that makes paper trading genuinely educational. When we linked them, journal usage for paper trades doubled almost immediately. Reducing friction matters.

The bigger picture

Paper trading isn't just a feature. It's a philosophy about what a trading platform owes its users.

If you're going to give someone access to markets — with all the financial risk that entails — you have an obligation to also give them a safe place to learn. Not a 14-day trial. Not a crippled demo with delayed data. A real, full-featured simulation environment that they can use for as long as they need, with the same tools and the same data that live traders get.

The trading industry has a retention problem, and it's self-inflicted. Platforms acquire users, those users lose money quickly because they weren't prepared, and they leave — often with a bitter taste and a smaller bank account. The lifetime value of that user is negative when you account for support costs and the reputational damage of another person telling their friends that "trading is a scam."

The alternative is to invest in that user's education upfront. Let them paper trade. Let them fail safely. Let them discover whether this is something they want to pursue seriously — and give them the tools to get good at it before they put real money on the line. The users who survive that process and go on to trade profitably are the ones who stick around for years. They're the ones who tell their friends about the platform. They're the ones who upgrade to premium when it exists.

This is why paper trading is the default on Nydar. It's not a stepping stone to the "real" product. It is the product — at least until you've proven, to yourself, that you're ready for what comes next.

Most platforms are designed to extract money from traders as quickly as possible. We'd rather build something that makes traders better. If that takes longer to monetise, so be it. The traders who survive the learning curve are the ones who'll stick around for years. The ones who blow up on day one are gone forever.

We'd rather have the first kind.

Ready to start? Paper trading on Nydar is free with $100,000 virtual capital across crypto, stocks, and forex. No credit card, no time limit. Get started here.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

Why We Built a Pine Script Indicator Engine (And What Traders Are Doing With It)

NydarTrading — Fri, 27 Feb 2026 17:49:39 +0000

We ship 105 technical indicators out of the box. RSI, MACD, Bollinger Bands, ADX, ATR, Stochastic, Ichimoku — the full catalogue. For most traders, that's more than enough. You could build a solid strategy using three of them and never touch the rest.

But the traders who stick around — the ones who come back every day, who build real edge, who actually make money — they always end up wanting something we haven't built yet.

One wanted a triple-confirmation oversold indicator that only fires when RSI, Bollinger Band touch, and volume spike happen simultaneously. Another wanted a custom momentum oscillator that weights recent price action differently during high-volatility regimes. A third wanted di_plus and di_minus with custom smoothing periods that don't match any standard ADX implementation.

A forex trader wanted a session-aware VWAP that resets at the London open rather than midnight UTC. A crypto trader wanted an indicator that tracks the spread between spot price and perpetual futures funding rate — something that doesn't exist in any standard library because it requires combining two different data feeds.

We kept getting the same request in different forms: "Can I build my own indicator?"

So we built an engine that lets you do exactly that.

The problem with "just add more indicators"

The obvious solution to "traders want more indicators" is to keep adding them to the platform. And for a while, that's what we did. Every time someone asked for something we didn't have, we'd evaluate whether it was worth adding to the core library.

This doesn't scale. Here's why.

Every indicator we add becomes something we have to maintain. It needs documentation. It needs to handle edge cases across crypto, stocks, and forex — and those asset classes behave differently in ways that affect calculations. A volume-based indicator that works perfectly on stock data breaks on forex pairs where "volume" means tick count rather than actual shares traded. Our 105 built-in indicators represent a significant maintenance surface, and each one had to be tested against all three asset classes before we shipped it.

More importantly, the requests are infinitely varied. Traders don't just want standard indicators — they want combinations of indicators with custom logic layered on top. They want moving averages that switch between SMA and EMA based on volatility. They want RSI that uses a different lookback period during trending versus ranging markets. They want things that don't have names yet because they invented them.

That last point is worth emphasising. Some of the most effective indicators we've seen aren't published in any textbook. They're the product of a trader spending months watching a specific market, noticing a pattern, and codifying it. The trader who watches the BTC/USDT order book all day and realises that a specific ratio of bid-to-ask volume at certain price levels precedes a move — that's not something we can anticipate. That insight belongs to the trader. They just need a way to express it.

You can't pre-build infinity. You have to give people a language.

Why Pine Script syntax

When we decided to build a custom indicator engine, the first decision was the scripting language. We had three realistic options:

JavaScript. We're a web platform, so this was the obvious choice from a technical standpoint. The browser already has a JS runtime. But giving users access to a full JavaScript runtime inside a trading chart is a security nightmare. Even sandboxed, the attack surface is enormous — you'd need to block network access, filesystem access, infinite loops, memory bombs, and a hundred other vectors. And JS is verbose for numerical computation. Nobody wants to write Array.from({length: period}, (_, i) => close[i]).reduce((a, b) => a + b, 0) / period when they mean "average of last N closes."

A custom DSL. We could design our own language from scratch, tailored exactly to our needs. Clean, safe, optimised for time-series data. But nobody would know how to write it. The learning curve would kill adoption before it started. Every user would need to learn a new language just to do something they might already know how to express. We'd also need to write all the documentation, tutorials, and examples from scratch — a massive investment with no guarantee anyone would bother reading it.

Pine Script syntax. And this is what we chose. Not because we're trying to clone any particular platform, but because Pine Script has become the de facto standard for expressing trading logic. Thousands of tutorials exist online. Every trading forum has Pine Script examples. When a trader googles "RSI divergence indicator code" or "di_plus pine script," the results are overwhelmingly Pine Script.

By adopting Pine Script syntax, we inherited an entire ecosystem of knowledge. Traders can take code they've written elsewhere, paste it into our custom indicator editor, make minor adjustments, and have it running on live data in minutes. They don't need to learn anything new. The syntax they already know just works.

There's a pragmatic angle too. Pine Script is purpose-built for time-series computation on OHLCV data. The language assumes you're working with price bars. Variables implicitly reference the current bar. Built-in functions like ta.sma() and ta.rsi() handle the lookback windowing automatically. This makes trading logic dramatically more concise than equivalent code in a general-purpose language, which means fewer bugs and faster iteration for the trader.

What the engine actually does

Let me walk through what happens when you write a custom indicator on Nydar. This isn't a tutorial — we have a comprehensive Pine Script guide and detailed custom indicators documentation for that — but understanding the architecture explains why it works the way it does.

When you write indicator code, it goes through three stages:

1. Parsing and validation. Your code is parsed into an abstract syntax tree. We check for syntax errors, undefined variables, type mismatches, and potentially dangerous operations. This is where we catch mistakes before they hit your chart. Unlike a general-purpose language, we can validate that your code will produce a plottable result — it must output at least one series of values. We also enforce resource limits at this stage: no unbounded loops, no recursive function calls deeper than a set threshold, no allocations above a memory ceiling. This is how we keep the engine safe without needing a full sandbox.

2. Compilation to an execution plan. The parsed code is compiled into a series of operations that our engine can execute efficiently. This is where Pine Script's design really helps us. Because the language is inherently bar-by-bar — every statement implicitly iterates over the historical price data — we can optimise the execution path in ways that wouldn't be possible with arbitrary code. Common subexpressions get deduplicated. If your indicator computes ta.sma(close, 20) in three different places, we calculate it once. Built-in function calls get routed to our optimised implementations rather than being interpreted line by line.

3. Execution against price data. The execution plan runs against the current chart's OHLCV data. Results are cached and only recomputed when new bars arrive or parameters change. This is critical for real-time performance — when a new tick comes in, we don't recalculate the entire history. We incrementally update only the current bar and any values that depend on it. On a chart showing a year of 5-minute data, that's the difference between recalculating 100,000+ bars per tick versus updating one.

The result is an indicator that feels native. It updates in real time, it works across all timeframes, and it scales to whatever history depth the chart is showing. A user shouldn't be able to tell the difference between a built-in indicator and a custom one — that was our design goal, and we hit it.

Real examples from our users

The best part of building a custom indicator engine is seeing what people do with it that you never anticipated. Here are some of the more interesting indicators traders have built:

Triple-confirmation oversold signal

This was the original request that pushed us to build the engine. The logic is straightforward — only signal when three independent conditions agree:

//@version=5
indicator("Triple Oversold", overlay=true)
rsiOversold = ta.rsi(close, 14) < 30
bbTouch = close <= ta.sma(close, 20) - 2 * ta.stdev(close, 20)
volSpike = volume > 2 * ta.sma(volume, 20)
signal = rsiOversold and bbTouch and volSpike
plotshape(signal, style=shape.triangleup, location=location.belowbar, color=color.green, size=size.normal)

It fires rarely — maybe once or twice a month on any given stock — but when it does, the setup has a high probability of at least a short-term bounce. The trader who built this told us it was more valuable than any single built-in indicator because it eliminated the manual work of checking three separate panels and trying to eyeball whether all three conditions were true at the same bar. That's the kind of thing humans are bad at and computers are good at.

Volatility-adaptive moving average

A forex trader built a moving average that automatically adjusts its period based on ATR:

//@version=5
indicator("Adaptive MA", overlay=true)
atrVal = ta.atr(14)
atrMean = ta.sma(atrVal, 100)
ratio = atrVal / atrMean
adaptPeriod = math.round(20 * ratio)
adaptPeriod := math.max(5, math.min(adaptPeriod, 50))
adaptMA = ta.sma(close, adaptPeriod)
plot(adaptMA, color=color.blue, linewidth=2)

During low-volatility consolidation, the ratio drops below 1 and the period shortens — making the MA more responsive to breakouts. During high-volatility trends, the ratio rises and the period extends — filtering out noise and keeping you in the trade. The result is a single line that adapts to market conditions instead of requiring the trader to manually switch between fast and slow MAs depending on what the market is doing.

Custom ADX with `di_plus` / `di_minus` smoothing

This is the one that shows up in our search console data. A lot of traders want the directional movement components (di_plus, di_minus) from the ADX calculation, but with non-standard smoothing:

//@version=5
indicator("Custom DI", overlay=false)
period = input.int(7, "DI Period")
smooth = input.int(5, "Smoothing")
upMove = high - high[1]
downMove = low[1] - low
plusDM = upMove > downMove and upMove > 0 ? upMove : 0
minusDM = downMove > upMove and downMove > 0 ? downMove : 0
atrVal = ta.ema(ta.tr, period)
diPlus = 100 * ta.ema(plusDM, period) / atrVal
diMinus = 100 * ta.ema(minusDM, period) / atrVal
plot(ta.ema(diPlus, smooth), "DI+", color=color.green)
plot(ta.ema(diMinus, smooth), "DI-", color=color.red)

The default 14-period Wilder smoothing in the standard ADX is tuned for daily charts. If you're trading 5-minute bars, that 14-period lookback covers just over an hour — not enough context for some strategies, too much for others. This version lets you set both the DI period and an additional smoothing layer independently. Several of our users run this on scalping setups where the standard ADX is too laggy.

Multi-timeframe divergence scanner

One of the more ambitious builds — a user created an indicator that checks for RSI divergence across three timeframes simultaneously. Price making higher highs while RSI makes lower highs on the 15-minute, 1-hour, and 4-hour charts at the same time. When all three align, it flags a high-probability reversal setup.

This required accessing multiple timeframe data within a single indicator, which was one of the features we had to add to the engine after launch. The request.security() function lets you pull data from a different timeframe than the one the chart is displaying. It's one of those features where the first user who asked for it made us realise we'd shipped the engine incomplete — of course you need multi-timeframe access. Trading decisions are almost never made on a single timeframe.

The pitfalls we help you avoid

Building an indicator engine also means watching people make mistakes, and then building guardrails. The three most common issues in custom indicator development are well-documented in technical analysis literature, but they're easy to fall into when you're writing code:

Repainting. An indicator "repaints" when it changes its historical values as new data arrives. This is the most dangerous pitfall because it makes backtesting results look better than they are. If your indicator uses close on the current bar and the bar hasn't finished yet, every tick changes that value — and when you look at the historical chart later, you only see the final values. It looks like the indicator was right all along, but in real time it was flickering between states. Our engine flags common repainting patterns during the validation stage and warns you before the indicator runs.

Overfitting. This is the custom indicator equivalent of curve-fitting a backtest. You tune 6 parameters until your indicator perfectly identifies every reversal in the last year of data, and then it fails completely on new data because you've modelled the noise rather than the signal. We don't have a magic solution for this — it's fundamentally a statistical problem — but we do show parameter sensitivity warnings. If changing a parameter by 1 dramatically changes the number of signals, that's a red flag.

Lookahead bias. Using future data in calculations, usually accidentally. The classic example is referencing close in a condition that's supposed to fire at the open — the close price isn't known at the open, so the indicator "works" on historical data but can't work in real time. Pine Script's bar-by-bar execution model helps prevent this by default, since each statement only has access to the current and previous bars. But it's still possible to introduce lookahead through creative use of request.security() with a lower timeframe, and we check for those patterns.

We built detection for these three issues because they represent the gap between "my indicator looks brilliant on a historical chart" and "my indicator actually works for live trading." Bridging that gap is the difference between a toy and a tool.

What we learned building it

Building the engine taught us some things that surprised us.

Most users start by copying, not creating. We expected people to write indicators from scratch. In reality, about 80% of custom indicators on the platform started as code copied from a forum, blog, or tutorial. Users paste it in, see if it works, then start tweaking parameters. This is why Pine Script compatibility was so important — it dramatically lowered the friction from "I found some code online" to "it's running on my chart." The learning journey isn't blank-page-to-finished-indicator. It's copy, tweak, understand, eventually create.

Error messages matter more than features. The single biggest factor in user retention with custom indicators wasn't how powerful the engine was. It was how helpful the error messages were. When we launched, errors were technical — "unexpected token at line 14." Users bounced. When we rewrote them to be contextual — "Line 14: ta.sma expects a number for the period parameter, but got a string. Did you mean to use input.int(14) instead?" — completion rates doubled. We now treat error message quality as a first-class feature, not an afterthought.

Performance is a feature. Early versions of the engine recalculated everything on every tick. On a 5-minute chart with a year of data, that's over 100,000 bars being processed multiple times per second. The UI would freeze, the chart would stutter, and users would assume the indicator was broken rather than slow. We had to build the incremental update system described above, and it made the difference between "cool tech demo" and "tool I actually use for trading." Nobody cares how clever your architecture is if the chart lags.

Saving and sharing drives adoption. When we added the ability to save indicators and load them across different charts, usage tripled. People build an indicator once and then use it everywhere — on every asset, every timeframe, every layout. The indicator becomes part of their workflow rather than a one-off experiment. We're considering adding community sharing next, though we want to get the security review right before we let users run each other's code. The risk of a cleverly crafted indicator that looks helpful but actually misleads is real, and we'd rather launch it right than launch it fast.

The 105 built-in indicators got better too. An unexpected benefit: building the custom engine forced us to re-examine our built-in indicator implementations. When users can write their own RSI and compare it to ours, any discrepancy gets noticed immediately. We found and fixed three edge-case bugs in our built-in indicators that had been there since launch — all discovered because a user's custom version produced slightly different values and asked us why. Competition from your own users turns out to be excellent quality assurance.

Where this is going

Custom indicators are one piece of a larger vision. If you can express your trading logic as code, you should be able to do more than just visualise it on a chart.

We're working on connecting custom indicators to our backtesting engine. Write your indicator, define entry and exit rules, and test it against historical data — all without leaving the platform. The indicator engine already computes values across full history, so the data pipeline is there. We just need to build the strategy wrapper and the results dashboard. The goal is to go from "I have an idea" to "here's how it would have performed over the last 2 years" in under a minute.

Beyond backtesting, we want custom indicators to feed into our alert system. "Notify me when my triple-confirmation oversold signal fires on any stock in my watchlist." That's the point where custom indicators become truly operational — not just a visual tool on a chart you're staring at, but an automated scanner that watches the market for you while you do other things. Combined with our existing Telegram notification pipeline, your custom indicator could wake you up at 3am when that crypto setup you've been waiting for finally appears.

The endgame is a platform where your entire trading workflow — from idea to indicator to backtest to live alerts to execution — lives in one place. We're not there yet. But the custom indicator engine is the foundation that everything else builds on, because it's where your trading logic gets expressed in a form that a computer can work with.

We built Nydar because we believe traders deserve professional-grade tools without the professional-grade price tag. The custom indicator engine is the purest expression of that philosophy. Instead of deciding what indicators you need, we gave you the building blocks to create exactly what you need.

If you've been sitting on an indicator idea, give it a try. And if you get stuck, the Pine Script guide and glossary are there to help you get unstuck.

Your edge is your own. We just built the engine to run it.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

How We Cut Our API Calls by 85% Without Losing a Single Data Point

NydarTrading — Fri, 27 Feb 2026 00:54:44 +0000

Last week we noticed something alarming in our API usage logs. Nydar was making nearly 15,000 API calls per day to our primary market data provider — against a daily budget of 2,000. We were overshooting by 7.5x. Not by a little. Not by double. By seven and a half times our allocation.

The data was still flowing because the provider throttles gradually rather than hard-blocking, but we were living on borrowed time. One policy change on their end and our entire stock data pipeline goes dark. No quotes, no heatmaps, no analyst ratings, no institutional holdings. Everything that makes Nydar useful for stock traders — gone.

We had to fix it. And we had to fix it without users noticing anything had changed.

This is the story of how we diagnosed the problem, fixed it in four phases over 48 hours, and ended up with a genuinely better product than we started with.

Why not just buy more quota?

Before we get into the technical work, let's address the obvious question. Our data provider offers paid tiers with higher limits. Why not just upgrade?

Two reasons. First, the economics don't add up at our stage. We're a growing platform, not a hedge fund. Moving from the free tier to a plan that would cover 15,000 calls/day would cost more per month than our entire server infrastructure. That's not a good trade when most of those calls are wasted.

Second — and more importantly — buying more quota doesn't fix the underlying problem. If our architecture is making 7.5x more calls than necessary, throwing money at the rate limit just means we're paying 7.5x more than we should. We'd rather fix the root cause and keep that budget for when we actually need it — when the user base grows and the real demand exceeds the free tier.

Optimisation first. Scaling second.

How Nydar's data pipeline works

To understand where the waste was happening, you need to understand how data flows through the system.

Nydar supports three asset classes: stocks, crypto, and forex. Each has different data providers, different update frequencies, and different trading hours. The architecture looks roughly like this:

External APIs — providers like Finnhub (stocks, forex), Binance (crypto), TwelveData (supplementary quotes), and others
Backend data sources — Python classes that wrap each provider, handle authentication, and implement caching
In-memory cache layer — a simple dictionary with TTL-based expiration. No Redis, no external cache. Just a dict with timestamps
REST endpoints — FastAPI routes that widgets call to get data
WebSocket layer — a persistent connection that pushes real-time updates to the frontend at configurable intervals
Frontend widgets — 40+ React components that render the data

Every API call happens at layer 2. The cache at layer 3 is supposed to prevent redundant calls. The WebSocket at layer 5 determines polling frequency. The waste was happening because layers 2, 3, and 5 weren't coordinating properly.

Discovering the problem

It started at 11 PM on a Tuesday. A routine check of our data provider's dashboard showed we'd used 14,898 of our 2,000 daily allocation. That's not a typo. Fourteen thousand eight hundred and ninety-eight.

The natural reaction is to assume something is broken — a runaway loop, a misconfigured retry, maybe a bot hammering the API. But our logs didn't show anything obviously wrong. The system was behaving exactly as designed. The problem wasn't a bug. It was architecture.

Nydar aggregates real-time data from multiple providers — live quotes, order books, analyst ratings, institutional filings, options chains, earnings calendars, and more. Each of these features makes API calls. Individually, each one is reasonable. A quote here, a filing there. Collectively, they were drowning us.

The audit that changed everything

The first step was figuring out where all these calls were actually going. We had basic daily counters, but that's like knowing your electricity bill is high without knowing which appliance is the problem. We needed per-endpoint, per-symbol granularity.

We rebuilt our API usage tracker with a detailed breakdown structure: which API, which date, which endpoint, which symbol, how many calls. We let it run for a full 24-hour cycle and looked at the results the next morning.

They were eye-opening:

Source	Calls/hour	The problem
Forex rate lookups	~991	Each of 15 currency pairs hit the bulk rates endpoint individually — but that endpoint returns every rate in one response
Heatmap quotes	~3,843	25 individual stock quotes per refresh, fired sequentially, with only a 60-second cache
WebSocket polling	~480	Polling every 30 seconds for stock data even when the US market was closed
Public snapshot	~240	Fetching 4 stock quotes every 120 seconds with no market-hours check
TwelveData duplication	uncounted	A `get_quote()` method that bypassed the cache entirely and duplicated what `get_ticker()` already does

Four categories of waste: redundant calls, unnecessary calls, excessive calls, and duplicate calls.

The forex revelation

The forex issue deserves its own section because it was the single most absurd finding.

Our data provider has a /forex/rates endpoint. You pass it a base currency — say EUR — and it returns exchange rates for every quote currency in a single response. EUR/USD, EUR/GBP, EUR/JPY, EUR/AUD, all of them. One call, all the data.

We were calling it once per pair.

So fetching EUR/USD, EUR/GBP, and EUR/JPY meant three separate API calls to the same endpoint, each returning the exact same blob of data, and we'd extract one rate from each response and throw away the rest. Multiply that by 15 active currency pairs refreshing every 60 seconds, and you get nearly a thousand wasted calls per hour.

The fix was embarrassingly simple: call /forex/rates?base=EUR once, cache the full response for 60 seconds, and have all EUR-based pair lookups read from that cache. One call instead of fifteen. A 93% reduction in forex API usage from a single architectural insight.

This is why auditing matters. We would never have guessed this was the biggest offender. The forex widget looked simple and lightweight from the outside. But underneath, it was our most expensive feature per data point.

Phase 1: Stop the bleeding

With the audit data in hand, we tackled the four biggest offenders in order of impact.

Forex bulk caching was the first and easiest win. We already described it above — one call per base currency instead of one per pair. Forex API usage dropped from ~900 calls/hour to ~60 calls/hour. We could have stopped here and still cut our total daily calls by nearly a third.

Market hours gating was the second-biggest win and required more thought. We built a is_stock_market_open() utility that determines whether the US stock market is in regular trading hours — 9:30 AM to 4:00 PM Eastern Time, Monday through Friday, accounting for DST. When the market is closed, stock-related endpoints return stale cached data with a "market_closed": true flag. No API call at all.

This eliminated roughly 4,000 calls per day that were happening between market close and market open. Think about that: for 17.5 hours out of every 24, we were making API calls for data that literally cannot change (regular-hours stock prices don't move when the exchange is closed). Pure waste.

But this one almost killed us.

The midnight UTC war story

Our first implementation used is_stock_market_active() instead of is_stock_market_open(). The "active" version includes pre-market (4 AM–9:30 AM ET) and after-hours (4 PM–8 PM ET) sessions. It seemed like the responsible choice — broader coverage means fresher data, right?

The problem is timezone arithmetic, and it's the kind of bug that only manifests at specific times of day.

Our daily API counter resets at midnight UTC. Midnight UTC is 7 PM Eastern Time — right in the middle of the after-hours session. So here's what happened every single night:

11:59 PM UTC: Counter at 1,987 of 2,000. System is throttled. Everything is fine.
12:00 AM UTC (7 PM ET): Counter resets to zero. is_stock_market_active() returns true because after-hours runs until 8 PM ET.
12:00:01 AM UTC: The system thinks the market is active and it has a fresh budget. Full-speed polling begins.

We had a widget called AssetBands that shows support and resistance levels for a watchlist of stocks. It polls 50 symbols every 30 seconds via the bulk tickers endpoint. At full speed, with a fresh daily counter, it burned through 2,000 API calls in under 30 minutes. By 12:30 AM UTC — 7:30 PM Eastern, still in after-hours — our entire daily quota was gone.

The first morning this happened, we thought our Phase 1 fixes hadn't worked. The usage dashboard showed 2,000+ calls, same as before. It took an hour of staring at the per-hour breakdown to spot it: a massive spike at exactly midnight UTC, then nothing. The observability tooling we'd built in Phase 3 literally paid for itself on day one.

The fix was a one-word change in one file: is_stock_market_active() to is_stock_market_open(). Regular hours only. Pre-market and after-hours data is genuinely useful, but not at the cost of your entire daily budget. If we ever need extended-hours data, we'll budget for it as a separate, explicit cost — not as a side effect of a boolean function that happens to return true at the wrong time.

Heatmap optimisation addressed both speed and volume. The heatmap widget fetches quotes for 25 stocks to build a sector performance grid. Two changes: we switched from sequential fetches to asyncio.gather() for parallel execution, and bumped the cache TTL from 60 seconds to 180 seconds.

The parallel fetch doesn't reduce API call count — it's still 25 calls — but it cuts the response time from around 5 seconds to under 1 second. Users were seeing a blank heatmap for five seconds on every refresh. Now it snaps in. The cache bump from 60s to 180s reduces call volume by two-thirds. For a heatmap showing sector performance, three-minute-old data is perfectly fine.

TwelveData deduplication was the last Phase 1 fix. Our TwelveData integration had two methods that hit the same underlying API: get_ticker() (cached) and get_quote() (not cached). The quote method existed for historical reasons and was bypassing the cache on every call. We routed it through the cached get_ticker() path. Usage dropped by roughly 50%.

WebSocket back-off. This one isn't in the original audit table because it overlaps with market-hours gating, but it's worth calling out. Our WebSocket layer pushes real-time updates to connected clients. During market hours, it polls every 30 seconds. But we had no concept of "the market is closed, slow down." After adding market-hours awareness, the WebSocket backs off to a 5-minute interval outside regular hours. Still polling — in case of corporate events or overnight moves — but at 1/10th the frequency.

We also added an extended OHLCV cache for candlestick data. During market hours, OHLCV data has a standard cache TTL. When the market is closed, we bump it to 4 hours. Candlestick data from 3 PM isn't going to change at 11 PM. A 4-hour cache during off-hours means the data is there when someone opens the app late at night, but we're not refreshing it every few minutes for no reason.

Combined, these changes reduced our total API calls by an estimated 60–70%. But we weren't done. Reducing calls is only half the problem.

Phase 2: What happens when you hit the wall anyway

Even with a 70% reduction, there will be days when traffic spikes, when a user has 40 widgets open, when something unexpected happens. You will hit your quota ceiling eventually. The question is: what does the user see when you do?

Before our work, the answer was "broken widgets." API calls would fail with HTTP errors, the frontend would show generic error states or infinite spinners, and the user would assume the platform was down. Terrible.

We built a three-layer quota exhaustion system that transforms this failure mode into something that actually makes sense.

Layer 1: The backend quota guard. Before every single API call to a rate-limited provider, we check a daily counter. If the quota is exhausted, we raise a QuotaExhaustedError immediately — no network call, no wasted time, no ambiguity. This check happens in a single method called _get_params() that all 17+ endpoints flow through. One chokepoint, complete coverage.

The key insight here is that quota exhaustion isn't an error. It's a state. The system should handle it as gracefully as it handles "market closed" or "no data available." Raising a typed exception (rather than returning None or an empty response) means every layer of the stack can handle it explicitly.

Layer 2: The global exception handler. A FastAPI exception handler catches QuotaExhaustedError from any route — not just the ones we've thought of — and returns a structured 429 response: {"code": "QUOTA_EXHAUSTED", "message": "..."}. This means we never need to remember to wrap a new endpoint in quota-handling logic. The safety net is global.

We also had to deal with a provider-specific quirk: our data provider returns HTTP 403 (Forbidden) when you're rate-limited, not the standard 429 (Too Many Requests). Python's response.raise_for_status() turns a 403 into a generic HTTPStatusError, which our existing error handling was logging as a server error. We built a _check_response() static method that intercepts 403 and 429 responses before anything else touches them and converts them to QuotaExhaustedError. Without this, quota events would masquerade as server errors throughout the codebase.

Layer 3: Frontend intelligence. An Axios interceptor catches 429 responses and rewrites the error message to "Daily data limit reached — resets at midnight UTC." Clean, human-readable, no jargon.

But we went further. Each widget now has a smart error state component called WidgetErrorState that checks context before deciding what to show. If the stock market is closed and there's a quota error, the user sees "Market Closed" with the last known values — not "quota exhausted." Because from the user's perspective, there's nothing wrong. The market is closed. That's why the numbers aren't moving. Showing them a quota error would be technically accurate but experientially misleading.

This distinction — between what's technically true and what's useful for the user — turned out to be one of the most important decisions in the entire project. Ten widgets now use this smart error dispatcher: Chart, VolumeProfile, MarketBreadth, IPO, ShortSqueeze, OrderFlow, OrderBook, AggregatedBook, LiquidationMap, and VolumeDelta.

The WebSocket channel. Most of Nydar's real-time data flows over a WebSocket connection, not REST. So the quota signal needs to travel that path too. When the backend detects quota exhaustion, it pushes a quota_exhausted message type over the WebSocket. The frontend listens for this event and fires an internal ws:quota-exhausted event that any component can subscribe to.

This is important because WebSocket-driven widgets wouldn't see the REST 429 responses. Without the WebSocket channel, a widget that gets its data purely from the push connection would keep showing stale data with no indication of why it stopped updating. The user would see prices frozen at their last value with no error, no market-closed badge, nothing. Just silence. That's worse than an error message — it's a lie.

What the user actually sees before and after

Let's make this concrete. Before the optimisation work, here's what happened when a user opened Nydar at 10 PM on a Tuesday:

Chart widget: Showed a loading spinner for 5 seconds, then "Error loading data"
Order book: Infinite spinner
Heatmap: Loaded after 5 seconds but with random gaps where individual stock quotes failed
Market breadth: "Something went wrong"
Volume profile: Empty canvas

After the work:

Chart widget: Shows the day's chart with a subtle "Market Closed" badge and the closing price
Order book: Shows the last known state with a "Market Closed" indicator
Heatmap: Loads in under a second showing end-of-day sector performance
Market breadth: Shows the day's final breadth reading with a closing timestamp
Volume profile: Shows the day's volume profile, which is actually more useful at end of day than during the session (the full profile is complete)

Every widget shows data. Every widget explains its state. No spinners, no errors, no confusion. The platform feels alive and informed even when the market isn't.

Phase 3: You can't optimise what you can't see

The is_stock_market_active() bug taught us that we needed much better visibility into what the system was doing in real time. Phase 3 was about building that observability layer.

Per-endpoint, per-symbol tracking. Not just "you made 2,000 calls today" but "the heatmap endpoint made 847 calls, 340 of which were for AAPL, across the quote and ticker sub-endpoints." This level of detail is what lets you spot anomalies instantly. If AAPL suddenly accounts for 80% of your API calls, you know something is wrong with the AAPL-specific code path.

Rotating log files. We set up a dedicated logs/api_usage.log with a rotating handler: 10MB per file, 5 files max. That gives us roughly a week of history without unbounded disk growth. The logs capture every API call with timestamp, endpoint, symbol, and cache status (hit or miss). When something goes wrong at 3 AM, we have the data to reconstruct what happened.

Admin dashboard endpoint. We enriched our existing /api/admin/api-usage endpoint to return top consumers, per-endpoint breakdowns, cache hit rates, and exhaustion status. This isn't a fancy dashboard — it's a JSON endpoint that we curl when we need to check things. Simple, but it's saved us multiple times already.

Throttled persistence. The usage tracker writes its stats to a JSON file, but doing that on every API call would create its own performance problem. We added a 30-second throttle: stats accumulate in memory and flush to disk periodically, with an explicit flush on application shutdown. This is one of those boring-but-essential details that separates production systems from prototypes.

Phase 4: The paranoia phase

The final phase was about edge cases and defensive coding. The kind of work that doesn't show up in metrics but prevents 3 AM pages.

Silent quota propagation. Here's a problem we didn't anticipate: when a QuotaExhaustedError gets raised inside a method, it can get caught by a generic except Exception block higher up the call stack. Generic exception handlers typically log the error at ERROR level. Quota exhaustion isn't an error — it's expected behaviour. But without explicit handling, every quota event generates a log line that looks like something is broken.

With 15 forex pairs refreshing every 30 seconds, that's potentially 1,800 false-alarm ERROR log entries per hour. Our log aggregator would light up like a Christmas tree for something that's completely normal.

The fix is tedious but essential: add except QuotaExhaustedError: raise before every except Exception block in every method that might transitively call an API. The quota error punches through all the generic handlers and gets caught only by the global exception handler where it belongs. We did this across all 17+ endpoint methods in both our stock and forex data sources.

Premium interest capture. This is the business side of quota management, and it's an example of turning a constraint into a feature.

When users encounter the quota exhaustion state during market hours (which is now rare, but happens on high-traffic days), they don't just see an error. They see a subtle call-to-action: "Want uninterrupted data? Register your interest for premium access."

Clicking it opens a modal that captures their email and what tier of data access they'd value. We deliberately didn't build a payment flow. We're not selling something that doesn't exist yet. We're gathering signal. The registrations go to a simple JSON store on the backend — nothing fancy, no email marketing platform, just a file that grows by one line when someone expresses interest. Aggregate stats are available at an admin endpoint so we can track conversion rates from quota events to signups.

The insight here is that the users who encounter quota limitations during market hours are, by definition, our most active users. They have multiple widgets open, they're checking data frequently, they care enough to be trading during peak hours. These are exactly the people we want to talk to about a premium tier. The quota limit acts as a natural filter for our highest-value users.

We didn't plan this. It emerged from asking "what should the user see when we hit the wall?" and realising that the answer isn't just "an error message" — it's an opportunity to understand what our most engaged users would pay for.

The numbers

After all four phases rolled out over 48 hours, here's where we landed:

Metric	Before	After	Change
Daily API calls	~14,898	<2,000	-85%
Forex calls/hour	~991	~60	-94%
Off-hours waste	~4,000/day	0	-100%
Heatmap response time	~5 seconds	<1 second	-80%
Error logs from quota events	~1,800/hour	0	-100%
User-facing errors on quota	Broken widgets	"Market Closed" or graceful CTA	qualitative

We're now comfortably within our API budget with headroom for growth. During market hours, data freshness is identical to before — we didn't increase any cache TTLs that affect real-time trading data. The 180-second heatmap cache is the only user-visible change, and for a sector heatmap, that granularity is more than sufficient.

The frontend side: market-aware error states

One piece of this work deserves a deeper look because it applies to any product that depends on external data: the frontend error state hierarchy.

Before this project, our widgets had a binary state: either data loaded successfully, or the widget showed a generic error. After the work, every widget can be in one of four states:

Loading — data is being fetched
Success — data rendered normally
Market Closed — it's outside trading hours, showing last known values with a clear indicator
Quota Exhausted — daily limit reached, with a premium interest CTA

The market-closed state is checked first. This is critical. If the market is closed and the quota is exhausted, the user sees "Market Closed" — because that's the real reason the data isn't updating. The quota state only shows during market hours when the user would actually expect fresh data.

We also built the market hours check into the frontend itself, and this was trickier than it sounds.

The DST problem

Daylight Saving Time is the bane of any system that cares about US market hours. The NYSE opens at 9:30 AM Eastern, but "Eastern" means different UTC offsets depending on the time of year: UTC-5 during winter (EST), UTC-4 during summer (EDT). If you hardcode the offset, your market-hours check breaks twice a year — in March and November — and it breaks silently. Prices keep updating normally; it's just your cache gating that's wrong, burning extra API calls for two weeks until someone notices.

We solved this using the browser's built-in Intl.DateTimeFormat API with the America/New_York timezone. The browser handles DST transitions correctly because it uses the IANA timezone database, which is updated regularly. No external API calls, no timezone libraries, no hardcoded offsets.

The implementation is lightweight: format the current UTC time into America/New_York components, extract the hour and minute, and check if it falls between 9:30 and 16:00 on a weekday. This runs entirely on the client. Zero network overhead. The frontend knows what time it is in New York without asking anyone.

We use this in multiple places: the WidgetErrorState component checks it before deciding whether to show "Market Closed" vs "Quota Exhausted", and the AssetBands widget uses it to switch between 30-second active polling and 5-minute idle polling.

What we learned

Audit before you optimise. We would have guessed wrong about the biggest offenders. The forex bulk-cache fix was the single highest-impact change, but it wasn't on anyone's radar until we saw the per-endpoint numbers. Intuition is good for generating hypotheses. Data is what tells you where to actually spend your time.

"Active" and "open" aren't the same thing. Pre-market and after-hours sessions exist, and traders do care about them. But they're not worth burning your entire daily API budget on. For cache gating and polling decisions, regular trading hours is the right boundary. If you need extended-hours data, budget for it explicitly rather than treating it as a side effect of your regular polling.

Error states are features, not afterthoughts. The quota exhaustion UX is arguably better than what we had before the optimisation work. Users now see contextual, market-aware status messages instead of generic loading spinners when data isn't updating. The system is more honest about what's happening and why. A well-designed error state builds trust. A broken widget destroys it.

Typed exceptions beat boolean flags. Using QuotaExhaustedError as a proper exception type — rather than returning None or setting is_exhausted = True on some state object — meant that every layer of the stack could handle quota events explicitly. The global exception handler catches everything we forgot. The silent propagation pattern keeps logs clean. Types are documentation that the compiler enforces.

Observability pays for itself on day one. The per-endpoint usage dashboard caught the is_stock_market_active() regression within hours of deployment. Without it, we'd have woken up to another 15,000-call day with no idea why the fix we'd just shipped didn't work. Every minute spent building observability tools saves hours of debugging later.

Cache TTLs are product decisions, not just engineering ones. How stale can heatmap data be before it misleads a trader? Is 60-second-old data meaningfully different from 180-second-old data for a sector overview? These aren't questions engineers should answer alone. They require understanding what the user is actually doing with the data and what decisions they're making based on it.

The pattern

If you're building a trading platform — or any application that aggregates data from rate-limited APIs — the pattern is the same:

Measure first. Per-endpoint, per-symbol, per-hour. You need the resolution to find the real problems.
Eliminate redundancy. Bulk endpoints exist for a reason. If you're calling an API that returns 100 results to extract 1, cache the other 99.
Respect time boundaries. If data can't change, don't ask for it. Market hours, business hours, weekends — build these boundaries into your polling logic.
Design your error states. When you hit the limit, what does the user see? If the answer is "a broken widget," you have work to do.
Build the dashboard before you need it. You'll need it sooner than you think.

What's next

We're now running comfortably within our API budget with room to grow. But this work opened up questions we hadn't considered before.

Multi-provider failover. If one data provider hits its limit, could we transparently fall back to another? We already have TwelveData and AlphaVantage as secondary sources for some data types. The quota guard infrastructure makes this possible — instead of raising QuotaExhaustedError, we could try the next provider in a priority chain. We haven't built this yet, but the architecture is ready for it.

Per-user quota awareness. Right now, all users share the same API budget. As we grow, we'll need to think about fair scheduling — making sure one power user with 40 widgets doesn't crowd out everyone else. The per-symbol tracking from Phase 3 gives us the data to understand usage patterns. The question is whether to implement server-side rate limiting per user, or to solve it at the data layer with smarter caching and sharing.

Holiday calendars. Our market-hours check handles weekdays and DST, but not market holidays. On Christmas Day, Martin Luther King Day, and a dozen other holidays, the US stock market is closed but our code thinks it's a normal Monday. We need to add a holiday calendar — either hardcoded for the year or fetched from an API (which, ironically, would be another API call to manage).

These are good problems to have. They're the problems of a platform that's working, growing, and thinking about the next level of sophistication. The 48 hours we spent on API optimisation didn't just fix a quota crisis — they gave us the observability, the error-state architecture, and the caching patterns to build on for everything that comes next.

Not bad for a week's work.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.

Intelligent Asset Bands: How We Rebuilt Symbol Navigation From Scratch

NydarTrading — Wed, 25 Feb 2026 18:15:00 +0000

The Problem With Symbol Selectors

Every trading platform has a symbol selector. And almost every one of them is terrible.

You get a search box. Maybe a dropdown with some favourites. If you're lucky, there's a watchlist you can manually curate. But none of them actually help you find what's moving in the market right now. They're passive — they wait for you to already know what you want to look at.

That's backwards. A good trading platform shouldn't just display data for the symbol you picked. It should surface the symbols that matter right now and make switching between them instant.

Think about how a professional trader actually works. They're not staring at one chart all day. They're scanning. Flicking between symbols. Looking for momentum, volume spikes, sector rotations. The symbol selector isn't a minor UI element — it's the primary interface for discovery. And yet on most platforms it's an afterthought. A text input with autocomplete, maybe a star icon to save favourites. The same UX pattern we've had since the early 2000s.

Nydar used to have a search bar in the header. Type a symbol, hit enter, your dashboard updates. Functional. Boring. And fundamentally the same approach every other platform takes. You had to already know what you wanted to look at before you could look at it. If you wanted to find what was moving in crypto right now, you'd have to check an external screener, note the symbols, then come back to Nydar and type them in one by one.

We wanted something better. Something that turns symbol navigation from a passive lookup into an active discovery tool. Something that replaces the question "what do I want to look at?" with the answer "here's what's worth looking at right now."

That's what Asset Bands are.

What We Built

Asset Bands are horizontal strips that sit between the header and your dashboard. Each enabled asset class — crypto, stocks, forex — gets its own colour-coded band with a row of clickable symbol pills. Click any pill and your entire dashboard instantly reconfigures to show that symbol's data. Every chart, every indicator, every widget updates in real-time.

The visual design is intentional. Each asset class has its own accent colour: warm orange for crypto, electric blue for stocks, emerald green for forex. The left edge of each band has a solid accent border with a gradient wash that fades across the first 240 pixels. It's subtle enough that it doesn't compete with your charts, but distinctive enough that you can instantly tell which band you're looking at.

Each pill shows the symbol name and a small percentage badge showing the 24-hour change. Green for up, red for down. The active symbol is highlighted in the accent colour with a subtle glow. Inactive pills have a muted, dark appearance with soft borders — they look clickable without being visually noisy.

But the real power isn't in the pills themselves. It's in the filter system behind them.

Per-Asset Intelligent Filters

Each asset class gets its own set of filters, because what matters in crypto is completely different from what matters in equities or forex. We didn't want a one-size-fits-all dropdown where half the options are irrelevant. A crypto trader scanning for volume doesn't care about sector classifications. An equity trader looking at financials doesn't need a "Top 50 by market cap" filter — they know the names already.

Crypto filters:

Top 25 / Top 50 — ranked by actual market capitalisation from aggregated cross-exchange data, not an arbitrary hardcoded list
By Volume — the 25 highest-volume coins sorted by real 24-hour trading volume
Gainers — the top 25 biggest movers to the upside right now, sorted by percentage change
Losers — the top 25 biggest drops, for contrarian plays or risk monitoring
All — every tradeable pair on the exchange

Stock filters:

Top 25 — the blue-chip core
Gainers / Losers — sorted by real-time daily price change percentage
Tech Sector — AAPL, NVDA, MSFT, META, GOOGL, AMD, ADBE, CRM, and the rest of the tech heavyweights
Finance Sector — JPM, GS, BAC, V, MA, MS, WFC, C — Wall Street's core
All — the full universe of tracked equities

Forex filters:

Major Pairs — EUR/USD, GBP/USD, USD/JPY, USD/CHF, AUD/USD, NZD/USD, USD/CAD — the seven pairs that account for the vast majority of global forex volume
Cross Pairs — everything else, from EUR/GBP to AUD/JPY to CAD/JPY
All — the complete list of tracked pairs

The key word there is real. Every filter except the sector classifications is driven by live market data, not a static list someone typed into a config file six months ago. When you click "Gainers," you're seeing the actual top performers sorted by real price change data from the last 30 seconds. When you click "By Volume," you're seeing actual trading volume aggregated across exchanges. This isn't a screener that runs once a day and caches the results. It's live.

Why These Specific Filters?

We spent time thinking about what a trader actually needs when scanning markets. Not what looks impressive in a feature list — what actually changes behaviour.

Volume: The Most Underrated Signal

Volume is arguably the single most important piece of information a trader can have beyond price. High volume on an up-move suggests conviction — real money is flowing in, not just a few retail traders chasing. High volume on a down-move suggests capitulation or forced liquidation. Low volume on any move suggests it probably won't last.

The "By Volume" filter surfaces this immediately. During a major market event — an unexpected Fed announcement, a crypto exchange collapse, a surprise earnings beat — the volume filter instantly shows you where the action is. You don't need to check 50 charts. You don't need to scan a screener on another site. The symbols with the highest conviction are right there in front of you, ranked.

Gainers and Losers: Following Momentum (or Fading It)

Momentum traders want to see what's running. Contrarian traders want to see what's been beaten down. Both need the same data, sorted differently. The Gainers filter shows the biggest percentage moves to the upside over the last 24 hours. The Losers filter shows the biggest drops.

Crucially, these filters update with every price refresh cycle (every 30 seconds). A coin that was in the middle of the pack at 9am could be the top gainer by 10am. You'll see that shift in real-time because the filter re-sorts on every data update.

Sectors: Scanning an Industry in One Click

When a major economic event hits — an interest rate decision, a regulatory announcement, a trade policy change — it rarely affects just one stock. It moves entire sectors. The tech sector filter lets you see all tech stocks at once: are they all red, or is NVDA green while the rest are down? That's a signal. The finance sector filter shows you whether banks are moving together or diverging.

This is how institutional traders think. They don't look at individual stocks in isolation. They look at sectors, at correlations, at relative strength. The sector filters give retail traders the same lens.

Majors vs Crosses: Forex-Specific Logic

Forex is a different beast entirely. The seven major pairs all involve the US dollar and account for the overwhelming majority of global forex volume. Cross pairs don't involve the dollar and tend to have wider spreads and lower liquidity. Traders often specialise in one or the other, and the filter reflects that natural division.

The Data Pipeline That Makes It Work

Here's where the engineering gets interesting. Making filters that feel instant but are backed by real market data requires careful orchestration of multiple data sources, each with different strengths, different rate limits, and different refresh characteristics.

CoinGecko for Market Rankings

For crypto, we needed market capitalisation rankings, 24-hour volume figures, and price change percentages — and we needed them for the top 100 coins in a single API call. CoinGecko's /coins/markets endpoint is purpose-built for exactly this.

One request returns everything: current price, market cap, market cap rank, total volume, and 24-hour price change percentage. For 100 coins. In a single response. That's remarkably efficient — the kind of endpoint that was clearly designed by people who understood how trading platforms actually consume market data.

We cache this response for 10 minutes on the backend behind a dedicated cache key (ranked_crypto) in our API cache layer. Market cap rankings don't shuffle every second. If Bitcoin and Ethereum swap places in market cap, you'll see it within 10 minutes. That's more than fast enough for a ranking filter, and it means we're making roughly 144 CoinGecko API calls per day instead of thousands. Given CoinGecko's rate limits on their free tier, this matters.

The 10-minute TTL was a deliberate choice. Too short and we'd burn through rate limits. Too long and the "Gainers" filter would feel stale. Ten minutes means that during a volatile market day, you're never more than 10 minutes behind on rankings, but during a quiet day you're not wasting API calls fetching identical data.

Binance for the Long Tail

CoinGecko gives us the top 100 with rich metadata. But Nydar tracks hundreds of crypto pairs via Binance. The top 100 covers the majors, but there are traders who want to look at smaller-cap tokens that only show up on exchange-specific listings.

So after fetching ranked data from CoinGecko, we merge in the full Binance symbol list. The top 100 coins have market cap rankings, volume data, and change percentages baked in from the CoinGecko response. Everything beyond that gets basic symbol information from Binance — enough to show the pill and load the chart, but without the ranking metadata.

This two-tier approach means the "By Volume" and "Top 25" filters are driven by CoinGecko's aggregated cross-exchange data (which is more accurate than any single exchange's figures, since it represents global liquidity), while the "All" filter still shows every Binance pair for traders who want to go deep into the long tail.

The merge itself is careful not to create duplicates. We build a Set of symbols from the CoinGecko response, then filter the Binance list to exclude anything already covered. The result is a single symbol cache where the first ~100 entries are rich (with market cap, volume, rank) and the rest are basic (symbol and source only).

Live Price Updates Every 30 Seconds

Regardless of which data source populated the symbol list, every visible pill gets live price updates every 30 seconds via our bulk ticker endpoint. This serves two critical purposes.

First, it keeps the change percentage badges on each pill current. The tiny "+3.2%" next to a symbol isn't decorative — it's actionable information. If that number is stale, the entire filter system is stale. A 30-second refresh means the visual indicators are never more than half a minute behind reality.

Second, it means the Gainers and Losers filters are working with fresh data every time you switch filters. The filter function runs against the current symbol cache, and the symbol cache is updated every 30 seconds. So if you switch to "Gainers" at 10:00:15, you're seeing data from the 10:00:00 refresh at worst.

The update path is important here. When price data arrives from the ticker endpoint, we merge it into the existing symbol cache without replacing the CoinGecko metadata. So a coin keeps its market cap ranking (from CoinGecko, refreshed every 10 minutes) while its price and change percentage update every 30 seconds (from the live ticker feed). Two data sources, different refresh rates, seamlessly merged into a single reactive data structure.

This is handled at the Zustand store level. The updateSymbolPrices action takes a map of {symbol → {price, change24h, volume24h}} and patches each matching entry in the cache without touching fields like marketCapRank or marketCap. Zustand's immutable update pattern means React only re-renders the pills whose data actually changed — not the entire band.

Stock Data: Working Within Constraints

For stocks, the data situation is different. Finnhub's free tier gives us real-time quotes with price and daily change percentage, but no volume data and no sector classifications. That constrains what we can offer.

The Gainers and Losers filters work the same way as crypto — sort by change24h, take the top or bottom 25. The data comes from the same 30-second ticker refresh cycle.

For sector classification, we don't have a free API that returns sector data with price quotes. So we maintain a hardcoded sector map — tech and finance classifications for the ~36 stocks in our universe that fit those categories.

Is this ideal? No. We'd rather have a dynamic sector API. But the pragmatic reality is that Apple isn't going to stop being a tech company between API calls. The sector map changes perhaps once a year when a company restructures or when we add new stocks to our universe. Hardcoding it is the honest engineering choice rather than over-engineering a dynamic solution for data that's effectively static.

We deliberately chose tech and finance as the two sector filters because they represent the two largest and most traded sectors in our equity universe. Healthcare, energy, and consumer discretionary are candidates for future expansion as we grow the stock universe.

Forex: Convention Over Configuration

Forex pair classification is the simplest of the three. The seven major pairs (EUR/USD, GBP/USD, USD/JPY, USD/CHF, AUD/USD, NZD/USD, USD/CAD) are defined by global convention, not by any metric that changes. They're the pairs where both currencies are from major developed economies and one side is always USD. Everything else is a cross. We store the majors as a Set and classify by membership — if it's in the set, it's a major. If not, it's a cross.

This is the kind of thing that doesn't need to be clever. The seven major forex pairs haven't changed in decades. They won't change tomorrow. A Set lookup is the right answer.

The State Architecture

The entire filter system runs through a single Zustand store (assetBandStore) that manages state for all three asset classes simultaneously. The architecture decisions here were important for performance and persistence.

What Gets Persisted (and What Doesn't)

The store uses Zustand's persist middleware with a partialize function that carefully controls what gets saved to localStorage. User preferences — which bands are enabled, which filter is active, custom lists — those persist across sessions. If you set stocks to "Tech Sector" and close your browser, it's still on "Tech Sector" when you come back.

But the symbol cache and price data do not persist. They refresh on every page load. This is deliberate. Persisting a 100-item symbol cache with prices and volumes would mean showing stale data for the first few seconds of every session until the fresh data arrives. That's worse than showing nothing for a moment while data loads, because stale data looks real. A user might make a decision based on last Tuesday's volume data because it loaded instantly from localStorage. Instead, we show the known symbols immediately (from a hardcoded fallback list) and replace them with ranked data within a second or two.

Selective Re-renders

Each BandRow component subscribes to only its own slice of the store. The crypto band reads symbolCache['crypto'] and bands['crypto']. It doesn't subscribe to the stock or forex data. This means a price update for AAPL doesn't cause the crypto band to re-render. In a system where three asset classes are each updating every 30 seconds, this matters for keeping the UI responsive.

The useMemo on the filter application means the sorted/filtered list only recomputes when the underlying data actually changes — not on every render cycle. And the useCallback on the selection handler prevents unnecessary re-renders of the pill components.

The UX Details That Took Longer Than the Backend

The data pipeline was the intellectually satisfying part. But the UX polish is what actually makes Asset Bands usable, and it took significantly more iteration than the backend. We went through at least four major revisions of the interaction model before landing on something that felt right.

Wrong-Type Widget Handling: Three Attempts

Here's a problem we didn't anticipate until we started using Asset Bands ourselves: what happens when you have crypto-specific widgets (Order Flow, Volume Delta) on your dashboard and then click a stock symbol?

These widgets can only display crypto data — they depend on Binance WebSocket feeds that don't exist for equities. So when you switch to AAPL, they have nothing to show.

Attempt 1: Overlay messages. Our first solution was straightforward — show a message overlay: "This widget requires a crypto symbol. Select a crypto symbol above to view data." Technically correct. Visually horrifying. The crypto widgets became massive empty rectangles with a small text label floating in the middle. Your carefully arranged 6-widget dashboard suddenly had three giant voids in it. It looked broken, even though it was working exactly as designed.

Attempt 2: Auto-minimise in place. We collapsed mismatched widgets to a single-row height strip in their current grid position. Better — no more voids. But now you had thin collapsed bars scattered randomly across your dashboard, breaking the visual flow. A collapsed bar at row 2, column 3 created an awkward gap between the widgets above and below it.

Attempt 3: Auto-minimise to bottom. The final solution: when a widget's asset class doesn't match the selected symbol, it collapses to a single row and gets pushed to the bottom of the grid as a full-width bar. When you switch back to a matching symbol, it expands back to its original size and position.

This required solving a non-obvious problem with react-grid-layout's vertical compaction. Setting y: 999 on a widget pushes it down, but only within its current column. A 4-column-wide widget at x: 8 would sit at the bottom of column 8, potentially overlapping with full-height widgets in other columns.

The fix was making minimised widgets full-width (w: 12, x: 0). A full-width widget at y: 999 must go below everything else because it spans all columns. The grid's compaction algorithm has no choice but to place it at the very bottom.

We also needed to preserve the original dimensions for restoration. When a widget auto-minimises, we store its original height, width, x, y, and minWidth in the widget's persistent config object. When the mismatch resolves (user switches back to crypto), we read those values back and restore the widget to its exact previous position and size. This survives page reloads because the widget config persists through Zustand's localStorage layer.

There's also a flag (_autoMin) that distinguishes auto-minimised widgets from manually minimised ones. If you manually minimise a widget and then switch asset classes, we don't want the auto-expand to fight with your manual choice. The flag ensures that only widgets that were automatically collapsed get automatically restored.

Scroll Behaviour

Symbol bands can have 50+ pills. They need to scroll horizontally. This sounds simple but has several edge cases that affect usability.

We implemented three complementary scroll mechanisms:

Mouse wheel — the scroll wheel maps to horizontal scroll. This is the expected behaviour for a horizontal list, but browsers don't do it automatically for horizontal overflow. We capture the onWheel event and translate deltaY into scrollLeft changes.
Click and drag — you can grab the band and slide it laterally. This required careful momentum detection to distinguish between a click (which should select a symbol) and a drag (which should scroll the list). We track mouse movement from mousedown and only enter "drag mode" after 3 pixels of horizontal movement. If the user drags, we suppress the subsequent click event so it doesn't accidentally select a symbol.
Edge fade — a CSS gradient overlay on the right edge signals that there are more pills to discover. It's a pointer-events-transparent div absolutely positioned over the scroll container, fading from the surface colour to transparent. Simple visual affordance, but without it users don't realise the band scrolls.

The Pill Design: Buttons, Not Labels

The symbol pills went through their own iteration. The first version looked like text labels — thin, no borders, no background. They didn't look clickable. Users hesitated before clicking them because the visual affordance was wrong.

We switched to button-like pills: visible borders (border-dark-700/30), a subtle background (bg-dark-800/25), rounded corners (rounded-md), and clear hover states that brighten the border and background. The active pill gets the full accent colour treatment — filled background, dark text, a soft glow shadow. The contrast between active (bright accent) and inactive (muted dark) is immediate and unambiguous.

The active:scale-95 on click gives tactile feedback — the pill shrinks slightly when pressed, like a physical button. The active pill gets scale-[1.04] so it sits slightly proud of its neighbours. These are tiny details, but they add up to something that feels intentional and polished rather than thrown together.

Filter Dropdown

The filter dropdown is deliberately minimal. A small button next to the asset label shows the current filter's short code. Click it and a dropdown appears with the available filters for that asset class.

Each filter option shows a human-readable label ("By Volume") and a short code ("Vol"). The active filter is highlighted with the asset's accent colour background. Click outside to dismiss. There are no animations, no transitions, no multi-level menus, no search, no icons.

We considered adding more visual flair to the dropdown — icons for each filter, descriptions, maybe a preview count. We stripped it all away. The dropdown appears, you make a choice, it disappears. The faster you can get through the filter selection, the faster you're back to looking at actual market data. Every millisecond spent in a dropdown menu is a millisecond not spent trading.

The Trading Workflow, Before and After

The real value of Asset Bands isn't any individual feature. It's the shift in mental model.

Before Asset Bands:

Open Nydar
Dashboard shows whatever symbol you looked at last
If you want to check what's moving, open CoinGecko / Finviz / another screener in a new tab
Find an interesting symbol on the external screener
Switch back to Nydar
Type the symbol in the search bar
Wait for the dashboard to update
Repeat for the next symbol

With Asset Bands:

Open Nydar
Glance at the bands — see what's green, what's red, what's moving
Click a symbol — dashboard updates instantly
Click "Gainers" — see the top performers right now
Notice SOL is up 8% — click it — full analysis in front of you
Switch to stocks — click "Tech" — scan the sector
Notice NVDA is diverging from AMD — click between them to compare

That's a fundamentally different relationship between trader and platform. Instead of a tool that responds to your questions, it's a tool that prompts better questions. The information is pushed to you rather than pulled by you.

Professional traders at institutional desks have Bloomberg terminals that show exactly this kind of information — market movers, sector performance, volume leaders. It's constantly visible, constantly updating, and it shapes how they think about the market moment to moment. Asset Bands bring that same awareness to retail traders.

The Numbers

Some metrics on what went into this feature:

6 files modified across frontend and backend
3 data sources orchestrated (CoinGecko, Binance, Finnhub) with different refresh rates and cache strategies
15 distinct filters across three asset classes, each backed by real market data
30-second price refresh cycle on every visible pill
10-minute ranking cache from CoinGecko, reducing API calls from thousands to ~144/day
5 widget dimensions stored and restored during auto-minimise (height, width, x, y, minWidth)
3 scroll mechanisms (wheel, drag, edge fade)
4 major UX revisions before landing on the final interaction model

What's Next

Asset Bands are live now. If you're a Nydar user, you'll see them between the header and your dashboard. The crypto and stock bands are enabled by default; forex is available in the asset class toggles in the header.

We're planning to add custom watchlists — the ability to create your own symbol groups and save them as a filter. The architecture already supports it. There's a custom filter type in the store, a full custom list management system with create/delete/add/remove operations, and the filter function already handles the custom case. We just need to build the UI for creating and managing lists — a modal to name the list, a way to add symbols to it, and a way to select it from the filter dropdown.

We're also looking at adding more sector classifications for stocks as we expand the equity universe. Healthcare and energy are the obvious next additions. And potentially a "trending" filter for crypto that surfaces coins seeing unusual search or social activity — CoinGecko has a trending endpoint that could power this.

The longer-term vision is for Asset Bands to become a genuine market scanning tool. Not just a way to switch symbols, but a way to discover trading opportunities. Real-time anomaly detection — flagging when a coin's volume spikes 5x its average, or when an entire sector moves in the opposite direction of the market. Correlation alerts — when two usually-correlated symbols diverge. Regime change detection — surfacing when the market transitions from trending to ranging.

For now, try switching between the filters. Click "Gainers" on a red day. Look at "By Volume" during a major market event. Switch between Tech and Finance when rate decisions drop. You'll start noticing things you would have missed with a search box.

That's the whole point.

Originally published at Nydar. Nydar is a free trading platform with AI-powered signals and analysis.