When Five Minutes Isn't Finished: What Gridiron Gazette Taught Me About Durable Systems

There is a specific kind of exhaustion that comes from being the production line for your own project.

I felt this most acutely during the early days of what would eventually become Gridiron Gazette.

Before we had any automation in place, producing a single weekly issue took me approximately two to three days of my available capacity every week.

Two or three days doesn't sound catastrophic until you realize that's most of a working week spent producing something that has to start all over again seven days later.

When I Was the Production Line

It wasn't just data entry. I was manually producing what amounted to a small, custom sports publication.

Every week, I created custom artwork for five fantasy matchups, featuring the teams' mascots in some form of football battle that represented who won and who lost.

I wrote the recap copy for all five matchups. I reviewed the scores and determined our weekly awards. Then I assembled all of it into the recognizable layout we'd created for the Gazette and made sure everything was formatted consistently.

The goal wasn't to automate the creativity.

The mascot concepts, the humor, the editorial judgment, and the writing were the parts of the work I valued.

The problem was the amount of human capacity required to turn those creative decisions into a finished publication.

On my best days, I could power through it. But on days when I was dealing with a migraine or simply overwhelmed by the actual work of thinking, all of those production mechanics felt like a wall.

The work itself wasn't necessarily difficult.

The system simply required me to carry the weight of the repetition every single time.

From Two or Three Days to Five Minutes

My first instinct was to stop rebuilding the publication by hand every week.

I built a process that could pull the data from ESPN and generate the finished PDF.

I also started moving recurring creative pieces into the system. Instead of creating entirely new team artwork every week, I created premade logos and visual identities for each fantasy team based on the individual owner's preferences.

And Gridiron got a reporter.

Sabre, my blue Doberman, became the Gazette's sports reporter persona, giving the publication a consistent voice and a personality of its own.

Once the backend was built, that two-to-three-day production process dropped to approximately five minutes.

That mattered for more than speed.

The Gazette still had its teams. It still had its personality. It still felt like Gridiron Gazette.

I hadn't automated the things that made it fun. I had moved the repeatable parts of its identity and production workflow into the system so I didn't have to personally reconstruct them every week.

The first automation was a huge success.

And because it worked so well, I eventually started wondering whether other fantasy leagues could have this too.

The Part I Actually Wanted to Scale

There was an obvious business reason to consider it.

If Gridiron Gazette could support multiple leagues, it had the potential to become a product and generate revenue.

But that wasn't the only reason I wanted to try.

Our recaps were fun.

Our league had developed its own little traditions around the Gazette. Every week we handed out three awards: the Cupcake Award for the lowest team score, the Kitty Award for the team that lost by the largest point margin, and Top Score for the highest-scoring team of the week.

None of that was necessary to play fantasy football.

That was precisely why it mattered.

The scores told us who won. The Gazette turned what happened into something our family could laugh about, argue over, and remember.

Sabre became part of that experience.

He wasn't just a logo or mascot attached to an automated report. I'd built him into the Gazette as our sports reporter, with his own personality and some very deliberate boundaries.

Sabre can roast a terrible play. He can be punchy. He can point out when a fantasy decision went spectacularly sideways.

He doesn't roast the actual person.

And he isn't mean.

Those rules are baked into the persona because the point is to make the league more fun, not give an automated system permission to be cruel to somebody once a week.

That boundary has become even more important as our family league has grown to include younger players. The Gazette needs to be something they can participate in and enjoy too.

That doesn't mean every future Gridiron league needs to sound exactly like ours.

The plan is to let leagues choose the moderation level that fits them, from family-friendly recaps to adult leagues that want stronger language or profanity.

The language can change.

Sabre's underlying rule doesn't.

Roast the play, not the person.

That's part of what I wanted other leagues to experience.

I wasn't trying to mass-produce our family's exact Gazette. I wanted to build something that could give another league its own teams, its own identity, its own weekly triumphs and disasters, and its own version of the fun we'd created around ours.

We Almost Took It Public

So we considered taking the automated PDF version public.

We didn't.

Before licensing ever became an issue, we'd already concluded that what worked for one family league wasn't stable enough to support multiple leagues.

There were still too many assumptions and rough edges for me to feel comfortable asking other people to rely on it.

The licensing issue surfaced later.

That timing turned out to matter.

We'd already decided not to scale simply because we could. We hadn't built a public product around the existing architecture before discovering that one of its underlying dependencies couldn't come with us.

Technical access to data doesn't necessarily mean you have permission to use it for every purpose.

Once I understood the licensing and use restrictions surrounding the ESPN and Disney data, I knew that dependency couldn't support the public product I had been imagining.

So we had to move away from ESPN.

And replacing it exposed something I hadn't understood about Gridiron itself.

I Wasn't Just Using Their Data

I hadn't just been using their data.

I had been using their math.

The fantasy scores arriving from ESPN were already calculated. As long as I accepted that finished number, Gridiron Gazette didn't need to understand how a player's football statistics became fantasy points.

ESPN was effectively a black box for that part of the system.

Gridiron received the result without needing to understand how the result had been calculated.

