Which variant
made more money.
Assign the split, join each variant to the payment data, and read the verdict: which arm earned more per acquired customer, and whether the difference is significant. Enter your own numbers below to see one.
Try a verdict · enter the counts from one of your tests
The variant earns more and the gap is significant. Ship it.
Computed from the numbers entered above. Nothing here is a customer result. In a workspace the payment figures come from the payments database.
Why teams stop testing
The usual choices are an enterprise contract, a homegrown setup, or no experiments. This is a fourth: the split, the payment data and the verdict in one tool.
Enterprise tools are priced for enterprise budgets
Indie products, bootstrapped SaaS and in-house growth teams run on margins where a bad release costs real money. A $40k annual seat is out of reach.
Homegrown experiment frameworks stop being maintained
Teams build their own. The person who wrote it leaves, the results sit in a spreadsheet, and the next test starts from zero.
Event analytics is not an experimentation layer
Analytics records what happened. Significance tests, holdouts and feature flags need their own layer.
Dashboards built for statisticians, read by product managers
A product manager needs one of three answers: ship, stop, or keep running. The significance figures belong next to that answer, not in place of it.
Built by the team that uses it.
optimiser.pro is built by a product-ops team for its own payment-led products. The team had a homegrown setup that stopped being maintained and could not justify an enterprise contract.
The tool puts the split, the payment data and the verdict in one place and answers one question: did the variant earn more than the control, and is the difference significant.
Where it runs today
One workspace runs on it so far: the team's own products. This page describes what the product does. There are no customer quotes because there are no other customers yet.
How a resolved test reads
Each experiment is a hatched column. The one that cleared its control with a significant revenue lift is solid, with the lift on it.
Illustrative. The lift shown is an example of how a resolved test reads, not a result we are claiming.
From a split to a decision in four steps
A dashboard and one HTTP endpoint. Nothing to install and no SDK to version. The significance test runs on every read.
# one row per variant key: "checkout_copy" control 50% → ?theme=classic variant 50% → ?theme=direct
# PostHog-compatible POST /api/decide { distinctId: "user_42" } → { themes: ["direct"] }
# per variant, from payments auth rate 61.4% rebill rate 38.9% rev / acquired €21.07
# two-proportion z-test winner: direct rev / acquired p=0.02 auth rate not significant
Figures shown are an illustration of the output shape, not a customer result.
Your stack stays where it is.
The tool decides which slug a visitor gets and reads what the payments database recorded. Your pages, content and analytics stay where they are.
- No CMS
- No visual editor
- No SDK
- No tag manager
- No data team
Your storefront and the stack it runs on. It already renders variants from a slug.
Your CMS, if you have one keeps owning content. The tool never writes a page.
Your analytics keep counting pageviews. The tool counts revenue.
Your payment provider is the source of truth we read from.
The testing suite and the script it injects into every page.
The flicker from client-side swaps after the page has painted.
The results spreadsheet that only one person could read.
The contract renewal priced on traffic you never tested.
What is counted, and what is not
claimed.
Three rules decide what appears on the dashboard and what a winner means.
# same test, two readings conversion +4.0% rev / acquired −€2.10 verdict not a win
# nothing wasted tests run 37 conclusive 2 logged 37
# read it honestly lift +48% probability 66% call re-test
Split. Join. Verdict. Ledger.
Four things the tool does, and one overview. Pick a screen.
Ship, stop or keep running, on one row.
The winner, the money and the p-value sit together. Settled runs get out of the way into the archive; the ones that need a call stay on top.
No dashboard builder. The rows are the dashboard.
Active experiments
Illustrative data. Your workspace shows your own experiments and your own payment figures.
Flat, published, priced on events
Priced on the events you send: the assignment and capture calls processed, not everyone who loaded a page. Two months free on annual billing. Every tier is published.
- ✓Unlimited experiments and feature flags
- ✓Server-side assignment, no anti-flicker snippet
- ✓Significance and SRM readouts
- ✓Per-variant payment P&L and the verdict
- ✓Assignment API — /decide, /capture, /flags
- ✓Everything in Operator
- ✓Multiple projects in one workspace
- ✓Metric registry, each metric with its own direction
- ✓Priority support
- ✓Everything in Studio
- ✓Multi-brand, multi-tenant workspaces
- ✓Onboarding of your existing test history
- ✓SLA
Priced on events, not traffic. Overage is billed at the same per-event rate. For more than 25M events a month, send a request.
The preview runs the product on staged data with no form. Read a verdict, walk the assignment API, see how a variant joins to the payment data. Then ask for a workspace.
Existing workspace: Sign in.
One workspace in production
optimiser.pro runs the experiments on one company's payment funnels today, the team that builds it. That is the whole reference list at present.
The engine is PostHog-compatible, so a storefront already calling /decide and /capture points at it without a code change.
Tests that ran in VWO import into the archive, so the history of what was already tried is kept.
Each workspace has its own subdomain, and the workspace is resolved from it on every request. One workspace runs on it today.
Run it on your own funnels.
From €149 a month per workspace. There is no trial and no signup form. Look at the preview, then tell us what you run and we open a workspace with you.