Stalefish Labs

The Group Chat Had It Right: Why I Un-Fixed Visible Picks

Michael Morrison — Tue, 31 Mar 2026 00:00:00 -0700

In a previous article, I wrote about how moving our F1 fantasy game from a text thread to an app unlocked pick categories that were too tedious to score by hand. The Overtaker pick replaced Fastest Lap in the app, and made the game better by doing things the group chat couldn’t.

This article is about the opposite: a case where building the app made me worse at game design, because I reflexively added a restriction that the group chat never needed. It was a lesson in not always doing things just because you can.

How it worked in the text thread

Our original game was dead simple. A group of friends who enjoy watching Formula One making lightweight fantasy picks for each race. It was all managed in a text thread and in Notes on my phone. You texted your picks to the group before the race started. Everyone saw everyone’s picks the moment they hit the chat. You could change your mind as many times as you wanted, right up until the formation lap. Nobody really tracked or enforced a hard deadline because the gentleman’s agreement was enough.

And here’s the thing we mostly took for granted but everyone enjoyed: you could see what your rivals picked. If you were trailing in the standings and neck-and-neck with someone, you might deliberately wait to see what they picked, and then pick a different driver for the podium to create a scoring differential. If you were leading, you might mirror a rival’s picks to protect your gap. It wasn’t chess, but it was a real layer of strategy on top of “who do you think finishes on the podium.”

Yet during several years of playing this way, almost nobody actually changed their picks strategically after submitting. The option was always there, but people mostly picked and moved on. What I learned the hard way is the strategic value wasn’t in last-second switching. It was in the information: knowing what you were up against.

What I did when I built the app

When I sat down to build Open Wheelers the app, I did what felt obvious: hide everyone’s picks until they lock. Blind picks. You submit yours, you see a checkmark next to your leaguemates’ names confirming they’ve picked, but you don’t see what they picked until the window closes and picks lock (the race start). Standard fantasy app behavior. The app suddenly gave me the power to enforce a new rule (blind picks), so why not do it?

I didn’t even really think about it too deeply. Every fantasy platform I’d ever used worked this way. Draft picks are secret. Lineup changes are private. Why would you show your poker hand a moment sooner than required? The whole model assumes that seeing someone else’s choices gives you an unfair advantage, so the system prevents it. It’s such a default assumption that I never questioned whether it was actually right for this game. And this is even given the knowledge that I deliberately set out to build a contrarian fantasy game!

What I lost

During initial testing of the appified game, something felt off. The picks phase was… quiet. You’d open the app, make your picks, close it, and wait. There was nothing to talk about until the race started and picks were revealed. The group text thread used to buzz with reactions to each other’s picks. Hot takes. Trash talk. “Lewis is struggling with Ferrari but you just can’t quit him, eh?” That energy was gone, replaced by a sterile, sealed-envelope experience.

Worse, I’d killed the strategic layer entirely. You couldn’t differentiate from a rival because you didn’t know what they picked. You couldn’t mirror someone to protect a lead because their picks were invisible. Every decision was made in a vacuum, which sounds fair but actually just makes the game shallower. Pure prediction skill is fine, but prediction skill plus situational awareness is more interesting. Indeed, sometimes ultimate fairness loses out to quality of life.

The irony is that I’d written a whole article about how the app should unlock more depth, not less. And here I was, having voluntarily removed a dimension of gameplay that the text thread gave us for free. Indeed, sometimes less is more.

The “because I could” trap

This is the trap, and I think it’s common in software: when you move something analog to digital, you inherit assumptions from existing digital products instead of examining what actually worked about the original. I looked at other fantasy apps and copied their pick visibility model without asking whether it fit our game. Which is admittedly funny because up to this point I literally looked at nothing else in fantasy F1 apps because I wanted Open Wheelers to be its own unique thing.

The group chat didn’t hide picks because it was good game design, it literally couldn’t. Messages are visible to everyone. But that constraint turned out to be a feature. It created a social, strategic experience that I then engineered away because I had the power to build walls that a text thread couldn’t.

Sometimes “because I could” is the right answer. The Overtaker category exists because the app can compute grid-to-finish deltas automatically. That’s a genuine improvement, and the gains were felt immediately. But hiding picks? That was me solving a problem that didn’t exist, importing a convention from games with different dynamics, and making the experience worse in the process. I went with effectively the software default when in reality the low-tech constraint was a winner all along.

What I changed

The fix was almost embarrassingly simple. Picks are now visible to your leaguemates the moment they’re submitted. You can still change yours freely until they lock at the start of the race, just like the text thread. No countdown timers, no change limits, no special mechanics. Just open information and the freedom to act on it.

Will some people wait to see what others pick before committing? Maybe. Will there be occasional last-minute switches and skulduggery? Probably. But years of running the text thread game proved that this mostly doesn’t happen, and when it does, it’s fun. It’s a feature, not a bug. “Did you see that she switched her podium pick 30 seconds before lights out?” is exactly the kind of story a fantasy game should generate.

The design principle

Last time, with the Overtaker change, the lesson was that the best mechanics are often the ones too complicated to run by hand. This time it’s the complement: not every analog constraint is a problem to solve. Some constraints are load-bearing walls disguised as limitations.

When you’re digitizing a game, or really any experience, the hard part isn’t adding capabilities. It’s knowing which rough edges to preserve. The text thread’s visible picks felt like a limitation of the medium. They were actually a core part of the game.

Build the features that were impossible before. But before you “fix” something that wasn’t broken, go back and play the original. The group chat might know something you forgot. Box, box.

Open Wheelers is a casual F1 and IndyCar fantasy game for friends, built by Stalefish Labs.

Building Confidence Into Uncertain Verdicts

Michael Morrison — Fri, 27 Mar 2026 00:00:00 -0700

This is the final article in the Building a Weather Decision Engine series. The previous articles covered the drying model, multi-app architecture, edge cases, and the Yardwise inversion. This last one is about the output side, how the engine communicates decisions to people who just want to know if they should go ride.

Why Not a Percentage?

The first version of the engine returned a moisture percentage. Users hated it. To be honest I kinda hated it too but it was the first logical thing to represent as meaningful output.

“Your trail is at 47% moisture” sounds precise. But what do you do with that? Is 47% rideable? It depends on the surface, your tolerance for mud, whether you care about trail damage, and how far you’re willing to drive for a “maybe.” The percentage outsources the decision to the user, which is the entire thing the app was supposed to handle. Besides, I have no idea what percentage tips me one way or the other toward making a real life ride decision.

A percentage also implies false precision. The engine’s moisture model is a reasonable approximation, not a soil sensor reading. Presenting a number with two significant digits suggests an accuracy that doesn’t exist, so it’s misleading. The difference between 47% and 49% is noise, not signal.

Three states (Yes, Maybe, No) work because they match how people actually think about the decision. You’re either going (Yes), not going (No), or weighing it (Maybe). The engine’s job is to put you in the right decision bucket, not to give you a homework problem.

The Maybe State Is the Product

The Yes and No verdicts are straightforward. The real design challenge is Maybe.

Maybe exists for conditions where reasonable people would disagree. A wetness score of 0.4 on a dirt trail means it’s damp but not muddy. Some riders would go. Others would wait. A veteran on a hardtail who likes playing the drift might like the extra challenge of some surprise slip here and there. A flowier rider on a full-suspension with less tire clearance might not want to bother and risk the occasional wet low spot. There’s also some variance in trails opening and closing based on conditions, which is another facet of where local knowledge would tip a Maybe verdict one way or the other.

The engine can’t make that call for you. What it can do is tell you why conditions are borderline, so you can apply your own judgment.

Rationale: The Why Behind the Verdict

Every assessment includes a structured rationale:

struct GroundwiseRationale {
 let headline: HeadlineReason
 let decisiveFactor: DecisiveFactor
 let headlineContext: HeadlineContext
 let details: [DetailReason]
 let values: RationaleValues
}

The headline is the one-line summary: “Light rain still drying” or “Strong drying clearing moisture” or “Frozen conditions — ice hazard.” It’s what the user reads first.

The decisive factor identifies the single most important reason for the verdict. This is the tie-breaker — the one variable that, if changed, would flip the result. “Recent heavy rain” or “weak drying conditions” or “surface sensitivity.”

