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.
I did not begin with a pitch deck or a market map. I began as 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 not that AI could produce code quickly. We already know that. 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.
What I can verify is stronger than a vague weekend-build claim.
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 switched on 22 hours and 49 minutes after the first commit.
The first commit itself was not a toy scaffold. It added 12,159 lines across 79 files. It already included the Astro application, account flow, data model, standings, and Stripe routes. By the end of the window, I was not looking at a generated landing page. I was looking at the bones of a business.
The product came from a problem I already understood
The important input was not a better prompt. It was proximity to the problem.
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 for places such as Pioneer Heritage Middle School and 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.
This was not “make me a volleyball startup.” It was a series of specific operational decisions an agent could implement and I could inspect.
I used agents as an operating team, not one magic chatbot
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—not merely produce a convincing answer once.
Stripe was code on day one, 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. Monthly season billing followed in the next 19 minutes, and Stripe Tax was enabled the next day. But checkout was deliberately fail-closed. A pre-payment release gate returned a 403 until the commercial and policy requirements were approved.
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 is slower than “I launched a subscription business overnight,” but it is a better operating result.
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
By September 30, 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.
Those numbers do not prove product-market fit. I have not verified subscriber or revenue numbers, and I will not turn missing data into a success claim. They prove something narrower: the system can build, maintain, audit, and deploy a real product 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.
No single agent did all of that. The speed came from handing structured work between agents without losing the evidence.
The guardrails created the speed
People often talk about guardrails as if they slow AI down. In this build, they did the opposite.
“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 did not need an agent to tell me parents had trouble following the season. I was already doing the work. AI compressed execution; it did not manufacture conviction.
Give every agent a narrow operating role
“Help with my startup” is not a role. Owning data quality, writing an SEO specification, reviewing a pull request, or measuring citation visibility is a role. Clear ownership makes 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
A functioning Checkout route is not approval to sell. A generated policy is not legal review. A passing test is not customer demand. Keep those gates visible instead of hiding them inside a launch story.
Keep the unknowns in the record
The site had 282 Search Console impressions and 16 clicks over the 28 days ending September 30. AI visibility tests had not yet produced a citation. Subscriber and revenue numbers were not verified. Those are not embarrassing footnotes. They are the baseline the next decision has 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.
But the durable part is not the 36-hour headline. It is the operating model underneath it: specialized agents, explicit authority, evidence at every handoff, automated deployment, and a human responsible for the promises.
That is where I think the next wave of small businesses will come from. Not one founder pressing a button and receiving a finished company. One operator using agents to move from a real problem to working software before the context goes stale—then slowing down exactly where trust, money, and truth require it.
