How we built Plens, from idea to app

What is Plens?

Plens is an app that tells you when to leave to stay driest. You enter your route and how much earlier or later you can go, and Plens works out along the whole route where the rain will be at the moment you pass each point. The web version and links to the app are on plensapp.nl⁠↗.

The question behind the product sits at the top of the web repo's README: if I cycle from A to B around my usual time, when should I leave to get as little rain as possible on the way? Cycling came first. Plens now also works for running and walking, and there is the Plensradar: the showers over the Netherlands and Belgium, plus a five-minute-by-five-minute view of whether it will rain where you are over the next two hours. The radar and the departure advice work without an account.

Plens is one of Studio Northstar's products. Its current status is on the Plens product page. This article is about how it was built. The technology itself, from KNMI radar to address lookup, is covered in the tech behind Plens.

What problem does Plens solve?

A weather forecast covers one place and one hour. Your ride covers twenty places in twenty minutes. Plens looks at the rain on each stretch of your route at the moment you are there, so a shower that only hits the last kilometre still counts.

Hourly data is too coarse for that. A shower from ten past eight to half past disappears in an hourly average, and that is exactly the shower that decides whether you arrive dry. So Plens uses the radar forecast from KNMI, the Dutch national weather service, in five-minute steps on a one-kilometre grid.

According to the same README, success means you never open the app. Your phone says “leave ten minutes earlier” on its own, and that is all you need. By default, notifications only arrive when the advice changes. And sometimes every departure is wet. Plens says so too: a message that rain can't be avoided arrived in the test build of 10 October.

How did we start?

We started with the data source, not the screen. How far ahead the radar can see decides what departure advice Plens can give, and that became the scope.

The KNMI radar forecast looks two hours ahead. That covers a commute but not a day plan. The first half hour is the most accurate, after which the forecast gets coarser. The scoring model rates reliability as high up to 35 minutes of lead time, medium up to two hours and low after that, citing verification studies of radar forecasts over the Netherlands. That is why Plens states how certain each piece of advice is.

Choosing the sources started as research too. In August 2026 the team recorded, per source, what was technically possible and what was legally allowed, and the licence often decided it. The KNMI radar is published under CC BY 4.0 and may be used commercially. Another radar source was only open for personal and educational use, so it dropped out. For route planners the question was whether you may store a route. A commute rarely changes, so you want to plan it once and reuse it, and many providers forbid exactly that.

That is how we start every product: first research into what it should deliver and where the limits are, then building.

How did we build it with agents?

Plens was built by one builder running several AI agents side by side. Almost every commit in both repos is in the name of Alan Abdulla, co-founder of Studio Northstar, who worked with Claude Code, Codex and Cursor. Niels Vermaat has twelve commits in the web repo. Melle Doreleijers decides on privacy and on the public release.

The timeline

From the first web commit to the test build of 10 October took about six weeks. From the first app commit to the closed Play test, eleven days.

The size

As of 11 October 2026, the web repo has 1,286 commits and 604 merged pull requests, the app repo 684 commits and 202 merged pull requests. In the app repo, 397 of the 684 commits carry a Co-Authored-By line for Claude. Those numbers say something about pace, not quality. A commit can be a comma or a whole feature.

The app did not just happen. The architecture decision of 21 September weighed four options on criteria such as maintenance by a small team, push and deep links, and app store quality. Expo and React Native scored 157 points, two fully native apps 106, a web wrapper 104 and a web app on its own 92. The decision also set limits, such as no provider key or other secret in the app bundle.

Who did what

Each agent had its own kind of work. According to the roadmap, Cursor set up the first scaffold. Codex handled the parity register, the architecture decision, the Android widgets and the store records. Claude Code built the mobile API, the native foundation, push notifications, in-app purchases and the compliance work.

Sessions ran at the same time, in the cloud and on the Mac. To avoid collisions, each session registers its branch on a work board. The board also shows which files change in more than one open branch, described as a merge conflict in the making. Cloud sessions run without secrets. An iOS simulator, EAS builds and store publishing are not possible there, so that work moves to the Mac.