The details array provides up to six contributing factors, each describing how a specific weather element is affecting conditions, either positively or negatively. Temperature is helping. Humidity is slowing things down. Wind is moderate. These aren’t ranked by importance, they’re presented as a set of forces that the user can scan to build their own picture, with the verdict-supporting forces appearing first.

The engine deliberately avoids showing the raw numbers in the rationale. Users don’t need to know that drying strength is 0.53 or that the wetness score is 0.38. They need to know “drying conditions are moderate — warm but humid.” The rationale translates numbers into plain language.

Confidence: Admitting What You Don’t Know

Each verdict has a confidence level — Low, Medium, or High. Don’t forget that we’re highly dependent on the weather source, and can’t control the occasional hiccup where a piece of key data is missing. That’s where Confidence enters the picture, and it starts at High and gets reduced by specific factors:

Missing timing data → Low confidence. If the engine doesn’t know when rain ended (the minutesSinceRainEnded value is nil), it can’t model the timing decay that’s central to the wetness calculation. It defaults to a 0.5 timing score (assume moderate concern) and drops confidence to Low. The verdict might be right, but the engine is guessing about a critical input.

Patchy rain → Medium confidence. When the weather source indicates precipitation has been spotty and inconsistent (patchyRainLikely), the actual conditions at the user’s spot might differ from what the nearest weather station recorded. The engine can’t know whether the rain hit your trail or the parking lot a mile away. These are unknown unknowns, well maybe they’re known unknowns…either way we don’t know!

Near-threshold conditions → Medium confidence. If the wetness score lands within 0.05 of a verdict boundary (0.25-0.35 near the Yes/Maybe line, or 0.55-0.65 near the Maybe/No line), the engine reduces confidence because a small change in any input could flip the result. This is the engine saying “I’m calling it Maybe, but it could easily be Yes.”

The confidence level affects how the UI presents the verdict. A High-confidence No is “Don’t ride — conditions are poor.” A Low-confidence Maybe is “Conditions are uncertain — check conditions on the ground.” Same verdict structure, different emphasis.

What I Didn’t Do With Confidence

I considered making confidence a continuous value (0-1) or adding more levels. I didn’t, for the same reason I use three verdict states instead of a percentage: more granularity creates more decisions for the user without adding useful information. The whole point here is to simplify decision making.

The three levels map to three communication strategies:

High: Trust the verdict
Medium: The verdict is our best call, but conditions might surprise you
Low: We’re short on data, verify on the ground

That’s enough to calibrate expectations without overwhelming.

Recovery Outlook: “So When Will It Be Good?”

The natural follow-up to a No or Maybe verdict is “when will conditions improve?” I was initially skeptical about including this but it has turned out to be extremely valuable because as is often the case, I’m actually not looking at the app to ride right this moment, I’m typically planning ahead for “later today.” The engine provides a recovery outlook, a qualitative time estimate, to attempt to answer.

The outlook is a simple 2D lookup: wetness score vs. drying strength.

Wetness / Drying	Strong	Moderate	Weak
Low (< 0.4)	Within hours	A few hours	Maybe later today
Medium (0.4-0.6)	A few hours	Later today	Maybe later today
High (≥ 0.6)	Later today	Maybe later today	Unlikely today

The categories are deliberately vague. “Within hours” means 1-2 hours. “Later today” means afternoon or evening. “Unlikely today” means tomorrow at the earliest. The engine doesn’t say “rideable at 2:47 PM” because that precision doesn’t exist in the model and it would be ridiculous to pretend that level of accuracy.

The “maybe later today” bucket is the uncertainty hedge — conditions might improve, but the engine isn’t confident enough to commit. It’s the recovery equivalent of the Maybe verdict.

There’s also a “may worsen” outlook for cases where the forecast indicates more precipitation. If the next few hours include rain, the engine won’t tell you things are improving, even if current drying conditions are strong. This prevents the frustrating experience of waiting for conditions to improve only to get rained on again. And this is fairly common on days where I’m pretty sure the trail is day right now but less sure of how the afternoon is going to go. In this regard, the engine isn’t just a past weather + surface conditions evaluator, it’s also taking a peek into the future (forecast) to give you a sense of if things are trending better, worse, or more of the same.

Risk Categories: More Than Just “Wet”

It occurred to me fairly quickly when building Ridewise that what we’re dealing with here isn’t just the ability to ride, as in muddy or not muddy, but also the risk implications. I’m using risk here as a two-way term depending on activity: risk to the user and in some cases risk to the surface. For a concrete skatepark, it’s entirely user risk, but for a mountain bike trail or sod soccer field, it’s risk to the surface. Actually the mountain bike example might cut both ways but you get the idea. And there’s the quality of the activity that I decided was also effectively a risk. So beyond the binary wet/dry question, the engine evaluates three distinct risk categories:

Surface damage — Will using this surface in current conditions cause lasting harm? This matters most for natural grass athletic fields (0.9 sensitivity), newly seeded lawns (up to 1.0 with establishment boost), and clay courts (0.85). It matters least for artificial turf (0.05), metal (0.05), and compost (0.3).

Activity safety — Is the surface dangerous to use? Wet metal has the highest safety sensitivity (0.95) because it becomes extremely slippery. Composite ramp surfaces like Skatelite and Ramp Armor are also high (0.85), along with metal and concrete. Artificial turf and potting mix are low (0.4) because their textures maintain grip even when wet. Indeed nobody skates on potting mix, but this illustrates how one engine can serve three different apps if you’re very careful about the design.

Activity quality — Even if it’s safe, will the experience be poor? Mud on a dirt trail (0.7 quality sensitivity) makes for a miserable ride. A damp skatepark (0.6) is more debatable, and can range from totally fine (squeegee the ramp and it may dry out) to a complete no-go.

These three risks are calculated independently and presented alongside the verdict. A Maybe verdict might come with low safety risk but high damage risk — meaning “you’d be fine riding, but you’d rut up the trail.” That distinction helps the user make an informed call.

Putting It All Together

The full assessment output:

struct GroundwiseAssessment {
 let verdict: Verdict // Yes / Maybe / No
 let confidence: Confidence // Low / Medium / High
 let rationale: GroundwiseRationale // Why
 let riskSurfaceDamage: RiskLevel // Harm to surface
 let riskActivitySafety: RiskLevel // Danger to user
 let riskActivityQuality: RiskLevel// Experience quality
 let recoveryOutlook: RecoveryOutlook? // When will it improve
}

The verdict is the headline. Confidence tells you how much to trust it. The rationale explains why. Risk levels add nuance. Recovery outlook answers “when?”

None of these fields exist in isolation. Together, they give the user a complete picture in a few seconds of scanning — enough information to make a confident decision without reading a weather report.

The Design Principle

The engine’s output design follows one principle: make the decision for the user, then show your work.

Most users will see the verdict color, read the headline, and decide. That’s the 80% case, and it should take three seconds. The rationale, risk levels, and recovery outlook are there for the 20% who want to understand why, or who are in a borderline situation where the details matter. And yes, I want wildly overboard on the proving your work part because I wanted it to be crystal clear that this isn’t a pretty veneer over what is essentially a weather app — the Groundwise engine is doing sophisticated modeling in service of a “simple” yet nuanced and challenging question about rideability/playability/vulnerability (plant vulnerability in Yardwise).

This is the opposite of how most weather apps work. They give you all the data and expect you to synthesize it into a decision. The Groundwise engine synthesizes first, then offers the data for verification. The user’s default is to trust the verdict and act on it. The detail is available but not required.

That’s what made three states better than a percentage. A percentage demands interpretation. A verdict offers a recommendation. The supporting detail is opt-in, not mandatory.

Thanks for Reading

This series covered a lot of ground, from the core concept through the drying math, multi-app architecture, winter edge cases, the Yardwise inversion, and now the verdict UX. If you’ve built something that turns noisy data into human decisions, I’d love to hear about your approach. The threshold and confidence problems are universal.

The Groundwise engine powers Ridewise, Fieldwise, and Yardwise — all available for iOS from Stalefish Labs. Find us on Bluesky.

One Engine, Three Apps: Sharing a Swift Decision Engine Across Products

Michael Morrison — Fri, 20 Mar 2026 00:00:00 -0700

In the previous articles I’ve covered what the Groundwise engine does and how the drying model works. This article is about the architectural decision that turned one app into three: sharing a single decision engine across Ridewise (trail conditions), Fieldwise (sports field conditions), and Yardwise (watering guidance).

The pitch sounds clean: “one engine, three apps.” The reality required some specific design choices to keep it from becoming a tangled mess of conditionals.

The Shape of the Problem

The initial problem was how to apply human intuition to map recent/current weather conditions onto different kinds of surfaces to assess “rideability,” the application being that I wanted a simple verdict on if a mountain bike trail or skateboard ramp was sufficiently dry to session. That’s it, weather inputs in and surface type in, rideability verdict out. And it worked, the app Ridewise solves the problem, and in building it I created a slick little software engine. The thing is, once you’ve built an engine, you start to think about other things it might solve. In this case I realized the Groundwise engine is really answering a question more general than mountain biking or skateboarding, it’s answering the fundamental question: what’s the moisture situation at this spot?

So the idea of three different apps started to coalesce, and their distinguishing characteristics began to emerge:

Cares about different surfaces (skateparks vs. soccer fields vs. herb gardens)
Has different thresholds for what counts as “too wet” or “too dry”
Interprets the engine verdict differently (wet is bad for riders, good for gardeners)
Needs app-specific logic (gardeners track manual watering, riders don’t)
Uses different language in the rationale (“trail might be muddy” vs. “field may hold water” vs. “soil has enough moisture”)

The question was whether to fork the engine into three copies, or keep one engine and parameterize the differences. I went with parameterization, and the key that made it work was keeping the customization surface small. As you’ll see, this was a key design decision early that paid off big later.

EngineMode: Flipping the Perspective

One of the most key types in the Groundwise engine is what allows it to pivot between caring about dryness or caring about wetness:

enum EngineMode {
 case wetnessConcern // Ridewise, Fieldwise
 case drynessConcern // Yardwise
}

The engine always calculates a wetness score from 0 (bone dry) to 1 (saturated). EngineMode controls what that score means:

Wetness concern: Low score = Yes (go ride), high score = No (too wet)
Dryness concern: Low score = Yes (water your plants), high score = No (skip watering)

The verdict enum is the same in both modes (Yes, Maybe, No) but the interpretation inverts. This is a deliberate choice. The consuming app doesn’t need to know which mode produced the verdict. It just renders appropriate app-specific colors/symbols for Yes, Maybe, and No.

SiteType: A Unified Wrapper

Each app has its own domain vocabulary. Ridewise has “spots” (trails, skateparks), Fieldwise has “fields” (baseball diamonds, tennis courts), Yardwise has “areas” (lawns, raised beds). Rather than making the engine accept three different input types, they’re wrapped in a single enum:

enum SiteType {
 case spot(SpotType) // Ridewise: trail, skatepark, bikeJumps, pumpTrack...
 case field(FieldType) // Fieldwise: baseball, soccer, tennis, rugby...
 case area(AreaType) // Yardwise: lawn, raisedBed, container, compost...
}

The key thing we’re trying to arrive at for wetness/dryness purposes is a surface type. Each case in this enum maps to a SurfaceType, the thing the engine actually cares about. A SpotType.skatepark maps to SurfaceType.concrete. A FieldType.baseball maps to SurfaceType.naturalGrass. A AreaType.container maps to SurfaceType.pottingMix.

The engine never branches on SpotType or FieldType directly. It resolves the surface type up front, then works exclusively with surface properties. This is what keeps the core logic free of app-specific conditionals, and ultimately what enables engine reuse across apps with different concerns.

Surface Types: The Parameterization Layer

The apps currently have seventeen surface types to encode the physical properties that actually matter for moisture modeling:

// Each surface type defines:
var dryingMultiplier: Double // 0.7 (clay) to 2.8 (metal)
var damageSensitivity: Double // 0.0 to 1.0
var isDrainingSurface: Bool // sheds water vs. absorbs
var isAbsorbentSurface: Bool // holds water in material
var safetySensitivity: Double // slip risk when wet
var qualitySensitivity: Double // quality degradation when wet

The engine uses these properties, never the surface type identity, to modulate its calculations. Drying multiplier scales how fast moisture clears. Damage sensitivity controls the sensitivity veto (should the engine push borderline verdicts toward protection?). Draining vs. absorbent determines whether residual wetness applies.

This means adding a new surface type is a data change, not a logic change. If someone wanted to add “packed gravel” for Ridewise, they’d define its properties and it would flow through the existing pipeline.

Also notice a few perhaps surprising things that entered the data model: safety and quality sensititivies. When you think about it, rideability isn’t just about “too muddy” or “has puddles,” there’s also a safety concern and a quality of ride concern. Skateparks are notably impossible to ride with any standing moisture, while mountain bike trails have a fairly wide range of acceptance that sometimes comes down to local rules (is it open?) and personal tolerance (how much mud is just annoying?). So the wet skatepark scenario is truly a safety risk, while the mountain bike scenario is more about am I damaging the trail and am I open to a mud ride.

As an aside, it’s worth noting that I ride a local private mountain bike trail that gets so little traffic that mud isn’t a damage concern at all. We tend to invert the normal ride season and ride that trail specifically in less than ideal conditions, so it provided a bit of a logic stress test for the app. Often for this particular trail I’ll take a Maybe verdict as a green light given its unique properties.

Threshold Calibration Per Mode

When it comes to actually rendering a verdict, the verdict thresholds differ between wetness concern and dryness concern:

	Yes	Maybe	No
Wetness concern	< 0.30	0.30 – 0.60	≥ 0.60
Dryness concern	< 0.15	0.15 – 0.45	≥ 0.45

Yardwise thresholds are shifted lower because the consequences are asymmetric. For a rider, going out on a borderline trail risks damaging the trail surface. For a gardener, missing one watering day rarely kills plants. The engine leans toward “maybe water” rather than “definitely water” because overwatering is its own problem.

The sensitivity veto also inverts:

Wetness concern: If a sensitive surface (like natural grass with 0.9 damage sensitivity) gets a Maybe verdict with wetness above 0.4, it’s pushed to No. Protect the surface.
Dryness concern: If a sensitive surface (like fresh seed with 0.95 effective sensitivity) gets a Maybe verdict with wetness below 0.3, it’s pushed to Yes. Water the fragile plants.

Same mechanism, opposite direction. And yet one line of mode-aware logic handles both cases.

App-Specific Features Without Conditionals

It’s worth pointing out that Yardwise has two features the other apps don’t: manual watering tracking and cold-weather dormancy suppression. Rather than branching on app identity, these are driven by the input data:

Manual watering is an array of WateringEvent values on the input struct. Ridewise and Fieldwise pass an empty array. The engine’s watering contribution calculation gracefully returns zero when there are no events, meaning no conditional needed.

Establishment sensitivity is a Double on the input (0.0 by default). Yardwise sets it to 0.5 for newly seeded areas and 0.2 for newly planted ones, boosting the surface’s damage sensitivity. Ridewise and Fieldwise leave it at 0.0. Again, no branching for the apps that don’t care, the math just works with a zero boost.

Cold-weather dormancy activates when the temperature drops below 55°F. It injects additional “wetness” into the Yardwise calculation, suppressing watering recommendations when plants are dormant. This is gated on EngineMode.drynessConcern because the concept doesn’t make sense for riders given that cold weather doesn’t make trails less wet.

This is the one place where I accepted a mode check in the engine, and it was a pragmatic call. Dormancy is fundamentally a gardening concept. Trying to abstract it into a mode-agnostic mechanism would have added complexity without clarity.

The Input Struct

On to the engine inputs, where everything flows through a single input type:

struct GroundwiseInputs {
 // Weather (required)
 let rain24hInches: Double
 let rain48hInches: Double
 let rain72hInches: Double
 let minutesSinceRainEnded: Int?
 let rainPattern: RainPattern
 let temperatureF: Double
 let sustainedWindMph: Double
 let cloudCoverFraction: Double

 // Weather (optional, improves accuracy)
 let gustsMph: Double?
 let dewPointF: Double?
 let relativeHumidity: Double?
 let overnightLowF: Double?
 let daysSinceLastRain: Int?

 // Freeze/thaw context
 let frozenSnowAccumulationInches: Double?
 let hoursSinceThawBegan: Int?
 let hoursBelowFreezing: Int?

 // Site context
 let siteType: SiteType
 let surfaceType: SurfaceType
 let exposureLevel: ExposureLevel

 // Mode and calibration
 let engineMode: EngineMode
 let establishmentSensitivityBoost: Double
 let isCurrentlyPrecipitating: Bool
 let hasThunderstorm: Bool

 // Yardwise-specific
 let manualWateringEvents: [WateringEvent]
}

Each app constructs this from its own domain model. Ridewise fills in the weather data and its spot’s surface type. Yardwise adds watering events and an establishment boost. The engine doesn’t know or care which app called it.

The Output: Same Structure, Different Meaning

The engine evaluates the inputs as a black box and generates an assessment in this form:

struct GroundwiseAssessment {
 let verdict: Verdict // .yes / .maybe / .no
 let confidence: Confidence // .low / .medium / .high
 let rationale: GroundwiseRationale
 let riskSurfaceDamage: RiskLevel
 let riskActivitySafety: RiskLevel
 let riskActivityQuality: RiskLevel
 let recoveryOutlook: RecoveryOutlook?
}

The consuming app interprets the verdict through its own lens. Ridewise renders Yes as “Dry — go ride.” Yardwise renders Yes as “Water today.” The engine provides the structured rationale (headline, decisive factor, contributing details), and each app’s UI formats it with domain-appropriate language.

Risk levels work the same way. Surface damage risk on a trail means erosion and ruts. Surface damage risk on a newly seeded lawn means killing the seed. Same risk level, different consequence, the app handles the framing.

What I’d Do Differently

The engine’s one-file structure (2,193 lines in GroundwiseEngine.swift) works but isn’t ideal. The frozen conditions check alone is 360 lines. If I were starting over, I’d break the pipeline into discrete stages: FreezeAssessor, PrecipitationAssessor, and DryingCalculator, VerdictResolver. And I’d make each of these a separate type with a clear protocol.

I’d also make the threshold constants configurable per surface type rather than per engine mode. Right now, all wetness-concern surfaces share the same 0.3/0.6 thresholds. But a clay tennis court arguably deserves tighter thresholds than an artificial turf field. The sensitivity veto partially handles this, but explicit per-surface thresholds would be cleaner.

That said, the current design has shipped and works. Premature refactoring is its own trap.

The Tradeoff

Sharing an engine across three apps means accepting constraints:

You can’t special-case easily. If Ridewise needs a trail-specific behavior that doesn’t generalize, you either make it general enough for the shared engine or handle it in the app layer.
Testing surface area grows. Every change to the engine needs to be validated against all three app contexts. A threshold tweak that improves Ridewise verdicts might break Yardwise scenarios.
Abstraction has a ceiling. Cold-weather dormancy proved that not everything generalizes cleanly. Knowing when to accept a mode check instead of over-abstracting is a judgment call.

The upside: every improvement to the drying model benefits all three apps simultaneously. When I improved the residual wetness calculation for trails, clay tennis courts and garden beds got more accurate too because they share the same underlying property (absorbent surfaces retain moisture).

For an indy developer maintaining three related apps, that leverage is worth the constraints.

Next in the Series

The next article digs into the edge cases that make weather modeling humbling: freeze/thaw cycles, precipitation intensity, snow melt, and cold-weather plant dormancy. Each one is a lesson in how simple models break when they meet the real world.

Ridewise, Fieldwise, and Yardwise are all available for iOS from Stalefish Labs. Built by one developer, powered by one engine.

Turning Raw Weather Into a Drying Model

Michael Morrison — Tue, 17 Mar 2026 00:00:00 -0700

In the first article about my foray into using weather data to assess surface conditions for riding activities, I introduced the Groundwise engine, a software decision system that turns weather data into a yes/maybe/no verdict for outdoor conditions. This article goes deeper into the core moisture model: how the engine takes raw weather observations and calculates a wetness score that drives the verdict. The hope is to show how a simple question such as “can I ride my mountain bike today?” spiraled into a fairly complex yet intriguing design challenge. Totally fair if you aren’t entranced by weather math, I get it, but I feel like there’s some value in pulling back the curtain to reveal how much goes into solving a seemingly simple problem.

The Groundwise model is relatively restrainted in scope, it isn’t trying to simulate soil physics. It’s trying to approximate what an experienced local would know instinctively — “it rained pretty hard yesterday, but it’s been warm and windy all morning, so the trails are probably fine.” The goal is to encode that intuition into something repeatable and surface-aware.

Weighted Precipitation: Not All Rain Is Equal

The engine tracks precipitation across three time windows: the last 24 hours, 24-48 hours ago, and 48-72 hours ago. But it doesn’t treat them equally. Here’s how they are weighted differently by the weather precipitation equation:

weatherPrecip = rain24h × 0.7 + (rain48h - rain24h) × 0.2 + (rain72h - rain48h) × 0.1

Recent rain dominates. An inch in the last 24 hours contributes seven times more to the score than an inch from two days ago. This matches real-world observation, where rain from three days ago has had significant time to drain and evaporate, while yesterday’s rain is still actively affecting conditions.

The subtraction matters too. rain48h is a cumulative total (it includes the last 24 hours), so the formula isolates each window’s unique contribution. A half an inch total over 48 hours where all of it fell in the last 24 tells a very different story than half an inch spread evenly.

Rain Score Normalization

A recent rain results in a raw precipitation value that gets normalized to a 0-1 scale, so effectively a percentage:

rainScore = min(1.0, totalPrecip / 0.75)

Three-quarters of an inch saturates the score (maximum value of 1, or 100%). Beyond that, more rain doesn’t make things more wet from the engine’s perspective — you’re already at maximum precipitation/saturation, which matches reality in that a trail, yard, or any other outdoor surface has a limit to how wet it can get. This prevents a 3-inch deluge from producing a wildly different result than a 1-inch soaking. Both are “very wet” — the distinction that matters is how long ago it happened and how fast things are drying.

Why Intensity Matters

The engine tracks rain pattern: light, steady, or downpour. It then applies a multiplier to the base wetness given one of those patterns:

Pattern	Multiplier	Why
Light	0.7x	Gentle rain soaks in gradually, less runoff, less surface pooling
Steady	1.1x	Sustained saturation, ground can’t keep up
Downpour	1.5x	Overwhelms drainage, causes pooling and surface flooding

A quarter inch of light rain over several hours is genuinely different from a quarter inch dumped in 20 minutes. The light rain absorbs more evenly. The downpour creates surface water, overwhelms drainage on absorbent surfaces, and can cause erosion on trails.

Drying Strength: The Recovery Side

Wetness is only half the picture. The other half is how aggressively conditions are drying things out. The engine calculates a composite drying strength from four weather factors:

drying = (tempFactor × 0.30) + (windFactor × 0.30) + (humidityFactor × 0.25) + (skyFactor × 0.15)

Temperature (30% weight): Warmer air holds more moisture and drives evaporation. The factor scales linearly from 0 at 50°F to 1.0 at 90°F. Below 50°F, evaporation slows dramatically. Above 90°F, you’re drying as fast as conditions allow.

tempFactor = clamp((tempF - 50) / 40, 0, 1)

Wind (30% weight): Moving air carries moisture away from surfaces. Scales linearly up to 20 mph, where the effect plateaus - going from 20 to 40 mph doesn’t double the drying rate.

windFactor = clamp(sustainedWindMph / 20, 0, 1)

Humidity (25% weight): Dry air absorbs moisture more readily. This is the inverse, where low humidity means strong drying.

humidityFactor = clamp(1.0 - effectiveHumidity, 0, 1)

When the weather API provides a dew point instead of relative humidity, the engine converts it using the Magnus formula. Dew point is actually the more reliable measurement — relative humidity fluctuates throughout the day even when actual moisture content stays constant.

Sky cover (15% weight): Clear skies mean solar radiation hitting surfaces directly, which drives evaporation. Clouds block that. This gets the lowest weight because its effect is real but smaller than the others.

skyFactor = clamp(1.0 - cloudCover, 0, 1)

Exposure Matters

All of this gets modified by where the surface actually sits. A trail under heavy tree canopy dries differently than an open field fully exposed to sunlight:

Exposure	Rain Multiplier	Drying Multiplier
Exposed	1.0x	1.0x
Shaded	0.7x	0.6x
Covered	0.0x	0.8x

Shaded spots get less rain (canopy intercepts 30%) but also dry 40% slower (less sun, less wind). Covered spots (under a roof or overhang) get no rain at all but still have air circulation for moderate drying.

