Use case

Your app, verified on every change and in between

Passing unit tests tell you the code runs. They do not tell you the feature works. Composal keeps checking the running product, on every pull request and, from your CI, after each deploy, and reports every result with the steps to reproduce each failure.

Read the docs
Composal · always watching your app
Pull request #1042 just now1 finding
Nightly run against stagingNo change
Deploy to productionNo change
Pull request #1041Passed
CI run, early morningNo change

Where the time goes today

Green builds, broken features

The pipeline asks whether the code compiles and the tests pass. Nobody asks whether the feature still works for the person using it.

Checking is a task someone has to remember

Playing with the product after a change depends on who has time and how tired they are. Small changes slip through.

Every run starts from nothing

Scripts do not learn. Each run repeats the same checks and misses what changed since the last one.

1

It runs without being asked

Pull requests start a run, and your CI can start one after a deploy. Composal tests the exact commit that shipped.

Pull requestCI jobDeploy
Composalruns the Scenarios and scans that matter
2

It remembers what it learned

Knowledge builds up run after run, like a QA engineer who remembers how the product behaves and what was already reported.

Knowledge · Billing
Run 1Run 4Run 9
Each run adds what it learned, so the next run starts ahead.
3

It reports what it found

Every run reports back, and each failure comes with the steps to reproduce it.

FindingInvoice total ignores new seats
Steps to reproduce attached
3 runs since: no change

Continuous integration for features

The check your pipeline was missing: does it actually work for the user?

Nobody has to remember

Verification is part of how code ships, not a favour someone does.

Signal over noise

Findings arrive with evidence, and the product’s known quirks do not come back as bugs.

See every use case