Every change starts with a product change record: a small JSON file stating what changes and why. That way it does not matter which session picks up the change. The app also stores the commit, manifest hash and OpenAPI hash of the web core. If web and app drift apart, CI fails.

Review first, then build

The brief for Claude Code started with reviewing, not building: first take a critical look at what Codex had already built, then improve it in small, demonstrable vertical build loops. On 24 September an independent review went through the app, with separate read-only agents. The first blocking finding was that the entire app lived in a single 317-line file, with no deep links. Thirteen build loops followed that same day, from the foundation to buying Pro in the app.

Plens used our own platform, ARCS, selectively. The brief says ARCS checks are only used where they improve a concrete decision or the evidence of quality.

At the end of the chain, Claude also ships: making builds, submitting them to Apple and Google and setting test notes, each time only after Alan's go. On 10 October Claude published the Android build that Google had approved for the closed test.

What went wrong, and what did we learn?

Most things went wrong outside the code: in builds, in the app stores and in the gap between a successful build and an app that works on a phone. The team wrote the lessons down in its handover documents. Six of them:

1. New iOS capabilities break the build. When Sign in with Apple and Associated Domains were added, the EAS build failed until Alan ran one interactive build with his own Apple login. Now app.json is checked before a build, and such changes are flagged in advance.
2. An env change in Vercel only applies after a deploy. Claude does not deploy to production itself. A small merge in the web repo triggers the deploy instead of Alan redeploying by hand.
3. Product records are append-only. What is recorded stays as it is. You add a new record, so it remains clear who decided what.
4. A native build never uses sample data. Registering on the Android emulator accidentally created a real account on 5 October.
5. Don't open other Play edits during a submission. The Android submission of version 0.14.0 got stuck because a home-made check loop opened a Play edit every 30 seconds, which made the submission's own edit expire. The build then went straight through the Google Play API.
6. A claim is not proof. The documentation said Siri would work on the Apple Watch. That turned out to be wrong. The Watch app is deliberately not built yet, Alan decided on 28 September.

The common thread is proof. The brief puts it plainly: don't claim device proof on the basis of a successful bundle or EAS build. A build that succeeds tells you nothing about whether the app does its job on a phone. That is why every feature sits in a parity register, per platform, and only counts once it has been proven on a real device.

Where does Plens stand now?

Plens is available. The web version runs on plensapp.nl⁠↗, and since 10 October the app has been at version 0.16.3 with testers: on iOS in TestFlight, on Android in a closed test that Google approved. There is deliberately no version 1.0 yet. On 9 October Alan decided to work through the TestFlight feedback first.

The app only goes public once every rule in the parity register is proven on both iOS and Android and Melle signs off. On 30 September the release check showed 106 open conditions: 49 product rules times two platforms, plus eight release conditions. The release document itself adds that this is not a list of 106 separate bugs.

Plens is free to use; Plens Pro adds running, walking and more routes, among other things (pricing on plensapp.nl⁠↗). The next milestone on our product page is a pilot with commuters. After that comes operating it: we take our own products to market ourselves, which shows us how they hold up in daily use.

Is Plens the only app that does this?

No. Dutch apps that give rain advice for your route, with a notification, already exist. The team wrote that down itself in the README, under the heading about what sets Plens apart:

In English: honestly, less than we thought at the start.

What Plens does is calculate with the KNMI radar forecast in five-minute steps on a one-kilometre grid, per stretch of route at the moment you are there, and state how certain each piece of advice is. Whether that makes a difference for your rides is easiest to find out by using it next to your usual routine for a week.

What to take away if you want to build an app

Building an app with AI goes fast once you have pinned down what you are building and how you will prove it works. Three things from Plens come back in every project we do.

• Start with the constraint. The radar decided what Plens could promise. Design the screens first and you discover that limit later.
• Record decisions where agents read them. An architecture decision, product records and a work board make sure one session knows what another did.
• Separate building from proving. A successful build is not a working app. Device proof per platform and an independent review belong inside the process, not after it.

If you want an app built this way, read how we approach agentic engineering, or get in touch.

You can try Plens without an account: the Plensradar and the departure advice are on plensapp.nl⁠↗.