Getting started

What Simulithic is

Simulithic sends simulated users through your product before real ones get there. Each one drives your app in a real browser or on a real phone, on the devices your actual visitors use, carries your flows out end to end and reports what broke. Ask for UX and the people become your visitors’ personas, with their patience, so the run also shows where they hesitated or gave up. You run them on every pull request, as a check that compares the PR’s build with the one in production; on a schedule against production, as monitors; and on demand from the Studio.

Five things fit together:

• Map. The explorer opens your product, presses every safe control on every page, and writes down each journey a person can take. Those journeys become your flows, with no test scripts to write.
• Check. Every pull request sends the same people through the same flows on the preview and on production, and posts one comment with what broke, per flow and per device.
• Monitor. The same runs repeat against production on a schedule, and Slack hears about it when a flow stops working.
• Capture. The Behavior SDK — one tag — records how your real visitors move through your product (routes, controls, timing, devices; never content), so the simulated people run on the devices your visitors use and take the routes they take, not a generic tester.
• Predict. Experiments estimate what a change does to a goal before you ship it, and check the estimate against what real users then did.

Before you start

You need a Simulithic account and a workspace. Accounts are invite-only while we onboard design partners; write to team [at] simulithic [dot] com for a code. A workspace is your product: it has a id, the people who can see it, and its own journeys, runs, checks and recordings. One account can hold several workspaces, one per product surface (a marketing site and an app are usually two).

For the command line you need Node 20 or newer. The CLI installs with one line and no npm account: curl -fsSL https://app.simulithic.com/cli/install.sh | sh.

1. Install the Behavior SDK

Open Setup in the Studio (or ask your connected coding agent for capture_snippet). It shows one script tag with your workspace id filled in. Put it before </body>on every page, or in your app's web layer:

<script src="https://app.simulithic.com/v1.js" data-project="ws_xxxxxx"></script>

It records behaviour, never content: the routes visitors take, the controls they press, the time between actions, their device and browser — no text, no values, no identity. Within a minute of the first visit Setup shows the session, and from then on the simulated people run on your visitors' devices and the routes real people take become journeys. The Capture page covers every attribute and theSimulithic.goal() call that names the outcomes that matter.

2. Map your flows

A flow is a task a person can be sent on: “starting from Home, make your way to Settings”. Flows come from two places. Once you have recordings, the pages your visitors actually reach become flows on their own. For the complete picture, including pages behind a login, map the product with the CLI:

curl -fsSL https://app.simulithic.com/cli/install.sh | sh     # one line, no npm; needs Node 20 or newer
export PATH="$HOME/.simulithic/cli:$PATH"                         # the installer prints this line
simulithic login
simulithic map https://app.yourproduct.com --upload     # a native app instead: simulithic map --app build/MyApp.app  (or --app app-release.apk)

The explorer opens your product in a real browser, follows every link, presses every safe control on every page, and uploads the pages, controls and journeys it found as your flow set. Behind a login, pass --login-url and --user and put the password in JOURNEYS_PASSWORD. The result shows up in the Studio as the canvas on the Simulate page.

3. Run your first simulation

Open Simulate. The canvas shows the page people start on and every flow as a card. Leave every card ticked, pick a type of user on the right, keep three people per flow, and press Run. Within a minute the people appear in the feed under the canvas, screen and all; a few minutes later the run is done and shows, per flow and per device, who reached the goal, what each person did, a recording of each session, and what went wrong with a fix prompt where it can tell.

If your product needs a sign-in, store a test account under Settings → Credentials first. Every simulated person then starts signed in.

4. Put a check on pull requests

The check runs the same simulated people through the same flows on the PR’s preview build and on production, and reports the difference per flow and per device. Mint a CI token with simulithic token --name github-ci, add it to your repository’s secrets as SIMULITHIC_TOKEN, and add the workflow from Pull-request checks. From then on every PR gets one comment with a verdict.

5. Get told when something breaks

Tick Repeat as a monitor on any run to have the same people go through it on a schedule, and connect Slack under Settings → Integrations to hear about a failing check, a monitor that started regressing, or a new high-severity finding in the channel you choose.