Skip to content
Sunset Beach, NC
Get Support

How Sunset Beach is built

Sunset Beach, NC tells you whether now is a good time to go to the beach, and why. It draws on more than 20 public data sources, from ocean buoys and tide gauges to the pier’s fishing report, refreshed every five minutes and turned into hourly scores for this one beach. The app shows no ads, needs no account and does no tracking.

This page follows the How it’s built screen, which you open with the How it’s built button on the NeuralConfig card on the More tab. The screen is written for two readers. Each section says what happens in plain words, and an Under the hood note under it gives the technical version. Both are always visible.

The four tiles at the top of the screen:

TileCaption
20+public data sources
5 minbetween refreshes
14AI models tested before choosing one
0ads, accounts or tracking
every 5 minutesMore than 20 public datasourcesNOAA · NWS · USGS · NCDEQ · Open-Meteo · eBird ·iNaturalist · and moreOne Cloudflare Workergathers, checks, scores andpublishesAppWidgetsLaunch countdownAlerts

Three steps, as the screen numbers them:

  1. Gather. Every five minutes, a small program in the cloud collects the latest forecasts, tides, buoy readings, alerts, wildlife sightings and events. Under the hood: a Cloudflare Worker on a cron trigger, with source adapters that each have their own cache, timeout and last-good fallback.
  2. Check and score. A response that arrives broken is rejected, and the last good reading stays. Then swimming, surfing, shelling and sunset watching are scored for every hour of the day. Under the hood: each score starts at 50 and adds or subtracts listed factors; some conditions cap it outright, like swimming after dark. Sun, moon and launch sightlines are computed on the server.
  3. Deliver. One result feeds the app, the home-screen widgets, the lock-screen launch countdown and alerts, so they all show the same thing. Under the hood: published once to KV and served with ETag revalidation; push through APNs from a shared sender; a native SwiftUI app with WidgetKit, ActivityKit and App Intents.

None of the app, the widgets or the alerts fetch from the upstream sources themselves. The full list of sources is on Where every number comes from, and the scoring, with every threshold, is on How the app judges things.

The screen’s heading for this is “AI writes the words. Code checks the facts.” A strip of three boxes shows the order: code works out the figures, Claude writes the summary, code checks every number.

Claude writes the headline and the one-line summary at the top of Today, working only from figures the app has already calculated. Before anything is shown, code checks every number and time in it against those figures. If one doesn’t match, you see a plain template instead.

Every score and every computed time in the app is calculated by code, not by a model. Readings come straight from the sources.

Under the hood: Claude Haiku 5.5, with gpt-oss-120b on Workers AI as the fallback and a template as the last resort. Every draft is checked against the data, and the summary is rewritten when the facts change.

The summary is written by a model, but only from facts the Worker has already computed, and every draft is checked before anyone sees it:

  1. Claude Haiku 5.5 writes first.
  2. If that call fails, or its draft fails the check, gpt-oss-120b on Cloudflare Workers AI gets the same prompt.
  3. If that fails too, a template built directly from the facts is shown.

The check compares every number and time in the draft with the facts it was written from. A model can only change the wording, never a fact. A draft is kept while it still matches the current facts. It is rewritten at most once an hour when the facts change, and at most every 15 minutes when the facts have moved out from under it (for example, the tide height it quoted has changed). The full list of what the check rejects is on How the app judges things.

Under the heading Chosen by testing, the screen says: “Fourteen models each summarized 30 recorded beach days, twice. Three got every fact right all 60 times. Claude Haiku 5.5 is the one in use, with gpt-oss-120b as the backup.” Its table keeps the rows that explain the choice — the model in use, its backup, and faster models that didn’t get the facts right often enough:

ModelRoleFacts rightSpeed
Claude Haiku 5.5In use60/603.9 s
gpt-oss-120bBackup, on Workers AI60/6010.2 s
Claude Sonnet 5.5—60/603.9 s
Llama 3.3 70B—56/601.0 s
Llama 3.1 8B—43/602.8 s

Facts right means every number and time in the summary matched the data. Speed is the median time to write one summary.

  • It shows its working. Tap any score to see what raised or lowered it. Every score starts at 50, and the listed factors add up to it.
  • The best hour, not just the best day. Each activity is scored hour by hour, so the app can tell you when to go, not only whether to.
  • Gaps are listed, not hidden. No wave sensor exists at this beach, so surf height is a forecast and labelled as one. More › Known gaps lists everything else the app can’t measure.
  • Nothing tracks you. No accounts, ads or tracking. If you turn on alerts or follow a launch, a notification token is the only thing that leaves your phone. The details are on Privacy.
  • When a source fails, the app keeps showing the last good reading and marks it Cached, instead of going blank. See How fresh the data is.
  • Tested in two time zones. Every proposed change is tested under two time zones, which catches the off-by-an-hour mistakes daylight saving time causes.
  • A broken source sends an email. If a source stays broken, an alert email goes to NeuralConfig, so it gets fixed instead of quietly going stale.

Under the hood: CI on every pull request, run under UTC and America/New_York. Per-source health in every payload, with alerting on top.

The screen ends with “Designed and built by NeuralConfig.” and a neuralconfig.com link, which opens NeuralConfig’s services page in Safari.