InverseOne

Positioning

InverseOne is a data-driven intelligence platform that frames daily judgments on Korean stocks as a buy / hold / sell traffic light. Instead of opinions or market chatter, every page presents a measurable signal, the confidence behind it, and the historical hit rate of similar signals — all on the same screen.

Market and Problem

Retail investors are flooded with information yet starved of comparable evidence for the only decision that matters: “should I act today?” Forum threads carry opinions but no follow-through; brokerage reports give conclusions but close the loop after publication; free chart tools show indicators but never the indicators’ historical accuracy.

InverseOne starts from two underserved values: comparability of judgments and transparency of post-signal verification. On the same screen the user sees (1) what signal fires today, (2) how confident the signal is, and (3) how often the same kind of signal has historically been right.

Core Audience and Personas

• Beginners (Layer 0 users) — Want a quick read from the traffic light and one-line summary alone. Buy/hold/sell plus a confidence percentage gives them a starting point
• Intermediate users (Layer 1–2) — Want to validate the signal: which indicators fired, how similar past situations resolved, whether the signal diverges from institutional consensus
• Verification-driven users — More interested in “what is your hit rate” than in any single recommendation. The /performance page’s calibration curve and consensus comparison is their entry point

The same page absorbs all three personas through progressive disclosure — Layer 0 (always visible) → Layer 1 (one scroll / one tap) → Layer 2 (tab switch).

Value Proposition and Differentiation

• Conclusion, evidence, and verification on one page — Other tools give you the chart, or the opinion, or the hit rate. InverseOne combines the traffic-light signal, confidence percentage, one-line summary, indicator-firing detail, similar-situation history, institutional consensus, affiliate CTA, and disclaimer in a single coherent flow
• Confidence as an explicit percentage — Not just a verdict; a confidence score lets users compare two buy signals against each other on the same scale
• All judgments are publicly tracked — The /performance page exposes a daily-refreshed calibration curve (does the 70% confidence band actually hit at 70%?) and a head-to-head comparison against institutional consensus. The system’s credibility is verified by data, not by claims
• Marketing-safe vocabulary enforced at build time — Words like “AI”, “recommend”, “target price”, “stop loss”, “guarantee” are blocked by a code-level lint. The fintech advertising guardrail is enforced by the build, not by a copywriter

Core User Flow

• Discover: Start from the home dashboard sections (today’s signals, changed judgments, consensus deviations) or the 8-column /stocks table
• Validate: On the stock detail page, traffic light → confidence → one-line summary (Layer 0) → fired indicators / chart / similar situations / consensus (Layer 1) → indicator detail panels / backtest cases (Layer 2)
• Act: A sticky CTA on the stock detail page (buy / sell buttons) opens an affiliate brokerage modal. Home and list pages intentionally have no CTA — only users with explicit intent reach it
• Return: The /performance page refreshes calibration daily, providing the verification loop that drives re-engagement

Progressive disclosure — one page absorbs beginners, intermediates, and verifiers