This creates an interesting dynamic: a shaded trail might actually be drier than an exposed one after light rain (less water reached it) but wetter after heavy rain (the rain that got through takes longer to leave).

Drying Classification

The composite score maps to three tiers, each returning a fixed drying effectiveness value:

Score Range	Classification	Effectiveness
≥ 0.7	Strong	0.8
0.4 – 0.7	Moderate	0.5
< 0.4	Weak	0.2

I deliberately chose discrete tiers over a continuous curve. The difference between a 0.41 and a 0.69 drying score isn’t meaningful in practice — both represent “conditions are helping somewhat.” The tiers prevent false precision while still capturing the real distinction between “sunny and breezy” (strong), “overcast and mild” (moderate), and “cold, humid, and still” (weak).

Combining It All: The Wetness Score

I warned you this problem has more nuance that it would seem. But hang in there, we’re getting closer to arriving at some meaningful mathematical conclusions. For example, the wetness score blends precipitation and drying into a single 0-1 value:

baseWetness = rainScore × 0.5 + (rainScore × timingScore) × 0.6

This formula does something subtle. The first term (rainScore × 0.5) ensures that heavy rain always contributes some wetness regardless of timing. The second term (rainScore × timingScore) captures the interaction — recent heavy rain is much worse than old heavy rain. The timing score decays linearly from 1.0 (just stopped) to 0.0 (24+ hours ago).

After the base calculation, the rain pattern multiplier is applied (0.7x for light, 1.1x for steady, 1.5x for downpour), then drying reduces it:

dryingEffect = dryingScore × 0.3 × dryingEffectiveness
wetness = baseWetness × (1.0 - dryingEffect)

The dryingEffectiveness factor prevents drying from being too aggressive when rain just ended. If rain stopped 30 minutes ago, even strong drying conditions haven’t had time to do much yet. The factor scales up as time passes, so drying’s impact grows the longer it’s been since rain.

A Worked Example

To put all these equations into perspective, let’s trace through a real scenario to arrive at a Groundwise verdict: 0.4 inches of steady rain ended 8 hours ago. It’s 72°F, 12 mph wind, 45% humidity, 20% cloud cover. Exposed dirt trail.

Rain score:

weatherPrecip = 0.4 × 0.7 = 0.28 (all in last 24h)
rainScore = min(1.0, 0.28 / 0.75) = 0.37

Timing score:

hours = 480 min / 60 = 8
timingScore = max(0, 1.0 - 8/24) = 0.67

Drying strength:

temp = (72-50)/40 × 0.30 = 0.165
wind = 12/20 × 0.30 = 0.18
humidity = 0.55 × 0.25 = 0.1375
sky = 0.80 × 0.15 = 0.12
total = 0.60 → Moderate (effectiveness = 0.5)

Wetness:

base = 0.37 × 0.5 + (0.37 × 0.67) × 0.6 = 0.185 + 0.149 = 0.334
× steady pattern (1.1) = 0.367
dryingEffectiveness = max(0.2, 1.0 - 0.67 × 0.5) = 0.665
dryingEffect = 0.5 × 0.3 × 0.665 = 0.10
wetness = 0.367 × (1.0 - 0.10) = 0.33

Verdict: Maybe (0.33 is just above the 0.3 threshold). The trail is borderline — rideable but still damp. On a dirt trail (damage sensitivity 0.5), the sensitivity veto wouldn’t trigger. A reasonable call either way, and the engine goes with Maybe, giving the rider the opportunity to then weigh locale-specific details such as trail sensitivity to damage.

Now change one variable — make it 85°F instead of 72°F:

temp = (85-50)/40 × 0.30 = 0.2625
total drying = 0.70 → Strong (effectiveness = 0.8)
dryingEffect = 0.8 × 0.3 × 0.665 = 0.16
wetness = 0.367 × (1.0 - 0.16) = 0.308

Still Maybe, but barely. A bit more wind or another hour of drying and it flips to Yes. That matches intuition — a hot afternoon pulls moisture out fast.

Residual Wetness: The Ground Remembers

The timing-based model handles most scenarios well, but it has a blind spot: ground saturation after heavy rain on absorbent surfaces.

If it rained an inch on Monday and you’re checking the trail on Wednesday, the timing score says “it’s been 48 hours, moisture contribution is minimal.” But anyone who’s walked a clay trail two days after heavy rain knows that’s wrong. The ground is still holding water.

The engine adds a residual wetness component for absorbent surfaces (dirt, grass, clay, amended soil) when precipitation exceeded 0.25 inches:

volumeFactor = clamp((rain - 0.25) / 0.75, 0, 1)
decayFactor = based on hours since rain and drying strength
surfaceRetention = inverse of surface drying multiplier
dryingReduction = strength-based reduction
residualWetness = 0.55 × volumeFactor × decayFactor × surfaceRetention × (1.0 - dryingReduction)

The peak residual value of ~0.55 deliberately sits in the middle of the Maybe range. It’s not enough to trigger a hard No, but it keeps the engine from prematurely saying Yes on saturated ground.

Clay surfaces (drying multiplier 0.7x) retain the most residual moisture. Concrete and metal (2.0x+) don’t get residual wetness at all, they’re draining surfaces that hold little (concrete) to no (metal) water.

What This Model Doesn’t Do

A few things I intentionally left out:

Soil type modeling. Real evapotranspiration models account for soil composition, drainage rates, water table depth. The engine uses surface type as a proxy instead. A dirt trail in sandy Arizona soil dries differently than one in Georgia red clay, and the engine can’t distinguish them. The tradeoff is simplicity — asking users to classify their soil composition seemed like a bridge too far. If you disagree, let us know, but I decided to err on the side of simplicity at least in terms of user inputs.

Microclimate effects. Two spots a mile apart can have meaningfully different conditions. The engine uses a single weather observation for each saved location, which might come from a station several miles away. Elevation, valley effects, and urban heat islands aren’t modeled.

Drainage infrastructure. A well-designed trail with proper drainage handles rain better than a flat trail in a depression. An athletic field with subsurface drainage is ready for play sooner than one without. The engine doesn’t know about this. Surface type captures some of it (artificial turf implies drainage engineering), but it’s imperfect.

These are all real limitations, and I’d rather be transparent about them than pretend the model is more precise than it is. The engine targets “better than guessing” — not “better than walking over and checking yourself.”

Next in the Series

The next article covers how this engine is packaged as a shared Swift framework consumed by three different apps — each with its own surface library, threshold calibration, and verdict interpretation. Same core math, three different products. It’s a lesson in code reuse, and the benefits of solving a problem once in just a general enough way to apply that solution multiple times.

The drying model powers Ridewise, Fieldwise, and Yardwise — all available for iOS from Stalefish Labs.

I Built a Weather Engine That Tells You When to Ride, Play, or Water

Michael Morrison — Thu, 12 Mar 2026 00:00:00 -0700

Every mountain biker knows the ritual. It rained last night. You check the radar, clear now. You check the trail association’s Facebook page, nobody’s posted. You text your riding buddy: “Think the trails are good?” They don’t know either. So you either stay home and miss a perfectly rideable day, or show up and chew through muddy trails that needed another six hours to dry.

I got tired of guessing so I built a weather decision engine that answers the question directly: is it too wet to ride?

Then I realized the same engine could answer two more questions: is this field playable? and does my garden need watering?

This is the story of the Groundwise engine, a single Swift package that powers three iOS apps by asking the same underlying question from different perspectives.

The Problem With “Did It Rain?”

Weather apps mostly tell you what will happen, and to a lesser degree they can tell you what happened. What they don’t tell you is what it means for the specific thing you want to do.

Half an inch of rain means completely different things depending on context:

On a concrete skatepark, it sheds in a couple hours. You’re probably fine by afternoon.
On a dirt trail, it might need 24 hours with good sun and wind. Or 48 hours or more if it’s overcast and cold.
On a clay tennis court, you might be waiting even longer, clay holds moisture and damages easily when wet.
In a container garden on a sunny patio, that half inch drained through the potting mix hours ago and your herbs might need water again tomorrow.

The answer isn’t just “how much rain,” it’s how much rain, on what surface, how long ago, and what the drying conditions have been since.

From Weather Data to a Verdict

So I built a weather analysis engine that takes in a handful of weather observations and produces a single categorical verdict regarding an action on a specific surface: Yes, Maybe, or No.