That wasn't a bad decision when ESPN fit the job. It was convenient, it worked, and it helped turn a process that consumed days into one that took minutes.

But once ESPN could no longer be the foundation for where I wanted the project to go, Gridiron had to understand something it had previously been allowed to ignore.

How do we actually calculate the score?

The work shifted toward nflverse, where we could start with the underlying football statistics rather than receiving ESPN's finished fantasy score.

That meant understanding the scoring system Gridiron had previously been able to take for granted.

We identified the rules our league actually used, including 1/2 PPR scoring, and began applying those scoring rules separately to the underlying statistics.

That separation opened another door.

If the base football statistics and the fantasy scoring rules were separate pieces of the system, our family's scoring configuration didn't have to be permanently baked into the engine.

The scoring engine could apply different configurations based on the statistics and rules it supports.

That wasn't the original goal.

I didn't begin this project thinking, I need to build a configurable fantasy football scoring engine.

I was trying to stop spending two or three days every week producing a family fantasy football publication.

Every Solution Exposed the Next Problem

The architecture evolved because each solution exposed the next thing I needed to understand.

The manual Gazette showed me that the production process consumed too much of my capacity.

Automation solved that problem.

Considering a public version showed me that something working for one league didn't necessarily mean it was stable enough for many.

The licensing discovery showed me that technical access wasn't the same thing as having a dependency I could safely build a public product around.

And leaving that dependency showed me that part of Gridiron's core logic wasn't actually inside Gridiron at all.

That's also why the current Gridiron Gazette app is deliberately small.

Right now, it's a beta for a single family fantasy league.

That's not because the goal ends there. It's because I've already learned the difference between something working for us and something being ready for other people.

This time, we're giving ourselves room to find the weird scoring cases, bad assumptions, broken workflows, and all the other things that only seem obvious after someone actually uses the system.

If Gridiron eventually supports other leagues, I want that expansion to happen because the foundation is ready for them, not simply because we discovered we could make it work for ourselves.

Automation Wasn't the Finish Line

We often think automation is the finish line for a durable system.

It isn't.

The first automated version of Gridiron Gazette proves that pretty well.

I took something that consumed two or three days of my week and built a system that could produce it in about five minutes.

By almost any measure, that automation was successful.

And it was.

The mistake would be assuming that because something is automated, it is finished.

The ESPN dependency worked until the product grew beyond what that dependency could support.

When that happened, I had to look deeper than the five-minute production time and ask what the system actually depended on.

Rebuilding parts of Gridiron means doing more work now because I've learned more about what the foundation needs to support later.

That's the difference between optimizing for convenience and building for durability.

Durability doesn't mean refusing to use third-party tools or deciding you need to own every piece of your technology stack.

That would create its own kind of unnecessary work.

It means understanding what you're borrowing, what happens if that dependency changes, and which parts of the system matter enough that you need control over them.

For Gridiron Gazette, scoring became one of those parts.

Once the underlying football statistics and the scoring rules became separate pieces of the system, Gridiron wasn't limited to asking another platform what a player scored.

It could take the statistics, apply the appropriate rules, and understand the result itself.

Our 1/2 PPR league became one configuration the engine could understand rather than the only way the product knew how to think about fantasy scoring.

I Was Part of the Infrastructure

And strangely enough, that brings the project right back to why I started automating it in the first place.

The original Gazette worked beautifully when I had two or three days to give it.

If I had the energy to create five matchup images, write five recaps, determine the awards, assemble the layout, fix whatever needed fixing, and get the finished issue out, everything was fine.

That was the problem.

I was part of the infrastructure.

My available time, energy, and ability to concentrate were dependencies every bit as real as an API.

If I had a migraine, if another project needed me, or if life simply ate the week, the production pipeline lost the resource it depended on.

Me.

Automation changed that.

Building reusable team identities changed it.

Giving Sabre a consistent reporter persona changed it.

Moving the production workflow into the backend changed it.

And now, moving the scoring logic into Gridiron changes it again.

Each step removes something that has to be reconstructed manually while preserving the places where human judgment actually adds value.

That's what I've come to mean when I talk about durable systems.

Building for the Weeks That Aren't Ideal

I don't want software that only works beautifully when everything around it is ideal.

I don't want a process that quietly assumes I'll always have three uninterrupted days, perfect concentration, plenty of energy, and nothing more important demanding my attention.

Because those weeks exist.

So do the other ones.

A durable system has to account for both.

The goal is to build a system that works on your worst days, not just your best ones.

About Bluedobie Dialogues

Bluedobie Dialogues is where I write about what happens while I'm actually building things: the decisions that worked, the assumptions that didn't, and the lessons that usually show up somewhere between the original idea and the finished product.

I’m Melanie Brown, owner and developer behind Bluedobie Developing. I build practical software around real problems, with a particular interest in AI, automation, accessibility, and systems that respect the humans using them.

Gridiron Gazette is one of those projects. It started as a family fantasy football publication and is currently being rebuilt as a single-league beta while I work through the scoring, architecture, and product decisions required to make it durable enough to grow.

Like this article? Buy me a cup of coffee here.