Quickstart

This walks the whole path in about ten minutes. If something fails, jump to Troubleshooting.

This page is for developing IndicaView on your own machine. To use the product, open the hosted workspace instead — see Getting started.

Assumes you have already run the local setup in Getting started. If not, start there — it takes a few minutes and nothing below will work without the vendor step.

1. Start the workspace

PowerShell

npm run dev

Then open http://localhost:8080 .

The first launch copies the vendored browser bundles and then serves app/. Give it a moment — the initial page load is fetching candles.

Why the vendor step is separate from the run command

The bundles are copied to disk before the app serves anything, and that copy belongs to Getting started rather than to npm run dev.

It is worth separating the three things a first launch does, because they look like one slow start: the copy of the vendored browser bundles, the serve of app/, and then the first page load fetching candles. The pause you are looking at is the copy.

That is the whole reason this page assumes the local setup has already run. Without the vendor step there is nothing to serve, and nothing below works.

Screenshot pending

awaiting screenshots/workspace-overview.png in public/

Workspace layout. The chart and editor stay mounted while Optimizer and Analysis replace the lower panel.

2. Pick a market

The topbar controls the market. The symbol picker has a search button that queries Binance for every USDT spot pair and ranks them by 24-hour quote volume, so the liquid pairs float to the top.

Only USDT pairs are listed, and that is deliberate: the Vela provider ships USDT feeds, so a non-USDT pair would silently fail to resolve instead of erroring.

Timeframes are grouped (seconds / minutes / hours / days / weeks) with a custom field for anything else. Both the symbol and the timeframe are remembered between sessions.

3. Load a strategy

The Pine editor starts with the template pre-loaded. Any file in app/strategies/ is available from the strategy picker:

Pick this	If you want
`ema_cross.pine`	The RSI-filtered EMA cross — a good optimizer subject
`multi_signal.pine`	A larger multi-signal study
`rsi_strategy.pine`	The only real-fills script

4. Run a backtest

Press Ctrl+Enter, or click ▶ Run.

Screenshot pending

awaiting screenshots/backtest-panels.png in public/

Backtest panel. Metric cards and the equity curve are filled from real fills only for strategy()-mode scripts.

Now read the result honestly. This is the step most people skip:

If the script is indicator()-mode — which ema_cross.pine and multi_signal.pine are — the trade list and every derived metric are synthetic. They were reconstructed from plotted signals, not simulated from fills. Only rsi_strategy.pine gives you real fills. See Engines — real fills vs synthetic.

The panel has three tabs: Performance (metric cards plus the equity curve), Trades Analysis, and Trades Log.

5. Your first optimizer run

Switch to the Optimizer workspace. The chart and editor stay mounted — only the lower panel changes.

Configure. The parameter editor reads the input.* declarations straight out of your Pine source. Every knob you defined becomes a searchable dimension.

Where the dimensions come from, and where they cannot

They are derived from the Pine source, not declared in the optimizer UI. There is one place a parameter is defined, and the search space is built out of those definitions rather than out of a second list you maintain beside them.

A value that is hard-coded in the script is not a dimension, because there is no second place to register it. Moving a constant into an input.* declaration is what makes it sweepable.

Everything else on the form — method, budget, seed — you set here. The search-space model behind the axes is in Optimizer.

Pick a method (Brute, Grid, Random, SA, TPE or GA), a budget, and a seed.

Screenshot pending

awaiting screenshots/optimizer-config.png in public/

Optimizer configuration. Parameters, algorithm, budget and seed are captured when the run launches.

Launch. Configuration locks, and the run captures the source, the bars and the search space it was given.

The three things a run captures, and when

All three are fixed at the moment you launch:

The source — the Pine as it stands at launch, not as it stands later.
The bars — the symbol and timeframe the trials evaluate on.
The search space — the dimensions derived from the source, as configured at that moment.

That is what the configuration lock means. The method, the seed, the budget and the axes are fixed for the life of the run.

Watch. Trials complete progressively and persist as they finish. Pause and Resume continue the same run; Stop keeps every completed trial and discards only the evaluation that was in flight. Starting a run that is already running is ignored rather than spawning a second pool.

What Stop actually discards

Trials persist as they finish, so a completed trial is already written by the time you press Stop. Stop discards exactly one thing: the evaluation that was in flight.

Everything already persisted stays, and so does the run record. Pause and Resume continue that same record rather than starting a new one, which is what makes a stopped run worth keeping instead of re-running.

Screenshot pending

awaiting screenshots/optimizer-results.png in public/

Results table. Every completed trial is listed; selection is tracked by original trial index so it survives sorting and filtering.

Export.

The results panel’s actions live in a Result actions menu (⋮): CSV, JSON and Share card.

Seed matters. A fixed seed makes the run reproducible, which is what lets the project assert that a UI change did not perturb the optimizer. Leave it alone while you are learning.

6. Open the analysis

Open analysis replaces the popup with a full Analysis workspace for the current run. It reads persisted data — it never starts a worker and never runs a backtest.

Screenshot pending

awaiting screenshots/analysis-overview.png in public/

Analysis Overview. Reads an existing run — it never starts a worker or a backtest.

The sections cover the run’s trials, parameter and performance analysis, trial comparison, Snipe (a focused single-trial view) and run details. “Open in Snipe” jumps straight to the exact trial you had selected, not just to the run.

7. Optional — the Python track

The CLI half is independent of the browser.

PowerShell

uv venv

uv pip install -r requirements.txt

python orchestrator/sweep.py —config examples/sweep_quick.yaml —dry-run# prints the grid without running

python orchestrator/sweep.py —config examples/sweep_quick.yaml

That writes results/<run-id>/ with the per-cell output, a summary.parquet and the resolved config. Rank and report it:

PowerShell

python orchestrator/rank.py --summary results/<run-id>/summary.parquet --out ranked.csv

python orchestrator/report.py --summary results/<run-id>/summary.parquet --out report.html

Full flag reference in CLI reference.

8. Optional — theme

The app follows a single theme across the chart, the editor and every panel. Switch it and the editor’s syntax theme swaps with it rather than staying stuck in one mode.

Screenshot pending

awaiting screenshots/theme-toggle.png in public/

Theme. The editor and chart theme follow the application theme.

Where to go next

Optimizer — the algorithms, the worker pool and the search-space model.
Analysis — the eight sections and what each one does.
Endpoints — what the app talks to, and what it deliberately does not.
Limitations — what this tool does not prove.