Stories

The second product is found by operating the first

A forecast engine built to put wind on a cycling route turned out to be most of what runners needed, pointed at a different problem. Not a pivot and not a feature — a sister product, on one engine, for an enemy that is not wind.

RunFast Windline

Summary

  • Running a product in production surfaces the next problem more reliably than planning does. Windline did exactly that.
  • Riders also run, the running population is far larger, and a runner’s day is not decided by wind. At running pace there is almost no cooling airflow, so heat, humidity and dew point decide everything.
  • The forecast engine already existed. Retuned for running pace it became RunFast — the heat timed to each kilometre of your own route, at the hour you reach it.
  • They are sisters, not a parent and a child. One engine, two enemies, neither product built on top of the other.

What operating a product tells you

The useful thing about running software in production is not the feedback form. It is that a working product puts you in a room with people who have an adjacent problem you were not looking for, and keeps you there long enough to notice.

Windline forecasts wind along a cycling route — it reads the bearing of every stretch, works out when the group reaches each one, and reports headwind rather than a compass direction. Operating it surfaced three facts in order: a large share of those riders also run, the running population is considerably larger than the cycling one, and running has nothing like the same relationship with wind.

A roadmap is a guess about what matters. An operating product is a standing instrument for finding out.

Wind is the cyclist’s enemy. Heat is the runner’s.

A cyclist at 25 km/h generates a constant stream of moving air. That airflow does two jobs: it resists you, which is why wind direction decides a ride, and it cools you, which is why heat is survivable at speed.

A runner has neither. At running pace there is almost no cooling airflow, so the body loses heat by evaporation and little else — and whether evaporation works depends on how much moisture the air can still take. That is why dew point, not temperature, is the number that ruins a race.

So the same day is two different days. For a rider it is a question of which direction the wind is coming from. For a runner it is a question of whether the air can still take sweat, and the honest answer changes hour by hour as the day warms up.

What nothing else was doing

The gap was specific rather than general. Weather for runners exists; weather timed to a runner does not.

  • Race tools cover famous courses — useful if you are running one of perhaps forty events in the world, useless for the route outside your door.
  • Pace calculators take a single temperature for an entire run, which is a reasonable approximation for forty minutes and nonsense across four hours of a warming morning.
  • Route-weather tools are built around cycling speeds, so they resolve in kilometres per hour and think the interesting variable is wind.

None of them answers the actual question, which is what it will feel like at your pace at kilometre 31 at the hour you get there.

Retuning an engine rather than building one

What made this a fortnight’s work rather than a year’s is that the hard part was already solved. Walking a route in time, resolving conditions to a point and an hour, blending between model readings — that machinery does not care whether the thing moving along the line has two wheels or two legs.

What it cared about was speed, and the assumptions underneath it. Pace is now handled in minutes and seconds per kilometre or mile, in five-second steps, from 2:30 to 15:00. That upper bound is deliberate and it is the detail that says who the product is for: at 15:00/km a run-walker finishing Comrades in twelve hours is timed as precisely as somebody at the front, which is not true of tools that assume everyone is fast.

The output changed too. Rather than a number to interpret, RunFast states the weather cost — how many minutes the conditions will take off you. A forecast becomes a pacing decision.

Why the followers matter more than the runners

The part that will probably decide whether RunFast is bigger than Windline has nothing to do with forecasting.

Runners race in mass events. Comrades alone has twenty thousand runners, and behind each of them is a small group of people at home who want to know where they are. A runner sets a goal, taps go live, and shares one link: followers see position, pace and projected finish against that goal on a map, with no app and no account.

Those followers can send a tap on the back, and the runner feels it mid-race. Which means every follower is a non-runner meeting the product on the day it matters most to somebody they care about — and a good share of them run, or will. The runner shares a link; the followers become the next runners and the next clubs. Cycling has no equivalent of this, because cycling has no Comrades.

Sisters, not a parent and a child

It would be easy, and wrong, to describe RunFast as Windline for runners. The products share a forecast engine, a Strava connection and a live-tracking server, and neither is built on top of the other. RunFast is not a Windline feature and not a product by Windline; the engine is common infrastructure and both are equal consumers of it.

That arrangement is also the test. Shared infrastructure that genuinely generalises can carry a second product without either one bending around the other, and one engine means the numbers are identical wherever they appear — a correction to either improves both. If it had needed forking, the engine was never general; it would just have been Windline with a different label.

RunFast launches for the 2027 season — Two Oceans in April, Comrades in June — and waits on no race organiser to list a course. It is free, with ProLend as headline sponsor in South Africa, and it carries its own December challenge, the RunFast 200: 200 km between 16 and 31 December, counted from Strava.

Running through a summer?

RunFast is free, and the web app needs no download.

Questions people ask

How does heat affect running pace?
At running speed there is very little cooling airflow, so the body sheds heat mainly by evaporating sweat — and that depends on how much moisture the air can still absorb. Dew point therefore matters more than temperature, and a humid 24°C can cost a runner more time than a dry 30°C. RunFast states the effect as a weather cost in minutes rather than as a raw reading.
What is WBGT and why does it matter to runners?
Wet bulb globe temperature combines heat, humidity, radiant heat and air movement into one measure of heat stress, and it is the figure race organisers use when deciding whether conditions are dangerous. It describes what the day does to a body far better than air temperature, which is why RunFast reports it per kilometre rather than once for the whole run.
Can you get a weather forecast for a specific running route?
Yes. Add a route as GPX, FIT or TCX, import it from Strava or draw it, then give a start time and a pace. RunFast works out when you reach each kilometre and forecasts that point at that hour, so the conditions shown are the ones you will actually run in rather than the ones at the start.
How does live race tracking work for family and friends?
The runner sets a goal and taps go live on race day, then shares one link. Followers open a map showing position, pace and projected finish against that goal, with the goal itself displayed as a ghost to compare against. Nobody following needs an app or an account.
Is RunFast free?
Yes, with one account across the web app, iPhone and Android. ProLend is headline sponsor in South Africa.
Is RunFast part of Windline?
No. They are sister products that share a forecast engine, a Strava connection and a live-tracking server, both built and operated by Cross Constellation. Neither is built on top of the other, and neither is a feature of the other.

Every product named here is built and operated by Cross Constellation.


The method

Build the thing, operate it, and let it tell you what the next one is.

Read next

A thousand kilometres, counted for you
Most December challenges hand you a weekly leaderboard and leave the sum to you. The Windline 1000 counts every ride from 16 December, puts your running total on Strava, and sends a finisher card on 1 January.

Wind against the road, not the town
Every tour group chat asks the same question the night before, and the honest answer to “thirty from the west” is “at the start, or at Sutherland?” A forecast for a place cannot answer it. So we built one for a road.

When the register is the product: building a standards body that can be checked
The Private Lending Association of South Africa publishes records that tell a stranger who is real. That makes every entry a liability, every badge a claim that travels, and the door the most important thing on the site. Here is the system, and why it runs Crossdeck for analytics and Crossdeck Trust.

Building an AI assistant that cannot lie about its work
Digital Hank reported a client meeting as arranged and produced a joining link. There was no meeting, no email, and the link led nowhere. Nothing had broken — the model had done what models do. So we stopped asking it not to, and rebuilt so it cannot.

We cut a client’s application rejections by 90% — by letting the documents fill in the form
ProLend was not losing applications because the applicants were wrong. It was losing them because a human retyped what was already printed on a document, and got a digit wrong. So we stopped asking people to retype documents, and had the documents populate the profile instead.

Why we built Crossdeck — and why every product we build helps test it
We thought the App Store Connect wait was the problem. The real problem was fragmentation — the same person scattered across a dozen disconnected tools. So we put one SDK and one customer timeline underneath everything we operate.

Every product is a test environment for the one beneath it
A habit tracker on the App Store, a link-in-bio product carrying anonymous global traffic, and a book catalogue on two platforms. None of them was built to test anything. That is exactly why they work as tests.

The Firebase bill that taught us to see
A runaway Firestore read bill sent us chasing ClickHouse. The real fix was not a new database — it was being able to see where every read came from. What we learned, and why we open-sourced Buckets.

The email address you’re keying on is not the person
Why email is a fragile anchor for user identity, how keying on the wrong id forks one person into many records, and how an identity graph converges every key onto one canonical customer.

We got our connector rejected. It was the best product spec we received all year.
A marketplace review rejected our connector with roughly a dozen findings. Instead of a failure, it read like a spec — the exact definition of a production-grade third-party integration we would never have written ourselves.

The black box blinks: seeing App Review happen in your own data
App Review is a black box. Identity-joined session data reveals when a reviewer starts testing your build, where they connect from, and the exact path they walk — plus the line we will not cross.

Why Biotree needed Crossdeck Trust — and how we stopped the SEO spam farms
Public, indexed link-in-bio pages are a magnet for spam farms and bot signups. The attack Biotree faced, why the obvious defences backfire, and the signup firewall that stopped it without punishing real users.

Why we are building Crossdeck Sales
Cold outbound is miserable because the seller is blind. We were not — we already saw who landed, what they read, and why. So we are building the tool that turns that journey into outreach that lands.