Designing a nature-diary app, and building it with AI in the loop.

01 · The challenge

A nature diary for people who love “their patch” but who aren’t he expert already. And a test of whether a designer who isn’t a developer can ship real software.

Most garden apps are built for the already knowledgeable and most nature-recording tools are built from an academic perspective. Brae is for neither. It’s ultimate user is the dabbler: someone who wants to find some joy in their own patch of the world, notice what it’s doing through the year, and keep a record they’re fond of. Someone who doesn’t know the Latin names, doesn’t have a watering schedule, and doesn’t want the sense that they’re failing a course they never enrolled on. The product itself is built around a folkloric hillside spirit, called Brae, who sends the prompts, notices what’s early or late, and keeps the gardener quiet company.

The work carries a second challenge, for me. I’m a service designer and strategist, not a developer. Brae is a test of whether someone who is good at the thinking — the proposition, the flows, the voice, the ethics of the data — can carry a real, shippable product onto people’s phones with AI doing the engineering, and keep the judgment that matters on the human side of the line. Or perhaps less of a test, more of a “when does this break (right now)”

Braes mission is to build a citizen science lens that can track how real people, in real conditions are observing the changing timings, needs and success of gardens across the UK. In a world where we’re constantly told by influencers that their established, cottage garden roses are already in full bloom, and comparing them to our newly planted, new-build soil fed ones I think a lot of reassurance and information will come from this reality-powered lens.

02 · The approach

Maintain scope (stay strong against the drift), a single voice across every surface, and AI as the build partner.

The first discipline was elimination. The temptation in a personal project is to build everything; the work was deciding what not to make. Tasks, garden-design tools, year-on-year comparison views are so attractive, but don’t test the core value of the proposition. I’ve initially focused on a single test: a weekly Walk-About prompt and the diary it feeds, “My Garden’s Story”. Though this has and nothing that doesn’t earn its place in it.

The second was voice. Brae is the only voice across the whole app — prompts, acknowledgements, empty states, errors, the lot. It’s pithy and a little strange (potentially a little reflective of self), rooted in landscape and weather and birds, and it never tips into the corporate softness it’s so tempting to default to. aka; no buzzwords, no phenological words and a lot of personality.

The third was the build itself. Brae runs on a standard, near-free stack and is built with AI carrying the code under my direction, with my partner — a data scientist and ML engeneer — as the first user (and occasional code reviewer). Where AI touches the product surface, it does so on tight reins: a plant-taxonomy step where the model proposes and a human approves, never auto-promoting a name; photo identification that offers a confident guess, a shortlist, or an honest “can’t say” rather than ever inventing a plant; and a quiet behind-the-scenes request to a real gardener when a photo stumps it. The leverage is real; the judgment stays put.

03 · What the work has produced (so far)

A working beta built around one loop, designed for the least confident person who’ll use it.

The product is a phenological observation app that doesn’t feel like one. A gardener makes a note like a first flower, a returning blackbird, slug damage, and Brae acknowledges it, sometimes remarking on how this sits against the default expectation: earlier, later abotu on time. Over time the diary becomes a record worth keeping rather than another to-do list. Brae also gives you a break down, at the garden level, or at the individual plant level of what it expects to see in the near future: buds next week, full flower in a month or so. Enough to give the user a sense of the future, without making it feel like a deadline.

04 · Outcomes

Heading toward an autumn 2026 beta — on real phones, including the ones that matter most.

Brae is a working beta heading to a small, patient circle for autumn 2026: my partner as the rigorous first user, my mum as the iPhone canary, and ten or so friends chosen for a deliberate spread of garden sizes. It’s pre-launch by design — the point of this stage is to learn from real gardens, not to chase numbers — so the honest outcome today is a built product and a set of design decisions I’d defend, rather than a metrics story.

The longer arc is deliberately left room: the architecture supports year-on-year comparison and, eventually, a printed almanac of local phenological predictions, without any of that being built before the core loop has earned it.

05 · My role

I own the proposition, the user flows, the brand, Brae’s voice, and the design decisions end to end. The code is written with AI under my direction; my partner reviews it and is the first user. The calls that decide whether the product is any good — what stays out of scope, how Brae speaks, what the data does and doesn’t claim — are mine.

There is no one else to blame for this one!

06 · Reflection

The thesis from the rest of my practice, tested on myself.

My starting position is that as AI compresses the cost of building, the cost of building the wrong thing well goes up. So the design judgment matters more, not less. Brae is where I hold myself to that claim. The risks in AI-assisted software are specific and seductive: the fabricated plant name that sticks because the user won’t know to correct it, the scope that sprawls because adding a feature is suddenly cheap, the voice that flattens to default because the model finds default easy. Holding those lines (and holding myself) of honest data, ruthless scope, a spirit that actually sounds like someone — continues to be the real work.