TL;DR: In the first 36 hours after Volleyball NT’s initial commit, AI agents helped me ship a deployed product with Stripe Checkout, authentication, analytics, policies, score reporting, and a real data pipeline. It looked like a potential new business. Turning payments on responsibly took 11 days—and that distinction matters.
The starting point was personal: I was a dad trying to follow my daughter’s middle-school volleyball team.
On September 3, I asked a tracking agent whether we should treat the local teams like a real league and make an unofficial table. The first version was a graphic. Two weeks later, that small idea had become Volleyball NT: a live North Texas standings site with hundreds of team pages, a results pipeline, parent accounts, and the infrastructure for a paid club product.
The surprising part was how quickly a group of specialized agents could move from an untidy real-world problem to an operating product system—provided I gave them clear jobs, hard boundaries, and one path to production.
This is what actually happened in those 36 hours, what took another 11 days, and what I would repeat if I were building the next small business this way.
What the 36-hour clock actually measures
I want to be precise because fast-build stories get exaggerated almost immediately.
The league-table idea came on September 3. The first Git commit landed on September 17 at 3:45 PM Central. The code had already begun before the repository existed, so I cannot honestly claim that the whole product went from a blank screen to production in exactly 36 hours.
The repository gives us a more useful, verifiable clock.
In the first 36 hours after that initial commit, the repository recorded 15 commits. The product had server-rendered pages, parent authentication, Stripe Checkout, success and webhook routes, analytics, Search Console verification, public policies, a Cloudflare deployment, an administrator portal, and parent score reporting. Stripe Tax was added to the Checkout code 22 hours and 49 minutes after the first commit.
The first commit was already a substantial application: 12,159 lines across 79 files, including the Astro application, account flow, data model, standings, and Stripe routes. By the end of the window, I was looking at the bones of a business.
The product came from a problem I already understood
Proximity to the problem was the most useful input.
School volleyball information is fragmented. A parent may need one system for a schedule, another for a final score, another for tournament information, and a group chat to understand what changed. The original need was simple: make the standings easier to follow.
That gave the agents a concrete job. Volleyball NT would be the fast, free, unofficial table a North Texas parent could open after a match. School standings, schedules, and results would stay public. A separate Club Access product could organize available club-season statistics for adult subscribers.
That distinction shaped the architecture. The public product needed real school hubs such as Reedy High School, individual team pages such as Wester 8A, district views such as the Wylie ISD standings, and tournament pages. Results needed sources and correction paths. Parent-reported scores had to remain provisional until an authoritative source confirmed them. The paid product needed adult authentication, team selection, Stripe subscriptions, cancellation handling, and gated access.
The assignment became a series of specific operational decisions an agent could implement and I could inspect.
I used agents as an operating team
The system works because the agents have different jobs.
A CMO agent runs the marketing plan and gates work. A volleyball marketing agent owns results and data quality. An SEO and AEO agent writes technical specifications and audits what shipped. An AI visibility agent tracks whether answer engines mention or cite the site. Regional results desks cover assigned areas. Cursor cloud agents write code and open pull requests. I review and merge.
The roles matter more than the model names. Each agent owns an object and an outcome.
The data agent does not deploy application code. The coding agent does not invent a score. The SEO agent can write a specification but does not silently rewrite production data. GitHub Actions deploys only after code reaches main. The operating rule in the repository is explicit: never run a production deploy command from an agent shell.
That separation gave the system speed without turning it into an untraceable swarm. Every code change had a branch, a pull request, checks, a merge, and a production build. Every result needed provenance. Unknown information stayed unknown.
It is the same lesson we found while testing a month of AI coaching overnight: an AI interaction can look excellent while the longer system still fails. The workflow has to preserve memory, authority, and state across many actions while producing reliable outcomes over time.
Stripe code was not permission to charge
The fastest way to ruin this story would have been to confuse “Stripe code exists” with “the business is ready to take money.”
Checkout, success, and webhook routes were present in the first commit. A monthly-billing pull request opened 19 minutes later, although that pull request was never merged. Stripe Tax was added to the Checkout code the next afternoon, 22 hours and 49 minutes after the first commit. Checkout remained deliberately blocked behind a pre-payment release gate.
Paid Club Access did not open during the 36-hour window. It opened 11 days after the first commit, once live Stripe configuration was confirmed and the pricing, terms, cancellation rules, support route, coverage language, and team-selection flow were in place.
That delay was part of operating responsibly.
Speed is useful when it shortens the distance between a decision and tested software. It is dangerous when it removes the decisions. Payments, privacy, source authority, and claims still need an accountable human.
The agents kept working after the initial sprint
The operational figures in this section are snapshots as of September 30, 2026.
By then, the repository had 31 pull requests, with 28 merged. The median time from opening a merged pull request to merging it was 12.9 minutes. Eighteen pull requests came from Cursor cloud agents. Since the deployment workflow went live on September 25, 20 successful production deployments had run automatically, with a median duration of about 68 seconds.
The live product had a 466-URL sitemap, including 358 team pages, 76 school pages, 10 district pages, and nine tournament pages. Its public catalog covered 14 North Texas school districts, 673 teams, and 550 posted finals. Free school coverage sat beside a paid Club Access offer at $4.99 per month or $49.99 per year.
The response started immediately. GA4 had recorded 43 sessions by September 24, and Search Console showed 282 impressions and 16 clicks by September 30. I’m not sharing subscriber or revenue figures here. These early signals show that the system can build, maintain, audit, deploy, and begin attracting traffic with a very small amount of human coordination.
One afternoon showed the full operating loop
September 30 was the clearest example of the system behaving like a team.
An SEO audit found thousands of parameterized links, duplicate-title groups, and important pages that search engines had not indexed. The data agent repaired bad result states, venue names, and game types, and restored 89 of 90 available MaxPreps finals. The SEO desk converted its findings into implementation specifications. Coding agents opened pull requests for redirects, sitemap cleanup, title and description changes, structured data, and filtering deleted games.
Three changes reached production in 33 minutes. One agent reconciled a branch after another pull request merged. CI passed. I merged. GitHub Actions deployed each approved change in roughly one to two minutes. The live site was then checked for the new sitemap, redirects, titles, and structured data.
Structured handoffs preserved the evidence while different agents completed each part of the job.
The guardrails created the speed
Guardrails made this pace possible.
“Do not invent scores” meant the data agents did not debate what to do with a blank result. They left it blank. “Deploy only from main” meant coding agents did not need to choose a release path. “Parent reports stay provisional” kept community input separate from official standings. “Paid sales stay off until approved” separated technical readiness from commercial readiness.
The rules removed ambiguity from routine work. That let the agents move faster on everything that was safe to automate.
I still owned the consequential decisions: what the product promised, when payments could open, which changes merged, how family privacy was handled, and whether the evidence supported a public claim.
What I would repeat on the next AI-assisted business
Start with a problem you touch yourself
I already knew parents had trouble following the season because I was doing the work. AI compressed execution; it did not manufacture conviction.
Give every agent a narrow operating role
Assign concrete ownership: data quality, an SEO specification, a pull-request change, or citation visibility. Clear roles make outcomes and handoffs inspectable.
Build one boring path to production
Branch, pull request, required checks, merge, automatic deploy. The pipeline should be less creative than the product. Agents can work quickly when release mechanics are predictable.
Separate technical readiness from business readiness
Treat Checkout, policies, tests, customer demand, and commercial approval as separate gates. Working software clears the technical gate. The other decisions still require their own evidence and owners.
Keep the unknowns in the record
AI visibility tests had not yet produced a citation by September 30. That baseline gives the next decision something concrete to beat.
Thirty-six hours can create leverage, not certainty
Volleyball NT began with a parent asking for a better league table. AI agents helped turn that need into a deployed, Stripe-ready product system at a speed I would not have considered realistic a year earlier.
The operating model underneath the headline is what makes the result durable: specialized agents, explicit authority, evidence at every handoff, automated deployment, and a human responsible for the promises.
I think this is where many of the next small businesses will come from. An operator can use agents to move from a real problem to working software before the context goes stale—then slow down exactly where trust, money, and truth require it.