The inputs are straightforward, stuff you’d get from any weather API:

Precipitation totals (last 24, 48, and 72 hours)
How long since rain ended
Whether it was light, steady, or a downpour
Current temperature, wind speed, humidity, and cloud cover
Whether it’s actively raining right now

Plus one critical piece of context: what surface are you asking about?

The engine defines 17 surface types across three categories. Each has a drying multiplier that controls how fast moisture clears, for example:

Surface	Drying Speed	Notes
Metal skateboard ramps	2.8x	Fastest, sheds water, heats up quickly
Artificial turf	2.5x	Engineered to drain
Asphalt	2.2x	Dark surface, absorbs heat
Concrete	2.0x	Drains well, slower to heat than asphalt
Potting mix	2.0x	Loose, fast-draining soil
Compost	1.2x	Active decomposition generates some heat
Dirt/ground	1.0x	Baseline, absorbs and holds water
Natural grass	1.0x	Root systems retain moisture
Amended soil (mulched)	0.7x	Mulch deliberately slows evaporation
Clay	0.7x	Dense, holds water, slow to release

That 4x difference between metal and clay isn’t just a number, it’s the difference between “rideable in an hour” and “unplayable until tomorrow.”

The Decision Pipeline

The engine runs checks in a specific order, with the most critical conditions evaluated first:

1. Is the ground frozen? If there’s an ice or snow hazard, the verdict is No regardless of moisture. This check alone is about 360 lines of code, freeze/thaw cycles are surprisingly complex. A concrete skatepark clears ice in 6 hours at 55°F, but a dirt trail might need 72 hours at 45°F to fully thaw and dry.

2. Is it actively raining? Straightforward gate. If precipitation is falling, the answer is No (or Maybe for very light drizzle on a fast-draining surface with strong drying conditions).

3. Calculate a wetness score. This is where the real modeling happens. The engine combines:

A rain score weighted toward recent precipitation (70% from last 24h, 20% from 24-48h, 10% from 48-72h)
A timing score that decays linearly over 24 hours since rain ended
A drying strength composite that factors in temperature, wind, humidity, and cloud cover
Residual wetness for absorbent surfaces, heavy rain on dirt or clay retains moisture well beyond what the timing score captures

4. Apply the verdict thresholds. A wetness score below 0.3 means Yes (dry enough). Between 0.3 and 0.6 means Maybe (borderline). Above 0.6 means No (too wet).

5. Sensitivity veto. High-sensitivity surfaces (like newly seeded lawns or natural grass athletic fields) get pushed from Maybe toward a more protective verdict. The engine would rather tell you to wait than let you damage a surface that’s expensive to repair.

One Engine, Two Perspectives

If you’re wondering how the above, which is described in terms of using a surface, could possibly apply to a container garden, it’s a fair question. And this is where the engine morphed into serving a series of apps instead of just one:

The engine calculates a wetness score. For riders and athletes, high wetness is bad, you want dry conditions. For gardeners, high wetness is good, it means you can skip watering.

Same math, opposite interpretation:

Wetness Score	Rider/Athlete View	Gardener View
Low (< 0.3)	Yes, go ride!	Yes, water today
Medium (0.3-0.6)	Maybe, check conditions	Maybe, check soil
High (> 0.6)	No, too wet	No, skip watering

The engine calls this EngineMode, either wetnessConcern or drynessConcern. A single enum that flips the entire interpretation layer while keeping the underlying moisture model identical.

Yardwise (the gardening app) uses slightly shifted thresholds, 0.15 and 0.45 instead of 0.3 and 0.6, because the stakes of getting it wrong are lower. Missing a watering day is a mild inconvenience. Riding a muddy trail damages the trail. Playing softball on a muddy clay infield isn’t great. You get the idea.

Why Not Just Show a Percentage?

Early versions of the apps showed a moisture percentage, and it wasn’t good. I didn’t know what to do with “the trail is at 47% moisture.” Is that rideable? It depends on the surface, on your own risk/comfort tolerance, on whether you care about trail damage, etc. A percentage pushes the decision back onto the user, which is exactly the problem the app was supposed to solve.

The solution was to simplify down to three states: Yes/Maybe/No, with an explanation of why. The Maybe state exists specifically for conditions where reasonable people would disagree. I have near me both public and private mountain bike trails, and the tolerance for mud varies widely based on level of traffic, so Maybe is when deferring to rider’s judgement is actually correct. The engine shows you the contributing factors (temperature is helping, but humidity is holding things back, for example) so you can make the final call.

Each verdict also carries a confidence level (Low, Medium, High). Confidence drops when timing data is missing, when rain has been patchy and unpredictable, or when the wetness score lands right on a threshold boundary.

What’s Coming in This Series

If you find talk of drying multipliers and residual wetness scores riveting, then hold on to your butts! This is merely the first article in a series about building the Groundwise engine. Coming up:

Turning Raw Weather Into a Drying Model - The math behind drying strength, residual wetness, and why rain intensity matters as much as total accumulation
One Engine, Three Apps - How to structure a Swift package that serves multiple products with different surface libraries and threshold calibrations
Edge Cases That Break Your Weather Model - Freeze/thaw cycles, cold-weather plant dormancy, the surprising complexity of “is snow melting?”, and dispatches from the great Nashville ice storm of 2026
Flipping the Question - How the Yardwise inversion works, including manual watering tracking and evaporative demand suppression
Building Confidence Into Uncertain Verdicts - Why three states beat a percentage, and how to communicate uncertainty without creating anxiety

The Apps

The Groundwise engine powers three apps, all available for iOS:

Ridewise, ride conditions for trails, skateparks, bike parks, and pump tracks
Fieldwise, field conditions for rec league sports on grass, turf, clay, and hard courts
Yardwise, watering guidance for casual gardeners with lawns, beds, and containers

All three are built by Stalefish Labs, a small indie studio focused on simple tools for getting outside and doing things together.

If you’ve built something that turns raw data into human decisions, I’d love to hear how you approached the threshold and confidence problem. Drop a comment or find us on Bluesky.

From Group Chat to App: How Going Digital Unlocked Better Fantasy Stats

Michael Morrison — Fri, 06 Mar 2026 00:00:00 -0800

Open Wheelers the app started life as a text thread. A group of friends with a love of Formula 1 just wanted a fun alternative to complex fantasy games with drafted teams, waivers, etc. So we played a manual game within a text thread, a gentleman’s agreement to get your picks in before the lights go out, and yours truly would manually tally results after each race, post the updated standings, and we’d argue about who was actually winning. It worked well enough for years. And it was completely holding the game back.

The thing about a manual game is that your pick categories are limited to whatever a human scorekeeper (me!) can reasonably verify after a race. Podium finish? Easy, check the top 3. DNF? Straightforward enough, the list of retirements is right there. Fastest lap? Easyish, one name, but F1 stopped publishing it clearly when they stopped awarding points to drivers in 2025, so it required a search each week.

So that’s what we were using: Podium, Fastest Lap, DNF. Three categories, three picks. Simple, fun, and perfectly adequate for a casual league among friends run out of a text thread. You may not think of the Messages app as a game engine, but it actually kinda worked.

But “adequate” and “kinda” are dangerous words for someone who obsesses over game design.

The problem with Fastest Lap

Turns out the mediocrity of our system had everything to do with the picks and points, and how they were born out of what was doable for a guy manually managing the stats. Take Fastest Lap, which sounds like an exciting stat. In practice, it’s one of the least interesting picks you can make, and here’s why: in today’s F1, the fastest lap is all too often just an index of the top cars in the race. It was actually a bit more interesting in the first years of our game when F1 actually gave out a point for Fastest Lap - then you’d sometimes see a driver deep in the pack pit late for fresh soft tires to try and snag a point. When F1 did away with that rule in 2025, Fastest Lap became a strategic afterthought, not a battle.

More importantly, it basically became a proxy pick for the Podium, a pick we already had. So we wanted something that rewarded paying attention to the actual racing. Something with real variance from week to week, where deep knowledge of the grid actually mattered. And maybe even something that could reward a bit of grit for that driver who battles throughout the race with hard driving even if it doesn’t necessarily net them podium glory. Think Lewis Hamilton struggling at Ferrari but in some races rage-passing half the field from a poor qualifying start.

Enter the Overtaker

