If I built it right, it interrupts you only when you'd want it to.

The app sits between two categories that already exist and are well served. Weather apps tell you what the sky is doing today and tomorrow. Navigation apps tell you how to get somewhere. Both are utilities brought to bear in all kinds of contexts. Neither one by itself tells a person asleep in a camper-van at the end of a forest road that the storm brewing ninety miles west is coming for the road they planned to leave on.

There are excellent tools out there for people who dig planning: the ones who carry a laptop out to the picnic table and spend an hour mapping routes around every front. I didn't build this to compete with them. Heck, we use a lot of the same data feeds. Storm Recon is for offline time, when you're in the hammock, or out on the water with the kids, and weather is the last thing on your mind. It's built to stay put away until it needs you. And if it buzzes your phone in the middle of the night or while you're fishing, it had better be good.

My goal was to create a "situational awareness engine" aimed at a specific problem facing campers, van-lifers, digital nomads and generally anyone who sleeps in a portable home — built on top of the utilities and data sources that already exist. Storm Recon watches what's around your position and your route, decides whether it matters to you specifically, and advises you what to do about it.

It doesn't follow you down the road. It doesn't track you at all. When you make camp, launch the app which tells it "I'm here now," then quit and put the phone down. That's it. Make it part of your camp checklist; the same way you'd level the rig or chock the wheels. From then on Storm Recon watches that spot and the ways out of it, and you hear from it for two reasons only: something you asked to know about, or something you need to know about.

As an aspiring digital nomad myself, hail damage to the rig is a very real concern, and the only solution I could find involved staying hyper-alert and overly focused on weather, forecasts and escape routes. All the tools existed to build an automated solution, so I decided to build the one I would use myself.

I started it on May 5th, 2026. One person, one freshly-minted LLC, a brand-new $20 Claude Plus account I had never used, no investors, no deadline...just an idea.

It was originally called First Mate. It would be the Gilligan to your Skipper — your "little buddy", always there when you needed him, focused on one important job. As it turns out, not only was the name taken, but in retrospect Gilligan had one job and was terrible at it. He disabled the S.S. Minnow and stranded the whole lot of them for years. No wonder Skipper always smacked the hell out of him with his hat. Premonitions of calamity before you've even tried the app wasn't the brand association bump one looks to evoke with a name.

Back to the drawing board: you're on the lookout for weather threats ahead, you're aware of your location and some route options, and you're good at figuring out how seriously to take a posted official alert if you study it. Storm Recon: Situational Awareness came out of that.

The last mile wasn't finishing the build

I expected the end of this to be a feature list I dutifully checked off. It wasn't. Most of the last stretch involved taking things out.

There are four tenets I drive into most things I build:

They're easy to instill early, when nothing exists and everything is cheap. They're expensive to implement at the end, because by then the thing you're about to hack apart is built and works.

Storm Recon failed my second tenet badly. An app about environmental threats has a natural gravity toward telling you everything it knows, immediately, every time it learns something. Like that know-it-all in third grade whose hand shot up for every question. That's not situational awareness. That's another feed to check, on a phone that already has too many, carried by someone who went camping specifically to stop checking things. The first builds were great at crying wolf. Unfortunately, they also cried bear, coyote, squirrel, giraffe and freaking spider monkey.

An alert going out over the wire didn't automatically earn an interruption. So the temperature is going up or down, big deal. Tough it out. Don't light up my phone about it. I started to become my dad, wanting to tell the app to man up and rub some dirt on it.

The part of the app you never see is the part that took the most work. It takes a lot to teach your app to shut up and stop pestering people, and that's what most of the work was about — keeping the phone in your pocket until you really need to see something. An app you hope nobody ever gets prompted to open? Awesome. Sounds like a winner.

There's a lot of data coming in, and it can't all be equally important. That's where the logic engine started doing real work: deciding what mattered, what merited an alert, and what kind of alert. What form it took. Update quietly or buzz the phone? A badge on the app icon? A push notification? Should it break through Do Not Disturb, or, worst case, fire off a critical alert with that shrieking sound reserved for Amber Alerts and dire threats?

