Goal framing — paths that shape version 1
Not a form to fill in — just the goal styles that usually come up. None of these change the time estimate by themselves. I confirm which path fits on a short call once you’re happy with the scope.
Common goal paths
In plain terms: what should the bot be optimising for in the first few months?
Research notes — terms & examples
Benchmark
A simple yardstick I compare against (e.g. “just holding EUR/USD”). Makes “it made money” meaningful — did it do better than the easy alternative?
Drawdown
How far the account value has fallen from a previous high point. Example: if it went from R180,000 to R162,000, that’s an R18,000 (10%) drawdown. Bigger drawdowns are harder to recover from emotionally and financially.
1. How should the bot place trades?
This is one of the biggest levers on safety, complexity, and timeline.
Trading mode
How much control do you want to keep on every trade?
Research notes — why this choice matters, examples & terms
Kill switch / emergency stop
One control that stops the bot from placing new trades immediately if something looks wrong. Like a fire alarm for the strategy — not a guarantee nothing bad happened, but it stops the bleeding.
Position
An open trade currently in the market. “Position size” = how big that trade is. Smaller sizes = less risk per mistake.
Lot
The unit of trade size in forex. Roughly: 1 standard lot ≈ 100,000 units of the base currency · 0.1 (mini) ≈ 10,000 · 0.01 (micro) ≈ 1,000. Smaller lots = less money at risk per pip move.
2. How aggressive should version 1 be?
More pairs and faster trading = more data, more edge cases, more time.
Market coverage & pace
I'll start narrow either way — this just sets how wide v1 goes.
Research notes — why this choice matters, examples & terms
Clarity: “One bot for all of forex” — both views, in context
In an earlier conversation, a good point came up: does one bot need to specialise, or can it handle the whole forex market? Both sides have a valid piece of the truth. Here is how they fit together — without anyone being “wrong.”
Software can absolutely watch many currency pairs at once. One program can scan the market, calculate signals, and place trades across EUR/USD, GBP/USD, USD/JPY and more. In that sense — coverage and automation — a single bot can operate across forex, not just one chart.
Different trading styles need different logic. Scalping, day trading, swing trading, and news reactions are not the same job. Markets also change character (trending vs quiet). A rule set that works well in one condition often underperforms in another. One bot can cover many pairs — but usually only one clear strategy style at a time, if results are to be trusted.
So both ideas are partly right: one bot can cover the forex market in breadth, while one strategy does not win in every style and every market condition. That is why this question exists.
Pair
Two currencies quoted against each other, e.g. EUR/USD = how many US dollars buy one euro. You always long one currency and short the other.
Timeframe
How long a typical trade might last — minutes (fast/scalping), hours (day), or days/weeks (swing). Faster trading is not “better”; it’s usually harder.
Majors
The most heavily traded currency pairs (typically EUR/USD, GBP/USD, USD/JPY, etc.). Usually more liquid and a sensible first focus for a bot.
3. Demo account first, or real money?
Highly recommend paper/demo until the process is boring. This option still matters for build work.
Trading capital mode
Where the bot will run while I build and prove the approach.
Research notes — why this choice matters, examples & terms
Why practice first — validation, not hesitation
If the question is “why only a practice-account bot in this timeframe?” — because phase 1 is built to prove the system, not to promise returns on day one. This is how serious automated systems are developed, not a smaller product or a lack of trust.
Until the bot places orders correctly, respects loss limits, and the dashboard matches reality, a losing week tells you nothing — it could be a bad strategy or a broken integration. Demo lets me fix the software with clean evidence.
I iterate on real market prices without risking capital while rules, logging, and safeguards are still being proven. That is how you get trustworthy numbers faster — not how you avoid “real” trading forever.
The finish line is a working bot + evidence pack. If the demo process is boringly reliable, going live is mostly a connection and config change — not a rebuild.
Real fills, slippage, and your own psychology are phase-2 variables. Banks, prop desks, and anyone serious about automation paper-trade first. It signals process, not amateur hour.
Demo / paper trading
A practice account with fake money and real market prices. Best way to prove a bot before risking capital. Also called “paper trading.”
Live trading
Real money at a broker. Only after demo results and clear risk rules. Not the right place to “see what happens.”
Fill
When the broker actually executes your order at a price. You might ask for one price and get a slightly different one — that difference can be slippage.
4. Where does market data come from?
Poor quality price history → misleading test results. This affects how much I trust the numbers later.
Data quality
How thorough should I be when testing the strategy on history?
Research notes — why this choice matters, examples & terms
Backtest
Replaying a strategy on past market data to see how it might have behaved. Useful, but imperfect — real trading adds costs and surprises history doesn’t fully capture.
Spread
The small gap between the buy price and sell price your broker quotes. It’s a built-in cost on every trade — the bot needs enough edge to overcome it.
Slippage
When an order fills at a slightly different price than expected — usually a small extra cost. Fast markets and large orders make it worse. Honest tests should include it.
Pip
The smallest usual quoted price move in forex. For most pairs it is the 4th decimal; for JPY pairs the 2nd decimal. Spreads and many examples on this page are counted in pips (or “points”).
5. How much visibility do you need?
You'll want to understand what the bot is doing — not just “is it up or down.”
Dashboard depth
What should you be able to see and review?
Research notes — why this choice matters, examples & terms
Equity / equity curve
Account value over time = cash + results of open trades. The “equity curve” is the chart of that value. Steady up is nice; wild zigzags mean stress.
Drawdown
How far the account value has fallen from a previous high point. Example: if it went from R180,000 to R162,000, that’s an R18,000 (10%) drawdown. Bigger drawdowns are harder to recover from emotionally and financially.
Win rate
The percentage of trades that ended profitable. High win rate ≠ always good — a few big losses can wipe out many small wins. Always read it next to drawdown and profit factor.
Profit factor
Total profits divided by total losses over a period. Above 1.0 means net positive historically. Below 1.0 means the strategy lost money overall on that data.
Trade log
The full list of what was traded, when, at what price, and (ideally) why. Essential for reviewing mistakes and improving the system.
6. Broker account — do you have one that can run a bot?
For South Africa, regulation and “can this account run automation?” matter more than the app itself. You pick or verify the broker; the tech lead handles how the bot connects to it.
Broker readiness
This is about finding a bot-friendly account — not about choosing software internals. The tech lead decides how the bot talks to the broker once that account exists.
Research notes — why this choice matters, examples & terms
South Africa — broker checklist before you fund anything
The client is in South Africa, so “which broker?” is not only a technical question. These checks protect the project (and the money) before any integration work starts.
Look up the broker’s South African entity on the FSCA register and note the FSP number. Some brokers are FSCA-licensed locally; others serve SA through offshore entities. Both can be workable — but you should know which entity you’re actually signing with.
Confirm the account type allows automated strategies (Expert Advisors / API trading). Many SA clients assume their bank’s FX app can run a bot — often it can’t. Bank platforms are usually for manual retail FX, not third-party automation.
Worth confirming early: can the account be denominated in ZAR (or at least funded easily from SA)? Local EFT / card options reduce friction vs international-only funding.
I build and prove the bot on a demo account first. If the broker makes demos hard to get, that’s a yellow flag for phase 1.
Broker
The company that holds your trading account and executes orders with the market. Your cash and positions live here — not in my dashboard.
API
A structured way for software to talk to another system. Here: my bot tells the broker “open/close this trade” and reads balances — without you clicking in an app.
MT4 / MT5
MetaTrader 4 and MetaTrader 5 — common desktop/mobile apps many forex brokers support. Popular for retail automation and demo testing. Automated strategies on MetaTrader are often called Expert Advisors (EAs).
FSCA / FSP
FSCA = Financial Sector Conduct Authority — South Africa’s market conduct regulator (formerly the FSB). FSP = Financial Services Provider number — the licence number you can look up on their register.
7. Who drives the strategy design?
Important to be clear about roles — this changes research time, not just “who types the code.”
Strategy ownership
Do you already have a trading approach in mind, or do I research and propose one?
Research notes — why this choice matters, examples & terms
Clarity: rules vs “AI” — where the line is
It’s easy to assume the bot “uses AI” to make trading decisions. In practice, rules and AI are different layers. Version 1 can work with rules alone. A model is optional and only helps if it earns its place with evidence.
Written conditions you can read: when to buy, when to sell, how much to risk, when to stop. These decide the trade. Risk limits (max loss, position size, emergency stop) are also rules — and they override everything else.
If used, a model usually scores a setup — e.g. “this pattern looked promising 62% of the time historically.” It recommends. It does not ignore your loss limits, invent new money, or trade without the rules saying yes.
1. Rules: “If daily close is above the 200-day average → potential buy; risk 1%; stop at 2%. Don’t trade if today already lost 3%.”
2. Optional AI inputs (only if I add them):
• Pattern score: model says this setup looked promising ~62% of the time historically → 64/100.
• News / sentiment (optional extra): headlines this morning sound “risk-off” (fearful) → mood score 35/100 (weak for buying risk assets).
3. Decision: combined signal only counts if rules are happy and risk is within limits.
Example: pattern looks fine, but news is very negative → bot skips or waits instead of buying on autopilot.
4. Action: Signals mode → idea (or “no trade”) appears in dashboard for your Approve/Decline.
Auto mode → bot places a small trade only if all checks pass; emergency stop still applies.
If there is no AI, steps 2a/2b are skipped — the same rules still work. News reading is an add-on, not the brain of the system.
Strategy
The written rules for when to buy, when to sell, and how much to risk. If you can’t explain it simply, it’s not ready for real money.
8. AI now, later, or not at all?
This is the only place “AI” changes the build timeline. Rules decide trades either way — AI is an optional input, not the brain.
AI in version 1
How much AI (if any) should be built into the first version — knowing it can be added later only if evidence justifies it?
Research notes — why this choice matters, examples & terms
What “AI” means in the tech stack (developer recommendation)
You don’t need to pick libraries. These are defaults if AI is chosen later — and they explain why “rules only” is cheap and “AI as core” is expensive.
No ML infrastructure. Pure Python rules engine + risk checks. Same stack works whether or not AI is added later — nothing gets thrown away.
Simple supervised models (scikit-learn / gradient boosting) on historical features. Still no LLM required — the model scores setups from numbers, not chat.
Longer research loop: feature engineering, walk-forward validation, bias checks. Still CPU-scale for 1–2 pairs — the cost is research time, not compute. This is also not an LLM job by default.
Black-box “AI trading” with no rule layer, no risk caps, or no explainable trade log. If a model can’t be explained next to the equity curve, it doesn’t ship.
AI / model
A statistical system that can score whether a setup looks promising based on past data — and, if I add it, a separate piece can read news “mood” (sentiment). Both are inputs to the strategy, not replacements for rules or risk limits. Version 1 can work with no AI at all.
Classic ML vs LLM
Classic ML = older, simpler statistical models trained on numbers (price history, indicators). They output a score or probability. No chat, no writing. Cheap, explainable — enough for optional setup scoring. LLM = chat-style AI (ChatGPT, DeepSeek). Reads text and news. More expensive and harder to control. Not required for v1 — and not what “AI scoring” means on this page.
Sentiment signal
A measure of market “mood” from news or social data, used as one input among many. Interesting later; not a substitute for tested risk management.
9. Personal use, or something more formal?
This is about safeguards and documentation — not legal advice. If you're building for others, say so early.
Use case & safeguards
Who is this for, and how careful do I need to be about controls and records?
Research notes — why this choice matters, examples & terms
Regulation / compliance
Country rules about who can offer trading tools or services. Personal use of your own broker account is usually simpler. Building for other people can require extra legal checks — I’ll flag, not advise.
Risk limit / stop loss
Rules that cap how much can be lost — per trade, per day, or in total. The bot should refuse to keep trading past agreed limits. This is more important than any prediction model.
What you’d get if phase 1 goes ahead
This is the concrete package — useful when deciding whether the time investment makes sense.
Practice-account bot
Runs on a broker demo account with your chosen pairs and loss limits. No real money until you choose to switch.
Evidence report
Results from past market data and/or demo trading — so “does this idea work?” has numbers, not vibes.
Dashboard
Account value over time, worst losing stretch, win rate, and a trade history you can review in plain language.
Runbook
Simple doc: how to start it, how to stop it, what the metrics mean, where your money sits.
Phase 1 done means
Clear finish line so “done” is not vague. This is a validation milestone — the same trading software, proven on demo before any live talk.
Demo bot on your chosen pairs under agreed risk limits · evidence report (backtest and/or demo) · dashboard with equity curve, drawdown, win rate, and full trade log · runbook · kill switch tested.
Rules fire when they should · risk caps actually stop trading · logs match what the broker shows · ~2–4 weeks of demo observation before any live conversation.
Technical approach — tech-lead defaults
These are tech-lead defaults — not client decisions. You don’t need to pick languages or libraries. Reasons are included so the choices are explainable, not arbitrary.
Frontend — SvelteKit
Dashboard for equity, trades, and risk controls. The bot’s profit does not depend on which frontend framework I use.
Backend — Python
Strategy logic, backtesting, data work, and broker control.
Database — PostgreSQL
Trade logs, equity history, bot state. Self-hosted on the same VPS as the bot.
Execution — MetaTrader 5 EA
Expert Advisor places trades inside MetaTrader unless the broker choice makes a Python API route clearly better.
AI in v1 — rules only, no LLM
No ML infrastructure on day one. Even if AI scoring is chosen later, classic ML models are enough — not DeepSeek/ChatGPT APIs.
Hosting — VPS for the bot
Commodity purchase so the bot can run 24/7. Not a scoping decision.
Not considered for phase 1 — can be discussed once we engage
Left out of the time estimate on purpose — not banned forever. Nothing here is locked out: anything on this list can be discussed, scoped, and added once engagement begins.
- Guaranteed accuracy or returns No one can honestly promise that. Better odds come from correct planning and engineering — not magic.
- Mobile app A browser dashboard covers version 1 — a native app can be scoped later if needed.
- Multi-broker / multi-account support One broker, one account, proven first — more accounts are a later conversation.
- Full auto-trading on day one Possible as an option — not the default safe path.
- AI news trading as the core strategy beyond Decision 8 Optional scoring or core AI are selectable there with extra timeline — not a silent add-on.
- 24/7 human monitoring team Alerts yes; on-call desk no (unless separately scoped).
- Payments / wallet features inside the platform Trading money stays at the broker.