The stat we really wanted was most positions gained: the driver who climbs the most spots from their starting position to their finishing position. In F1, this is sometimes called the “overtaker” award. It rewards the most dynamic racing of the afternoon: the recovery drives, the strategic masterstrokes, the scrappy midfield battles that don’t make the broadcast highlights but absolutely define the race.

It’s Fernando Alonso starting P17 after a qualifying penalty and slicing through to P7. Or a midfield driver nailing an alternate strategy to jump six cars on the undercut. Or someone surviving a chaotic wet start to gain a dozen spots while half the grid spins off. Yes, probably Max. You get the idea. These are the moments that make F1 worth watching, and the Overtaker pick puts a fantasy stake directly in them.

The problem? Try scoring that manually from a group chat.

To calculate positions gained, you need each driver’s starting grid position and their finishing position, then compute the delta for every classified finisher, then rank them. That’s 20 drivers, two data points each, every race. It’s not rocket science, but it’s exactly the kind of tedious bookkeeping that kills a casual game. No one’s going to maintain a spreadsheet for a fun side competition with friends. And if the scorekeeper gets it wrong, which I will, because grid penalties and post-race time penalties shift the numbers, the arguments start.

The app does the boring parts

This is the quiet superpower of moving a game from text to software. The app doesn’t just automate scoring, it unlocks categories that were impractical before. When results flow in digitally, computing positions-gained is trivial. Grid position minus finish position, sort descending, done. The app handles ties, accounts for DNS and DNF edge cases, and posts the answer the moment results are confirmed.

What took a motivated scorekeeper (me!) 15 minutes of cross-referencing now takes zero effort. And the pick itself, who’s going to gain the most positions, is infinitely more interesting than Fastest Lap. It asks you to think about:

Qualifying mismatches: Which fast cars are starting out of position due to grid penalties?
Race pace vs. one-lap speed: Who has a car that’s better in race trim than qualifying trim?
Strategy variance: Which teams might roll the dice on an alternate strategy that could leap them up the order?
Track characteristics: Is this a track where overtaking is physically possible, or will grid position mostly hold?

Every one of those questions requires genuine knowledge of the sport. That’s a pick category with depth.

The design principle

The lesson here isn’t specific to F1 or fantasy sports. It’s a broader game design idea: the best mechanics are often the ones that were too complicated to run by hand. When you move a game to software, don’t just digitize the existing rules. Ask what was impossible before and whether it’s interesting now.

For Open Wheelers, Fastest Lap was a concession to manual scoring. Overtaker is the pick we always wanted but couldn’t practically support. The app didn’t just make the game easier to play, it made it a better game.

And if you think that’s an incremental difference, try picking the Overtaker for a rainy Interlagos. That’s not a checkbox. That’s a decision.

Open Wheelers is a casual F1 and IndyCar fantasy game for friends, built by Stalefish Labs.

The Weather Says Clear Skies. So Why Is the Trail a Swamp?

Michael Morrison — Thu, 05 Mar 2026 00:00:00 -0800

I love mountain biking. I love skateboarding. I love pretty much anything that involves wheels and dirt and concrete and the outdoors. What I don’t love is driving 30 minutes to a trailhead only to find the trail is a rutted, muddy mess, despite the forecast showing nothing but sunshine.

This is sadly not an isolated occurrence.

The Gap Between Weather and Reality

Weather apps are great at telling you what the weather is and often what it will be. Temperature, wind, humidity, chance of rain, it’s all there. What they don’t tell you is what last night’s rain did to the ground beneath your tires. That half inch at 2am? On a south-facing dirt trail with good drainage, it might be bone dry by noon. On a shaded clay singletrack in the woods? Come back Thursday. Or what about the concrete skatepark in direct sunlight vs. the shaded halfpipe layered in Skatelite? Not the same.

For years I did what every rider or skater does. I’d check the radar, look at the hourly history, maybe glance at the 48-hour precipitation total, and make a gut call. Sometimes I’d text a buddy: “You think Warner is rideable?” And they’d text back something equally scientific: “Probably?”

The variables are too fuzzy. How much did it rain? When did it stop? What’s the temperature now? Is the wind helping things dry? Is the trail in full sun or deep shade? Is the surface dirt, gravel, concrete, wood? Did it freeze overnight and is now thawing into a soupy mess? Each of these factors interacts with the others in ways that are genuinely hard to hold in your head all at once.

So I Built an App

I’m a developer, so naturally my response to this frustration was to write software. What started as a personal side project, just a quick tool to check if my local spots were rideable, turned into something much bigger once I realized how many people share this exact problem.

The app pulls real weather data, looks at recent precipitation, drying conditions, temperature trends, freeze-thaw cycles, surface type, sun exposure, all of it, and synthesizes it into a simple answer: Yes, Maybe, or No. It tells you whether conditions are likely suitable for riding right now, and gives you a seven-day outlook so you can plan ahead.

Building it forced me to formalize all of those gut-feel heuristics I’d been running in my head for years. How much rain is too much? How long does it take to dry? Does Ramp Armor dry faster than wood or metal? When does a freeze actually matter? Translating intuition into code is humbling, because it forces you to confront how much of your “expertise” is just vibes.

It’s Still an Inexact Science

Here’s the thing I want to be honest about: even with a carefully crafted and dedicated prediction engine running real weather data through a multi-phase algorithm, this is still an inexact science. Ground conditions are hyperlocal. Two trails a mile apart can behave completely differently based on soil composition, tree cover, elevation, and drainage. No amount of weather data can perfectly capture what’s happening at a specific spot on the earth’s surface.

The app gives you a well-informed estimate, and in my experience, it’s right far more often than my old gut-check method. But it’s not infallible, and I never want to pretend it is.

That honesty is actually baked into the product. Users can submit feedback when a verdict doesn’t match what they found on the ground. And behind the scenes, I use an LLM to process those reports, analyzing the weather conditions, the surface type, the user’s description of what they actually encountered, and then use that to identify patterns where the engine’s assumptions might be off. It’s a feedback loop that lets the prediction model evolve based on real-world ground truth from actual riders at actual spots.

I think that’s what makes this problem so interesting. It sits right at the intersection of atmospheric data, soil science, and lived experience. No model will ever be perfect, but a model that learns from the people using it every day can keep getting better.

What’s Next

In a future post, I plan to pull back the curtain on the prediction engine itself, how it evaluates moisture, what the drying model looks like, how freeze-thaw cycles are handled, and why certain surfaces behave so differently from others. It’s a surprisingly deep rabbit hole, and I think anyone who’s ever stared at a weather app trying to decide “is it rideable?” will find it interesting.

Until then, check the app, trust the verdict, and if it’s wrong, tell me. That’s how we make it better.

Ridewise is available now on the App Store, built by Stalefish Labs.

Bad Timing & Sticktoitiveness

Michael Morrison — Wed, 04 Jun 2025 00:00:00 -0700

Timing really is nearly everything. And what it isn’t, circumstance makes up for. — Steven Van Zandt

It was such a great plan, it really was. You know those success stories where lightning strikes someone with a genius idea, and then somehow stars align and they take their idea to fruition right when it’s needed most? Wild success ensues, and you get to read about the virtue of following your dreams, and how simply seizing opportunity is all that separates you from similar results. If I was really cheeky I’d give you a numbered list of steps to follow. Well this is not one of those stories, this is a tale of timing, really bad timing. This is a cautionary tale to show how even endless enthusiasm, diligent work, and careful planning can be hilariously mocked by the unforeseen.

My big idea was a software solution to the cat herding problem of figuring out who’s in and out when trying to get together with friends. I’m an old skateboarder (really old!) and it’s an activity that is generally less enjoyable and less safe alone. So skating with friends is a key part of the sport. We used text messaging to plan sessions and it sorta works but has a lot of failings like the first joke or unrelated comment can fully derail the in/out responses, the skate session invite scrolling off into oblivion. Seemed like a problem that could be perfectly solved with a mobile app.

Enter Muster, a mobile app for getting people together in the real world. I tend to play the long game, meaning my pet projects sometimes take a while but I don’t quit easily, so back in 2019 the app had been a project for going on a decade. The iOS version was finally nearing completion and the excitement of actually releasing this thing into the wild was getting real. What had started as a Minimum Viable Product very much morphed into a full-featured app, and the unwillingness to not ship something half-baked at least partially explains the ridiculously long development timeline. In tragedies there’s often a seed of self-destruction if you look deeply enough, and in the case of Muster the perfectionism of features caused the publish date to slip literally years and eventually land in early 2020. So I was wrapping up the final touches on this app for helping people get together…what could go wrong?