All of that had to be worked out by studying the alerts, looking at the context around them, and understanding location, direction, severity and patterns — none of which reading a single alert from one source will tell you. Get it wrong once and it costs you confidence. Get it wrong a lot and it's an uninstall. Get it wrong for an influencer and they'll tell all 600,000 of their viewers your app is garbage. And get it wrong for the one person who ignores a warning they shouldn't have, and it costs them a lot more than that.

So yeah — 80% of the work you'll never see.

The thing that nearly didn't make it

Wildfire.

It matters more to this audience than anything else the app tracks, and it is the worst served by the data. Rain, wind, hail, temperature — those arrive as clean feeds you can subscribe to. Fire doesn't. It doesn't even count as "weather." There was no source to plug in, which meant either building detection out of signals that weren't designed for it, or shipping a situational awareness product that goes blank on the situation that scares people most.

I built it. Then I had to prove it worked, and that turned out to be harder than the detection.

You can't grade a system like this against what actually happened, because what actually happened contains information the app would never have had at the time. Check it against the outcome and every model looks brilliant. So the testing had to replay historical fires as a sequence of partial states: reconstruct what was knowable at 6am, ask the app what it would have said at 6am, and score that. Then 7am. The shortcut is available at every single step, and it always makes the numbers better.

That process is also how I found the worst bug in the product: the app returned ALL CLEAR for a position inside a Level 3 evacuation zone. I wrote that one up in full back in August — "You Shouldn't Hear Crickets During a Wildfire" — rather than fixing it quietly and moving on, because a life-safety product that only publishes its wins isn't worth much. I don't answer to skittish investors who worry about airing flaws. It's just me. If something's broke, I fix it right, even if it costs another few weeks of testing and tuning logic.

Why it wasn't faster

No boss, no investors, no board deadline, no launch deadline. Nobody was waiting on this but me.

That's usually described as the luxury version of building something, and it kind of is, but it's also the reason the last mile kept pushing out. Every external deadline I've worked to in thirty years arrives with a built-in argument for shipping the thing you have instead of the thing you meant to build. Take the deadline away and that argument disappears. What's left is you, deciding when it's done, with nobody to blame for the date.

The usual culprit when something takes longer than planned is our old nemesis, scope creep. On this project I did add functionality along the way — wildfire — but the real creep came from the logic engine, and the refinements it kept demanding. It had to be smarter. Then smarter still. Test after test after test, grading the results, making corrections, and seeing how it performed against live conditions and real-world scenarios replayed from the archive. We jumped on breaking news. Wildfires in Oregon? Floods in Indiana? We dropped pins on actual local campgrounds, ran the test harnesses live, and scored and improved as events unfolded.

That work, again, will never show up as pixels on a screen. But when this app asks for your attention, know that there's good reasoning behind it.

I don't recommend this approach for all app development. It was right for this one.

What I don't know yet

The target user for this project is someone who wants to protect their tiny home on wheels from incoming natural threats. Over the course of testing, I had one friend on a boat who was interested in maritime conditions and escape routes over water. I have others in Los Angeles who were affected by the Palisades fire and have homes in high-risk areas. Maybe there's a wider need for an app like this outside the digital nomad community.

The only way I'll find out is if you use it and tell me. The About screen has a contact link that comes straight to me.

Storm Recon is now available on the App Store.

Most of what you just read about is work you will never see but know it's there, which is an odd thing to ask people to pay for. People pay to see magic shows that do the same thing. I personally think the app's situational awareness engine is pretty magical. Regular price is $9.99. It's $1.99 (80% off) for the first 90 days — a small price to pay to take a problem off your plate that makes road-life better.

Built by one person at Bacon Cheese Frosting LLC. I posted several behind-the-scenes accounts of development and testing here: