Skip to content
Julien Fleuridas
FR — Passer en français
← All projects

Product · Development

DayBrief

A weather app that only speaks when it is useful: one message in the evening, and a correction if the forecast really changes.

PrototypeAugust 2026 — ongoingPersonal project

In short

Problem
Weather apps show everything they know, and it is up to each person to find what matters to them. People open them often and remember little.
Solution
One message in the evening about tomorrow, then one correction only if the forecast really changes. Fixed rules decide what is worth saying, without ever overstating certainty.
What it brings
No need to check the weather: if there is something worth knowing, you get it. Otherwise, the app stays quiet.
Where it stands
Prototype. The app runs in demo mode and its 420 tests pass, but it is not published and notifications have not been tested in real conditions.
My role
I defined the promise, the five rules, the thresholds and what the tests had to prove. The code was written with assistants, under my direction.

The problem

A weather app shows everything it knows: hourly temperature, wind, humidity, pressure. It is up to each person to sort through it and work out what matters for tomorrow. People open it often and remember little.

The idea

No need to check the weather. If there is something worth knowing, we will tell you.

Every evening, at a chosen time, one message about tomorrow. Then the app keeps an eye on the forecast: if something important changes, it sends one correction that says what changed. Otherwise it stays quiet. And if tomorrow is an ordinary day, it simply says so.

The five rules

  1. What matters, not everything. Data is not shown just because it exists. Normal wind is never mentioned.
  2. No fake precision. Having hourly data does not mean knowing the weather to the hour. The message talks about "late in the day".
  3. No AI makes up the weather. The message is built from fixed rules and sentences written in advance. Nothing can be invented.
  4. Quiet by default. One message in the evening, at most one correction, never a notification just to bring the user back.
  5. Never surer than the data. Depending on confidence, the message says "expected", "likely", "possible" or "uncertain".

The third one matters most. Generative AI would have made the message more fluent, but it could, one evening, have announced rain that does not exist. For an app that rests entirely on trust, that risk is not worth it.

Where it stands

All 420 tests pass, including reference tests that fail as soon as a rule changes. However, the app is not published, and sending notifications has not been tested in real conditions. It is a prototype.

Numbers

420

automated tests passing

the weather engine and the screens, across 22 test suites

Source · npx jest, run on 30 September 2026

What I did

  • Product design

    I set the promise and the five rules that settle every choice: say what matters, never fake precision, stay quiet by default.

  • Rule design

    I defined the thresholds: normal wind is never mentioned, a one-degree change never deserves a message.

  • Needs definition

    I wrote down how everything works, from the evening message to the decision to send, or not, a correction.

  • Testing

    I had reference tests written that fail as soon as a rule changes.

  • Assisted development

    The app and its engine were built with coding assistants.

Evidence

  • 420 tests passing

    verified

    The weather engine and the screens are covered by tests, some of which check what the message says, and what it must not say.

    Source
    the repository's test suite
    Verify with
    Full run on 30 September 2026: 22 suites, 420 tests passing.

  • No AI makes up the weather

    verified

    The message is built from fixed rules and sentences written in advance. Nothing can be invented, each message costs almost nothing, and the same data always gives the same result.

    Source
    the repository's architecture documentation
    Verify with
    Read the architecture and processing pipeline.

  • Written rules, easy to adjust

    verified

    Every threshold (wind, temperature, rain) is defined in one place. Changing it makes a test fail: no change goes unnoticed.

    Source
    product rules documentation
    Verify with
    Read the product rules and the thresholds file.

Limitations

  • Not yet published on the App Store or Google Play, and no users for now.
  • Notifications sent from the server have not been tested in real conditions.
  • The thresholds are product choices to be tested, not weather truths.
  • The code was written with assistants: what this project shows is the design of the product and its rules, not React Native expertise.
  • The code is private, so it cannot be browsed from this site.

What I take away

  • Choosing not to use generative AI is also a product decision. When all the value rests on trust, one invented sentence costs more than it brings.
  • Deciding what not to say takes more rules than deciding what to say.

What it could bring to a company

  • Any customer notification (delivery, invoice, alert) benefits from the same rule: one message when there is something to say, one correction, otherwise nothing.
  • Separating the rules that decide from the way things are said applies to any product where a mistake costs trust.

Technologies

  • React Native
  • Expo
  • TypeScript
  • Supabase
  • PostgreSQL
  • Open-Meteo
  • Zod
  • Jest