Try it in 2 minutes

Step 1 of 5

Ask the planner where your team should work from

What to try

Press “Find our best cities”. The team is already filled in: London, New York and Lisbon, 09:00–17:30 each.

Why it matters

It checks every city in the registry against everyone’s working hours and the month’s climate, ranks them with fixed, tested rules, then uses AI once to explain the top three.

What you'll see

A trail of every step it takes, then three cities ranked by the hours the whole team is online together, with the working shown.

Nothing runs until you press the button.

Step 2 of 5

Run the morning Trip Watch check on a sample trip

What to try

Under “Try them now”, press “Run the morning check now”.

Why it matters

Every day at 06:00 UTC, Trip Watch re-scores every watched trip on the fresh forecast and emails the owner only when the answer changes. Nobody has to remember to check.

What you'll see

Each step ticks as its real result lands: a live forecast for each city, the new scores, then either the exact email the owner would get or a plain “no change, no email”.

A labelled sample trip, run in your browser. Nothing is saved or sent.

Step 3 of 5

Build the Monday brief for a clock-change week

What to try

Pick a Monday, then press “Build the brief”. The sample team is London, New York and Lisbon.

Why it matters

Mondays at 06:00 UTC, the brief works out each opted-in team’s shared hours day by day and emails it, so the week one city’s clocks change and another’s don’t catches nobody out.

What you'll see

The brief leads with the clock change, shows each teammate’s shared hours on every day of the week, and shows the email exactly as the Monday run would send it.

Clocks go back: London and Lisbon Sun, 25 Oct · New York Sun, 1 Nov. The brief for that week leads with it.

Built in your browser by the brief’s own code. Nothing is sent.

Step 4 of 5

See every automation run, logged in public

What to try

Read the totals, then Latest runs, then the card for each automation.

Why it matters

Every run writes one row: when it started, what set it off, what it checked and changed, and how many emails went. The page shows those counts, never a name or an email.

What you'll see

Runs in the last 7 days, the newest runs first, and when each schedule fires next. Anything that hasn’t run yet says so.

Counted live from the run log each time the page loads.

Step 5 of 5

See how it was built, and what the reviews caught

What to try

Skim the stack and the schedules, then read “What the reviews caught”.

Why it matters

It is the process behind the app: review the live site, fix in a focused pull request, ship, then check it live. Its counts are worked out from the code when the site is built.

What you'll see

Counts from the build, each automation’s schedule as set in the code, real review findings with the change each one caused, and a plain “Not done yet” list.

Anything that can’t be counted is left out, not guessed.