flowchart LR
    L0["Layer 0 — always visible
━━━━━━━━━━━
· Traffic-light signal
· Confidence %
· LLM one-line summary
· Affiliate CTA
· Disclaimer"]
    L1["Layer 1 — scroll / 1-tap
━━━━━━━━━━━
· Price chart
· Indicator firing bars
· Similar-situation stats
· Institutional consensus"]
    L2["Layer 2 — 2-tap+
━━━━━━━━━━━
· Indicator detail panels
· Backtest individual cases
· Alerts (Pro-locked)"]

    L0 -->|beginner stops here| L1
    L1 -->|intermediate validates| L2

Absorbing both fast judgment and deep verification on the same screen is the central differentiator versus split-page models.

Business Model Hypothesis

Monetization will be validated in stages. The current focus is accumulating track record and user trust as primary assets.

1. Brokerage affiliate (in production) — Buy/sell CTAs link to real brokerage trading pages through an affiliate structure. CTA placement is restricted to the stock detail page — high-intent users only
2. Pro tier (hypothesis) — To be validated after 3–6 months of accumulated track record. Candidate features: per-user alerts on signal changes / similar-situation hits, per-stock calibration, saved filters
3. Market expansion — Reuse the same engine across US, Japan, and crypto markets. Validated Korean hit-rate transfers to other markets through the same data model

System Architecture (planning decisions become system structure)

Two heavy planning decisions shaped the architecture.

1. “The conclusion and the hit rate must appear on the same page, simultaneously.” → A single stock-detail screen fetches and renders (a) today’s signal, (b) the signal’s confidence, and (c) the historical hit count for the same kind of signal — all together. Splitting verification onto a separate page would let users see the conclusion and leave; progressive disclosure on one page absorbs both quick judgment and deep verification.

2. “Track record must accumulate automatically and be verifiable by anyone.” → A daily scheduler triggers signal generation after market close, and an outcome-scoring run grades the previous day’s signals at the next close and writes hit/miss to the DB. The /performance page renders that accumulated data directly. The same code that produces signals also grades them — that’s the integrity guarantee.

Signal generation → user-facing pipeline

flowchart TD
    S1[Daily scheduler
post-market-close trigger]
    S2[Daily scheduler
next-trading-day trigger]
    API[Hono API
AWS Lightsail · 9 services shared]
    DB[(MySQL
stocks · judgments
firings · similar_situations)]
    Cache[in-process
memory cache 5min]
    CDN[CloudFront
inverseone.com]
    User[Users
Astro Island Architecture]
    Crawler[Social crawlers
static OG buy/hold/sell]

    S1 -->|price/volume/fundamentals fetch
indicator firings + confidence| API
    API --> DB
    S2 -->|grade yesterday's signals
refresh calibration bands| API
    DB --> API
    API --> Cache
    Cache --> CDN
    CDN --> User
    CDN --> Crawler

Signal generation and post-hoc scoring share the same API code path, so “conclusion” and “verification” data sources are not separable — a structural integrity guarantee, not a policy.

Technology Choices and Trade-offs

• Frontend: Astro 5 + React 19 (Island Architecture) + TypeScript 5.9 + S3 + CloudFront. Evolved through Next.js → Vite SPA → Astro. Uses output: 'static' + client:load React islands — pages with no interactivity (About, FAQ, Privacy, etc.) ship zero JavaScript; interactive surfaces hydrate as islands only. OG metadata is handled via Astro’s <head> slot. Per-stock dynamic OG image (Satori-style composition) is deferred to a follow-up phase
• Backend: Hono on Node + PM2 on AWS Lightsail. Nine services share a single core via host-based routing (api.inverseone.com/v1/*). Going serverless would have multiplied infrastructure cost and added cold starts; a single warm process also pairs well with batch crons like daily scoring
• Database: MySQL 8.0 with a greenfield schema. Existing Neon/Drizzle data (from the Next.js era) was not migrated — restarted from a clean schema. Core query patterns are composite-indexed lookups and DATETIME comparisons, where MySQL vs Postgres makes no architectural difference
• State management: TanStack Query plus local useState. No global store — 90% of state is server-fetched, so a client store would add overhead without benefit
• Theme system: Tailwind v4 with CSS-variable design tokens (tokens.css) for a dual light/dark theme. dark: Tailwind variants and hardcoded hex colors are blocked by a build-time lint (theme-lint.mjs) — new components are dual-theme by construction
• Marketing-safe vocabulary: Five terms — “AI”, “recommend”, “target price”, “stop loss”, “guarantee” — are blocked by legal-lint.mjs in the prebuild phase. The fintech advertising compliance line is encoded as a system guardrail, not a manual review step
• What was dropped: User authentication (operational overhead during MVP), real-time price push (signals are daily — unnecessary), native mobile (Expo code is frozen pending PWA validation)

Operational Automation

Automation layers that make solo operation feasible:

• Daily signal generation — A token-authenticated scheduler hits the signal-generation endpoint after market close. It fetches market data, evaluates indicator firings, computes confidence, and writes results to the DB. Tomorrow’s user-facing signals are produced overnight without manual intervention
• Outcome-scoring automation — Yesterday’s signals are graded against today’s close as hit/miss. Calibration curves and cumulative hit rates are always current at the moment a user views them
• Consensus comparison — Institutional consensus data is refreshed periodically and labeled against InverseOne’s own signal (aligned vs diverging). The /stocks “consensus deviation” filter, the stock-detail consensus card, and the /performance “vs consensus” KPI all read from the same source
• Static OG assets — Pre-rendered OG images per signal type (buy/hold/sell) are stored in S3. Sharing a stock page produces a preview colored by the signal type (per-stock symbol composition is a follow-up)
• Build guardrails (theme / legal) — lint:legal and lint:theme run before astro build. Use of non-token colors or banned vocabulary blocks deployment outright. Type checking is handled by the Astro build itself

Current State and Operational Signals

• Status: Live on the Korean stock market with daily automated signals and accumulated outcome scoring
• Started: 2024-01 (initial release on Next.js + Neon); 2026-04 rebuilt on Vite + S3 + Hono + MySQL (greenfield); 2026-05 frontend migrated to Astro Island Architecture
• Infrastructure: Single AWS Lightsail instance + S3 bucket (inverseone.com, web/files prefix split) + CloudFront, with a backend shared across nine services
• Automation: Two daily schedulers (signal generation / outcome scoring) plus three prebuild guards (legal / theme / types)
• Verification signals: Daily signal generation has run without interruption; the calibration curve maintains positive monotonicity (higher confidence bands hit at higher actual rates); consensus comparison is operational across the catalog

Retrospective and Next Hypotheses

• What worked: The progressive-disclosure structure that fuses conclusion, evidence, and verification on a single page. Beginners get a usable read from the traffic light alone; intermediate users go deeper on the same screen. Splitting these would have served neither audience well
• What I would redo: The original Next.js + Neon stack felt like a fast win for SSR/SEO, but operationally it accrued Vercel/Neon costs, cold starts, and platform lock-in. Migration confirmed that Astro Island Architecture plus MySQL adequately covers SEO, OG previews, and social sharing — and ships less JavaScript by default. Starting on this stack would have saved the migration round-trip
• The vocabulary lint, in retrospect: Encoding “AI”, “recommend”, and similar terms as a build-time block paid off more often than expected. Copy review time is replaced by the build pipeline acting as the reviewer
• Next hypotheses: (1) US / Japan market expansion using the same engine and signal model, (2) Pro tier — saved filters, alerts, per-stock calibration — once track record is sufficient, (3) per-stock dynamic OG image composition, (4) reactivating the en / ja locales

Comparable Engagements

The capabilities developed solo on InverseOne — planning, implementation, and operations end to end — translate to other domains.

• Decision UX that fuses conclusion, evidence, and verification on one screen — Medical results + diagnosis + statistics, candidate matching + score + hit rate, real-estate listing + reasoning + track record, and any domain that asks “why this conclusion” and “is this system trustworthy” simultaneously
• Marketing-safety vocabulary enforced at the build layer — Fintech, healthcare, insurance, and any domain whose advertising rules deserve to be encoded as a build-time guardrail rather than a manual review process
• Daily ingestion plus outcome-scoring closed-loop pipelines — Signal / prediction / recommendation systems whose grading must be automated and exposed back to the same users that consumed the original output
• Multi-service backend on cost-optimized infrastructure — Multiple services sharing a single Hono core via host-based routing, dropping per-service operating cost into the same envelope
• Next.js → Astro Island Architecture migration — Exiting Vercel/Neon hosting cost, cold starts, and platform lock-in while preserving SEO, OG metadata, and social-share previews at static-site economics. Pages with no interactivity ship zero JavaScript; interactive surfaces hydrate as islands only

I prefer engagements where one person carries the work end to end — from planning to system architecture to operational automation. Reach me via /work-with-me or /contact.