DEV Community: taste kim

Trader Pro v0.3 shipped — Korean + US stock backtest GUI on KIS OpenAPI

taste kim — Mon, 18 May 2026 07:19:53 +0000

TL;DR

Shipped Trader Pro v0.3 — a desktop GUI (Electron + Vite + React + TypeScript) wrapping the Korean Investment & Securities (KIS) OpenAPI for backtesting and paper trading on Korean + US stocks. v0.3 is a full visual redesign + the cumulative work of 14 phases.

Stack: Electron 33 · Vite 5 · React 18 · TypeScript 5 · Zustand · Lightweight Charts · electron-builder · Pretendard + JetBrains Mono

Buy/Download: tastekim.gumroad.com/l/epgoll ($79 · lifetime updates)

What v0.3 changes

Visual redesign (Phase 14)

Mint primary (oklch hue 175) — calmer, more modern than the previous cyan
Shadow-driven depth — 5-tier surfaces, almost no 1px borders
Typography pair — Pretendard (Korean/Latin sans) + JetBrains Mono (price/numbers)
Modern radii (6/10/14/18px)
Design tokens consolidated in tokens.css — single source of truth for color, shadow, radius, density

Cumulative features (Phase 1–13)

Custom strategies with 8 indicators — RSI, Bollinger Band, Volume Spike, SMA, EMA, MACD, Stochastic, ATR, freely composable, persisted via electron-store
Multi-timeframe backtest — 1m/5m/15m/30m/60m + daily/weekly/monthly, with auto-pagination through KIS API's 100-day chunk limit (up to ~5 years)
Multi-indicator chart — toggleable overlays (SMA/EMA/BB) + sub-panels (RSI/Stoch/ATR)
Chart animation — backtest results play back oldest → newest with skip
Portfolio system — up to 50 holdings, weighted-average multi-symbol backtest, auto-portfolio from actual KIS holdings
Live/paper mode — separate page with realtime price pulse, SVG sparkline with markers, position card with live P/L, 5/30/60/120/240-min milestone guides, auto session report on stop
Markets — KRX + NASDAQ + NYSE + AMEX + HK + Tokyo + Shanghai + Shenzhen; 26 ETFs in autocomplete (KODEX/TIGER/QQQ/SPY/VOO/VTI/TLT/GLD/SLV)
Market hours + FX — KRX/US session state with weekday and KST conversion, live USD/KRW rate refreshing every 5 min
Paper/Live budget split — Paper: user-entered, Live: pulled from KIS balance API
Auto-update checker — manifest hosted on a secret GitHub Gist, in-app banner on new release, Gumroad re-download for buyers

Automated tests — 106/106 PASS

Why these choices

Why Mint over Cyan

Cyan can read as cheap/generic in trading dashboards. Mint with oklch hue 175 sits in the same calm-cool family but is distinct enough to be a brand color, and it pairs well with semantic red (loss) without clashing.

Why no order automation

v0.3 is monitor + paper simulation only. Real orders go through KIS HTS/MTS by the user. This keeps the legal surface area small while still delivering ~95% of perceived value: backtest engine + live indicator evaluation + signal alerts + position simulation.

Why pagination over websocket

KIS daily-OHLCV is a REST endpoint that returns ~100 trading days per call. A 5-year backtest needs ~12 sequential calls per ticker with 200ms delay between calls. WebSocket adds infrastructure complexity for marginal value when most retail KR traders care about daily-bar strategies.

Why a hand-rolled update manifest over electron-updater

electron-updater needs Apple code-signing ($99/year). For a $79 one-time product, a secret GitHub Gist + in-app banner + Gumroad re-download covers the same ground at zero cost.

Architectural notes

Single IPC entrypoint

// preload.ts
contextBridge.exposeInMainWorld('kisApi', {
  fetch: (args) => ipcRenderer.invoke('kis:fetch', args),
});

One window.kisApi.fetch({ action, params }) covers KIS, portfolio CRUD, strategy CRUD, fx, and update-check.

Live engine = tick aggregator + indicator on candles

1-second poll → tick log → bucket into the user-selected interval → run identical indicator math as the backtester. Same math both sides means live signals match what backtest predicted.

Two Zustand stores

tradingStore (UI/settings) and liveStore (session ticks/signals/position). Splitting avoids re-rendering settings UI on every tick.

Try it

Gumroad: $79 — lifetime updates, in-app update banner, macOS arm64 (.dmg / .zip).

I built a Korean stock auto-trading GUI on KIS OpenAPI — Trader Pro Beta

taste kim — Fri, 15 May 2026 16:12:47 +0000

TL;DR

I built Trader Pro — a desktop GUI for Korean stock auto-trading on top of the Korea Investment Securities (KIS) OpenAPI. It combines backtesting, live trading, and indicator customization in one app, no coding required.

Beta is live (macOS): https://tastekim.gumroad.com/l/epgoll ($79, saves $20 off the June 1 launch)

Why I built it

I had a Node-based trader using KIS API and a backtest engine that worked, but only as a CLI. Friends wanted to try it without learning the command line. So I wrapped it in Electron + React + TypeScript.

What's inside

Backtest engine

TP/SL collision via candle-pattern estimation (bullish candle → SL likely first; bearish → TP first)
In-sample / out-of-sample split (70/30) for walk-forward validation
Kelly Criterion + R/R ratio + Expected Value per trade
Korean fee/tax accounting (0.21% round-trip)

Live trading

KIS OpenAPI integration with mock/real account toggle
1-min polling for current price
Auto TP/SL exit + EOD close at 15:30 KST
Telegram alerts coming v1.0

Customizable strategies

5 validated presets: G1/G2/G4 gap-down, RSI Oversold, Bollinger Squeeze
Edit gap threshold, TP %, SL %, budget, ticker pool
RSI / Bollinger / Volume filters