On February 20, 2020 I excitedly published my decade-plus long project to Apple’s App Store, the dream was now reality. Indeed, that dream of connecting the world one intimate event at a time was officially beginning. I celebrated with a drink and dessert (actual photo)…it was now time to sit back and wait for the world to adopt this can’t-miss new idea. I imagined finally doing away with clumsy antiquated texting to plan our skate sessions, and the app quickly growing beyond our skateboard crew as a solution for all informal RSVPs. Muster would be a force for good, bringing friend and foe together. Bullies and bullees burying the hatchet, dogs and cats living together in harmony, was peace on Earth finally within reach? I should’ve savored that dessert a bit more…probably a good general rule to live by.

The CDC Museum lists the official start of the COVID-19 pandemic as December 19, 2019, with the first U.S. case on January 20, 2020. But given that pro sports dominates much of American culture, it would be March 11, 2020 when things “got real,” as the NBA canceled the remainder of their season. So less than three weeks after the launch of the app that had been carefully designed to break with other forms of social media and put the focus on people being face-to-face with each other, we find out that being face-to-face with each other is literally life-threatening. Brutal.

I had managed to create a doomsday app purely through an accident of timing. Like catastrophic timing, some of the worst timing ever. How could you possibly spend ten years of your life creating something, only to release it within weeks of it becoming absolutely useless? Worse than useless, dangerous! That was a crushing, helpless feeling, sadly but mercifully overshadowed in some ways by the life and death consequences of the pandemic, which trivialized our individual pursuits in the wake of literal survival for many. Even so, we all knew there would eventually be a return to normalcy, just no clue how or when, and at what cost.

So yes in hindsight I should’ve been working on Zoom not Muster leading into 2020, but here’s the good news about horrific timing…eventually time heals most things, one way or another. You just have to hang on and not let the lows of the present erase the potential highs of the future. I can’t say I was bursting with such cool-headed stoicism in 2020, there was little pretense of calm or wisdom in the moment. Nevertheless, quitting wasn’t on the table, the newly released app languished unused during COVID, as did many of us, while we safe-distanced and waited to find out what happens next.

Then time marched on and eventually things got better. Even though Muster’s initial release was comically flawed, like on a Shakespearean level, it ultimately survived COVID, and is alive and well today. It continues to help me and my friends not skate alone, and it has remained a vibrant project that is still evolving and improving as I stumble to unravel the subtle social challenges of bringing humans together.

I guess the takeaway (in both tech projects and in life) is to realize that even the best attempts at planning can go horribly awry, and the only thing you can truly control is how much quit you have in you. I learned that sometimes the best laid plans will be thwarted by the unknown, where opportunities become problems that turn into predicaments. The only choice is to quit or press on, and if you believe in yourself and what you’re doing that choice is surprisingly easy to make.

Muster is available now on the App Store, built by Stalefish Labs.

Obsession & the Artistic Entrepreneur

Michael Morrison — Mon, 19 Aug 2024 00:00:00 -0700

Without obsession, life is nothing. — John Waters

I obsess over things. Once an idea takes hold, I’m at its mercy. It can arrive in an instant but linger for a very long time, in some cases years and even decades. It can be an obscure hobby (beekeeping), a high-risk activity outside of mainstream ball sports (skateboarding), or it can be an idea for a problem to be solved. Problem solvers are often thought of as entrepreneurs, and they certainly can be, but we’re really talking about two wildly different personalities and skill sets. Yet obsession can give one a false sense of the other.

I mention this because I’ve been obsessively working on a particular problem for quite some time, and as you learn more you might think the time, energy, and money I’ve spent on it makes me an entrepreneur. That’s what I thought too, and I was very wrong. Entrepreneurs are (or should be) serious about things like determining if there’s actually a market for their solution, how to properly reach that market, and just maybe how much it will cost, both financially and more importantly in time. They would do that BEFORE diving into the work, and they’d be right to do so. But that’s not me, and when aiming that laser focus of obsession at a problem, I’ve learned I’m really only solving it for myself.

Project myopia can be a wonderful thing for personal projects where you’re effectively doing pro bono work for yourself. Expectations typically line up pretty well with results when they live in the same person’s head. Or to put it in marketing terms, you don’t have to sell yourself on the benefits of your own idea. Thing is, you DO have to eventually sell others on your idea if part of your plan involves it solving their problems too. For example, a mobile app with a comically ambitious scope. I’m talking about Muster, which is attempting to evolve the concept of an RSVP for the mobile age and in doing so change how we get together with each other in the real world. I’ve been working on it for nearly 15 years, which is slow by almost any standard but insanely slow for tech (the iPhone itself has only been around since 2007). But I’m patient, and stubborn. And I understand that to do just about anything meaningful in life, you must exhibit dogged perseverance and cultivate a certain love for the process of creation itself, with a bright line separating effort from outcome.

So with Muster think an extremely informal evite with a hint of messaging, calendar, a touch of Instagram, even a dash of Strava. I know in marketing you aren’t supposed to define yourself in terms of your peers or competitors but it’s often the simplest way to convey an idea, and zero-sum thinking is usually counter-productive in a world large enough for multiple ideas to co-exist and serve unique purposes. Besides, referencing “the competition” is small potatoes when it comes to Muster and ignoring marketing best practices. Anyway, the idea grew out of the need to distill the communication for getting together down to two possibilities: in or out. Other interesting features evolved over time but that’s still the core of the app: let’s get together, are you in or out?

Seems simple enough, right? I naively thought so too way back in 2010. Turns out there’s a lot of subtlety in event planning, even informal events like meeting up with friends for a coffee. How do people find each other in the app, cultivated friend lists like Facebook? If we’re meeting on Friday in Atlanta (EST) but I create the invitation on Wednesday while in Nashville (CST), what time zone is used? Do you show that time zone in the app? To both people? Is location required or should it be optional, maybe inferred from the title like “Grilling at Our House?” And what about notifications, iPhone and Android users coming together, privacy concerns, etc.? It started to become clear why no other mobile apps have succeeded in solving this ostensibly simple problem, and why most planning is still done with clunky text threads. Enter an obsessive guy with technical skills, a problem to solve, an over-abundance of optimism, and zero regard for proper entrepreneurial decision-making.

Years go by. Then a few more. Plenty of roadblocks surfaced, including a shuttered software development tool (Parse) and a pandemic, among other challenges…but all those design problems mentioned got solved, and many more were identified and solved as well. Not only that, but real-world usage led to several significant enhancements such as event messages and media, invitee groups, plus-ones, co-hosts, min/max attendees, and more. The idea evolved but I stuck to my guns in building the app I wanted, not the app I guessed the world needed. Sure, tons of testing was done with friends and family, not to mention Muster being both a lead sponsor and planning tool for the world’s largest backyard skateboard contest. But at the end of the day every major decision came down to “what do I personally want this app to do?”

And here we get to the real issue at hand. I’ve heard it said that if Bob Dylan hadn’t become one of the greatest songwriters in history, he’d be sitting on a sidewalk somewhere playing the exact same music. That’s an artist. An artist creates because they can’t not do it, and the best artists create for themselves, regardless of whether they ultimately sell their art or perform it to make a living. With art, success lies in the creation itself, not in how it’s received by others — Vincent Van Gogh only sold one painting in his lifetime!

Business is in many ways the opposite of art, where success is necessarily defined by others voting with their wallet for a product by trading goods or money. App-making is certainly a business, I mean apps are literally published in an app STORE. So it’s difficult to make the “apps are art” argument with a straight face. Yet there’s an artist inside this engineer who is dutifully committed to creating the ultimate real world social app purely for myself. And at the same time publish it in a store where others get to decide if it also provides any value to them.

The irony that this ruthlessly individualized app depends on others for business success isn’t lost on the artist in me, yet I can’t not create it. The resulting conflict is real, and the jury is still out on whether this particular marriage of technology and liberal arts ultimately delivers on that famous Steve Jobs insight. In the meantime, if you ever stumble across a guy on a sidewalk sitting on a skateboard with a laptop coding away, consider downloading his app and inviting him for a coffee. I’m in!

Muster is available now on the App Store, built by Stalefish Labs.