Ready for an agent
One label says an AI agent can take the job from here. Agents are fast and cheap, so everything that is safe to hand them gets handed to them.
All workCase study
They had a spreadsheet.I built the rest.
64 Analytics is a college baseball and softball analytics platform. I built the pipeline that feeds it, the web app people log into, and everything underneath.
- The product
- College baseball and softball analytics
- Started from
- A spreadsheet
- I built
- The data pipeline, the web app and the infrastructure
- I ran it for
- Three NCAA seasons, with the fourth coming up
- Then
- Acquired by Rule42, October 2026
From a spreadsheet to a product somebody bought
Somebody handed me a spreadsheet. That was the product.
Today 64 Analytics is player and team rankings, advanced stats, transfer portal tracking and scouting tools, across the NCAA divisions. I built the pipeline that brings the data in, the web application on top of it, and the rest of the infrastructure that keeps both standing.
Then I ran it. Three NCAA seasons so far, with the fourth coming up. Building a thing is one skill. Keeping it up through a season, when the people using it can't wait, is a different one.
In October 2026, Rule42 acquired 64 Analytics. The numbers behind that are not mine to share. The work is, so here are three pieces of it.
The Match
The player-and-coach matching system I built for 64 Analytics Player Profiles, to aid recruiting.
Picking a college program is a big decision made with bad information. A player knows what matters to them. They usually have no way to hold every program up against it.
The Match does that. The player says what they care about, every program gets a score, and the score comes with its reasons. No black box telling a kid where to spend four years.
Change your mind about what matters, slide a setting, and the scores follow.
For the technical reader: each program is scored per category against the player's own numbers and stated preferences, with a per-category breakdown, a fit chart across eight categories, and sliders that adjust the matching criteria.
Nothing gets lost, and nothing gets started half-baked
The intake and triage system. Here is the trip every bug report and feature request takes before anyone touches the code.
It lands
Every bug report and feature request goes into one place. Not a text, not a hallway conversation, not somebody's memory.
It gets sized up
How urgent is it, on a four-step scale. How big is it, from extra small to extra large. If the report is missing something, it goes back with a question instead of a guess.
It waits its turn
Sorted work waits in a backlog with its priority on it, so the loudest request does not automatically win.
It is marked ready
Ready is its own status. Work does not start because somebody felt like starting it. The label also says who picks it up: an AI agent, or a person.
It gets built
The work goes to the part of the system it belongs to: the app customers use, the database, the nightly data import, or the play-by-play pipeline.
It gets tested
Testing is its own stop on the line, not something that happens if there is time left.
It gets reviewed
The last stop before it ships. Finished is a status somebody has to grant, not one the work awards itself.
Ready for a person
The other says a person has to. Work that needs judgement goes to somebody who has some, and it is decided before the work starts, not halfway through.
For the technical reader: it runs on GitHub issues. Needs-triage and needs-info intake, priority P1 to P4, estimates XS to XL, a status flow of backlog, ready, implementing, testing and review, a ready-for-agent versus ready-for-human split, and routing across the client app, the database, the data-import pipeline and the play-by-play pipeline.
A data pipeline that only costs money when it runs
Most of the day there is nothing for this system to do. So most of the day, nothing is switched on.
Every night
The day's data comes in.
Right after
The numbers refresh, so what people see matches what just arrived.
Then
The right people get told how the night went.
Then
The leftovers get cleaned up, so old files do not pile up.
Every hour
A watchdog checks that everything is still healthy.
On a schedule
The play-by-play pipeline, the pitch-by-pitch record of each game, checks whether there is work. If there is, it starts a machine to do it. If not, nothing starts.
No work, no machine.
The heavy machine starts only when there is work waiting for it. The bill follows the work, not the calendar.
For the technical reader: a Terraform-managed stack on AWS, built on Lambda, EC2, EventBridge and SQS. Lambdas handle the nightly data import, the refresh that follows it, notifications and cleanup. An hourly snapshot watchdog reports CloudWatch metrics. A scheduled, EventBridge-driven play-by-play pipeline starts an EC2 worker only when there is work for it.
Next upThis site, built in the openAI agents did the typing on this site. Here is what I threw out, in my own words, and the gate each release has to pass.
Got something like this on your plate? The first half hour is free, and I'll tell you straight whether you need me.