Validated numbers (out-of-sample, last 30% of 100-day data)

G4 strategy on Samsung Electronics (005930):

47 trades
Win rate 63.8%
R/R 1.34
EV per trade: +1.93%
Max drawdown: -4.21%

Past results don't guarantee future returns. Standard disclaimer applies.

Stack

Electron 33 + Vite + React 18 + TypeScript 5
Zustand for state
Lightweight Charts (TradingView) for candle chart
Axios for KIS API
Tailwind for styling
Built for macOS (Intel + Apple Silicon), Windows build May 25

Try it

If you're in Korea and trade through KIS — or just want to see how a small Electron + Vite + Zustand app comes together — grab the beta:

→ https://tastekim.gumroad.com/l/epgoll

$79 (50% off launch), 7-day refund, lifetime updates.

Happy to answer questions in the comments — about the backtest math, the KIS integration, the Electron packaging, anything.

— Tastekim

I encoded indie hacker discipline into Claude Code agents — here's the pattern

taste kim — Fri, 15 May 2026 12:05:16 +0000

Most indie products don't fail at code. They fail at the disciplined parts AI tools won't force you through: validation, MVP scoping, pricing, launch.

I spent a few weeks codifying those parts into Claude Code agents with one specific pattern that changed everything: explicit refusal clauses and kill criteria in the agent prompts.

The problem with helpful-only agents

When you ask Claude (or any frontier model) to help, the model tries to deliver. That's the entire training signal — give the user what they asked for.

This works for well-specified tasks. It fails for ambiguous decisions and bad inputs.

Ask the model "validate my SaaS idea" — a helpful-by-default agent will validate it. It can argue both sides, but the bias is toward yes. Yes is more help-shaped.

Ask "price my product at $9/month" — a helpful-by-default agent will help you justify $9. It won't say "actually you should charge $39 based on competitive data" unless you specifically open that door.

The missing instruction is the list of things the agent should not do, regardless of what you ask.

The pattern: "Refuse to" sections

Here's the literal section from a pricing-strategist agent I wrote:

## Refuse to

- Pull pricing out of thin air without competitive benchmarking
- Recommend "free forever" without a clear monetization path
- Suggest gimmicky pricing (random odd numbers, fake "sale" prices)

And from a cold-outreach-writer agent:

## When to refuse

If the founder wants to send the same email to 1,000+ unverified contacts → refuse.
That's spam, it doesn't work, and it gets domains blacklisted.

If the founder has no clear ICP → refuse.
Cold outreach without targeting is theater. Send them to the idea-validator agent first.

These aren't safety filters. They're domain-specific refusals based on what makes the underlying task succeed or fail in the real world.

Why this works

LLMs follow instructions in context. If you say "refuse to X" the model will refuse X — at least the obvious cases. The behavior change is large and reliable for prompts that explicitly enumerate refusal cases.

The value: the agent's outputs become genuinely useful rather than just superficially compliant. You ask for a quick pricing rec; it pushes back if you haven't done the homework. You ask it to draft a cold email; it asks for an ICP first.

That pushback is what a senior co-founder would do. It's what's missing from generic AI assistants.

Kill criteria are even stronger

A step beyond refusal: each agent has Kill criteria — hard conditions that, if true, force the agent to output a NO-GO verdict.

The idea-validator agent has five:

Problem has no existing workaround AND no public complaints → score ≤ 3
SOM × realistic price < $50K ARR potential year 1 → score ≤ 4
Zero competitors AND zero indirect solutions → score ≤ 2
Buyer needs new budget category to pay → score ≤ 5
Distribution plan is "post on Twitter and hope" → score ≤ 2

If any trigger, the agent stops weighing and reports the kill. No softening. No "but here are some considerations."

This single pattern killed two of my own bad ideas in the first week. Each one would have been ~6 weeks of work otherwise.

The hook variant for the strongest refusal

For "don't write code outside the MVP spec," I went one step further and implemented it as a Claude Code PreToolUse hook.

The scope-creep-guard hook intercepts every Write or Edit operation, checks the project's MVP-SPEC.md, and prompts the user if the file path doesn't appear to be in scope.

The difference between a refusal in the prompt and a refusal in the hook is who has the last word. Prompt refusals can be argued past. Hook refusals require an explicit override action — slow enough that you actually think about it.

For things that should always be slow (touching production, writing code outside scope, deleting data), use hooks. For things that should be carefully reasoned (pricing, scope, positioning), prompt refusals are enough.

What it cost

Three friction points worth naming:

The agent gets argumentative. You sometimes know better than the agent does about your specific context. The refusal triggers anyway. You have to either provide the bypass context or override.
Refusals can be wrong. A blanket "refuse to do X" rule will misfire on edge cases. The agent should have an escape clause ("unless the founder explicitly justifies why this edge case is different").
Token cost. Refusal sections take 50-200 tokens per agent. Across a multi-agent workflow this adds up. The improvement in output quality more than compensates, but be aware.

Try the pattern yourself

Steal the pattern even if you don't use my agents:

Add a ## Refuse to section to your own agent prompts
List 3-5 things the agent should NOT do under any circumstances
Add 2-3 Kill criteria for hard NO-GO conditions
Watch the output quality improve

Or use the agents directly. I packaged this work into a Claude Code toolkit:

Free preview agent (MIT) — the idea-validator with full kill criteria + sample output
Full $19 toolkit — 5 agents, 3 skills, 2 commands, 1 PreToolUse hook (scope-creep-guard). LAUNCH code → $14 for 72hrs.

The methodology is in the README either way. Most of the value is the discipline encoded in the prompts.

What other disciplines would you encode into your agents? I'm thinking churn-diagnostician next.