Running a Travel Softball Season With Claude
Share on LinkedInI use Claude the way most engineers do. Write code, debug things, work through problems out loud.
This year I pointed it at something that isn’t software at all. I help coach a 16U travel softball team, and a season turns out to be a small operation: money to raise, schedules to keep straight, parents to keep informed, content to produce on a cadence. The interesting part is that almost nothing about how I work changed. Same primitives, same habits, same failure modes. Just a different domain.
If you already use Claude for engineering work, none of the individual capabilities here will surprise you. What surprised me was how directly the practices transfer, and how much of a season is really just state management with a human approval step.
The season is a repo
The whole thing lives in files. A fundraising plan, a schedule, a roster, per-event notes, a set of CSVs. Not one long conversation.
That single decision does most of the work. Conversations lose context and can’t be diffed. Files persist, and Claude can keep them consistent with each other. When a pricing detail changed, it propagated to every document that depended on it in one turn, instead of me remembering three places to update by hand.
Same reason we keep configuration in version control instead of in someone’s head. The novelty isn’t that Claude wrote a document. It’s that it maintains referential integrity across a dozen of them over months.
There’s a source of truth problem too, and it shows up exactly where you’d expect. The roster’s canonical copy is a Google Sheet that other people edit. The local copy drifts. Re-syncing surfaced fields that had been filled in upstream and never made it down, which then unblocked downstream work that had been silently skipping those records. Stale cache, invalidated on read. It’s the same bug you’ve shipped before, in a domain where nobody thinks to look for it.
A couple of records still had no usable value after the sync. Those got flagged as missing rather than filled in with a plausible guess, which is the behavior you want and don’t always get.
MCP servers, pointed at things that aren’t code
This is the part I’d underestimated.
Our fundraiser graphics live in Canva. When pricing changed mid-conversation, Claude read the live design, edited the specific text elements, showed me a before-and-after, and committed it. Not “generate a new graphic.” Read, mutate, verify, commit, against the actual design.
Player birthday posts are the better example, because the input is structured data. Birthdates live in the roster CSV. Claude computes each player’s next occurrence, schedules the work with enough lead time that nothing goes out late, and builds that player’s birthday design in Canva with their details already filled in correctly. The only thing left for me is dropping in the photo.
That’s a join between a local file and a live design tool, templated per record. Conceptually it’s a tiny ETL job with a design system on the end of it. The reason it exists is that it cost a conversation instead of an afternoon, which is the difference between a nice idea and a thing that actually happens twelve times a year.
The team’s Google Calendar works the same way. Parents subscribe to it on their phones, and Claude keeps it current. A game time moves and it lands on their calendar without me sending a separate message about it.
You already know MCP is a protocol for giving a model real tool access. What I hadn’t internalized is that the SaaS tools running the non-code parts of your life increasingly expose the same interface. The mental model where Claude generates content and you go paste it somewhere is already outdated. It’s CRUD against live external state, and the tools are the ones you’re already paying for.
Worth noting the boundary, since it’s instructive: Claude could manage every event on that calendar but could not create the calendar itself or generate the public subscribe link. Those are console-only operations. So I did those two steps by hand, then had it verify the subscribe URL actually returned a valid feed. Standard division of labor between control plane and data plane, and you find it fast when you go looking.
An instructions file, and the reversal it recorded
The project has an instructions file. Same idea as a CLAUDE.md: scope, conventions, and the things I don’t want to re-explain every session.
The entry I care about is a reversal. My first instruction was to sync confirmed events to the parent calendar automatically. A few messages later I took it back. Parents actually look at that calendar, so a wrong entry costs real trust, and the convenience wasn’t worth it. Now anything parent-facing requires explicit confirmation, no exceptions, including for dates that are obviously settled.
Claude updated the instructions file with the new rule and, more usefully, with why the rule exists. That second part is what keeps a future session from helpfully optimizing the guardrail away.
Two things graduated out of the project entirely and into cross-session memory: that I’m an assistant coach rather than a club director, so budget and insurance aren’t mine to own, and the parent-facing confirmation rule itself. Worth being deliberate about that boundary. Project files are scoped config, memory is global state, and things that are true regardless of what I’m working on belong in the second one.
I keep landing in the same place I did using Salesforce’s MCP server against a production org: scope what the tool can touch before it touches anything, then keep a human on the write path that carries real consequences. Everything else can run unattended. The capability to act autonomously and the decision to grant it are separate choices, and the second one stays yours.
The unglamorous parts that actually compound
These are the parts that changed the economics of the whole operation.
Planning as a running conversation. Evaluating fundraising options, modeling returns, revising as new information arrived. It also caught a pricing ladder where one tier was quietly worse value than the tier below it. Not because it did arithmetic I couldn’t do, but because it checked the structure rather than just filling in the numbers I handed it. That’s the review comment you want and rarely get.
Editing loops on things nobody wants to write. Parent communications went through a dozen real revisions each: tone, accuracy, length. Then the good ones became templates with the specifics swapped out. Boring work, done properly, at a cost low enough that I actually did it properly.
Images as input, not prep work. Event flyers arrive as photos. Claude reads them, extracts the details, cross-references against what’s already tracked. It caught two flyers pointing at the same venue already logged under a different name. No transcription step.
Several unrelated calendars as one system. Games, practices, fundraising deadlines, social content tied to player milestones, internal notes not meant for parents. Different domains, different audiences, merged into a single dashboard where internal-only categories stay internal by default. It has been republished a dozen times as the season filled in, each pass picking up from the current file rather than regenerating from scratch. This is the kind of overhead that normally gets abandoned by week three. It survived because maintaining it costs nearly nothing.
The actual takeaway
Nothing here required writing software. No custom tooling, no scripts, no glue code. The whole thing is Claude, some MCP connections to tools I was already paying for, and a directory of markdown and CSV files.
If you build software for a living, you already have the instincts this rewards. Keep state in files. Define a source of truth and re-sync against it. Write down decisions and the reasoning behind them. Gate the operations that are expensive to get wrong. Those habits are worth more than any specific capability, and they work fine on problems that have nothing to do with code.
The season hasn’t started yet. But the operational side is calmer than any season I’ve helped run, and it’s because I stopped treating “run a softball team” and “run a small system” as different problems.