Pulse

A hyperlocal event platform, from the data pipeline up to the interface.

Role: Designer and main builder, at Strata
Duration: March 2026 to now
Product: iOS and Android app, data pipeline and staff tools
Focus: Event data quality, human review, privacy-first analytics

The events feed, with city, date and category filters.

Overview

Pulse is an events and places app for Kitchener, Waterloo and Cambridge. People follow venues and artists online and still miss concerts, comedy nights, markets and art shows, because the listings are scattered across websites, Instagram and Facebook. Pulse gathers them into one feed.

Pulse is a Strata product. I designed it and built most of it using Claude: the app, much of the data pipeline and the staff tools that keep the catalogue clean. A colleague started the backend, and from May 2026 I was its main author.

It is live on the App Store and Google Play.

Problem

Collecting events is the easy part. Publishing only the right ones is hard:

The same event arrives from several sources and from repeat runs. One feed piled up 2,614 rows for 383 real events in eight days
A weekly event is many dates, and a rejected date must not come back
Sources put events at the wrong venue. In one baseline, one in five landed in the wrong city
Most images a crawler finds are logos. In a dry run, about 71 per cent were
A model reading a web page can state things the page never said

People only keep an events app if they can trust what is in it.

Key decision

Nothing goes live without a person.

On the first real run of the pipeline, 419 events reached the public catalogue that nobody had checked. The rule since then: automation can approve an event or reject it, but only a curator can publish.

I designed the publish step around that rule. It checks for duplicates first, then shows exactly what will go live, in dates and listings, before anyone confirms.

Approach

The rules I worked to:

Tell the model the rule, then check it in code. Every extracted field has to be backed by text on the page
Hold, do not guess. An event with no confident venue match gets no address and waits for a curator
Design from tokens only. The app has no hard-coded colours or spacing
Keep people's data on their phone wherever possible
Ship small and often. About three in four changes can go out over the air

Solution

The app

The app opens on a feed of events for the cities you pick, with filters for date, category and type. Each event has its own page with directions, sharing and tickets, and each venue has a page of what is on there.

You can save events and get one reminder at nine the morning before, scheduled on the phone itself. There are no accounts.

The pipeline

Nine stages run in order. Each one reads the previous stage's table in the database and writes its own. Pages are re-fetched and checked for change, a model extracts events with evidence, rules and a model classify them, and anything outside the region is held for review.

A weekly event is stored once and expanded into dates when the app asks for them. Rejected dates are written into the series as exceptions, so they stay gone.

The triage centre

Staff review everything in one queue, whatever the source. Cards are grouped into new today and still waiting from earlier.

Approve and reject act at once, with an eight-second undo. A recurring series shows as one card. An event held for a missing venue comes with a suggested match and a one-click fix.

The review queue on staging: one list for every source, grouped under New today. Held events come with a suggested venue and a one-click add and assign.

Analytics

The analytics page puts the business numbers first: daily and monthly active devices, new devices, sessions, and which events and places people open, save and click through to tickets. It also counts store click-throughs from the website, by where on the page they came from.

It does this without accounts. Each device has a random ID that is not tied to a person, location is reduced to a city on the phone, and search terms are never logged.

Analytics on staging: the Right now band, the selected date range and daily active users.

Health monitoring

For nine days in September the pipeline reported success while every extraction call was failing. Runs now have a third state, degraded, for a run that finished but hit a problem.

The health page shows how much staff still decide by hand, what was published, duplicate rows, what is waiting and why, extraction by run, and pages that have gone quiet.

Pipeline health on staging: the share of rows decided by staff, published, duplicated and waiting for review, with weekly trends below.

The pipeline page shows each schedule, the run in progress and recent runs, with degraded runs flagged.

The pipeline page on staging: each schedule with its frequency, time zone and a Run now button.

For the app, health is the release process: 270 automated tests, ten scripted flows on real builds, and a guard that refuses to publish an update no installed build could receive.

Outcome

Live on the App Store and Google Play
Five app releases since the first store version in August 2026
About 20 backend promotions to production between June and October
False approvals cut from 304 to 177 in a two-week replay
270 automated tests in the app and 331 in the staff tools
About three in four changes ship over the air, in roughly three minutes

Figures are as of October 2026.

Discuss this case study with you?

I'd be happy to walk through this project in more detail and discuss how this approach might apply to your needs.

Set up a call (opens in a new tab) Contact me