A Pet Project With a Second Purpose
I spend most of my working time in an enterprise environment. In September I launched Rival Nights, my first consumer app, as part of The Ship Monthly Challenge.
Rival Nights runs game-night leagues for friends. Cornhole, pickleball, darts, ping pong. It handles the invites, the schedule, live scores, standings, and playoffs, all in a mobile browser.
The motive was simple. I wanted to have more fun with my friends and make it easier for other groups to do the same. I also plan to give a portion of the proceeds to charity, so a league night can raise money for a cause as well as settle a rivalry.
It also gave me something I do not get in my day job: a chance to run a lean consumer launch end to end, and to see what that process could teach enterprise delivery.
Where the Pilot Stands
Rival Nights is in a limited pilot. The feedback has been good, but it is too early for numbers that mean anything, and good feedback from a small group is not proof of a market.
This post is about the process, not the product's results.
The Same-Day Release
Early in the pilot, players asked for two things: calendar integration and changes to how scheduling worked.
Both were designed, built, tested, and shipped later that day. The people who asked were shocked.
In most enterprise settings I have worked in, those two requests would take a different path. They would go into a backlog. Someone would size them. They would wait for a planning cycle, then a sprint, then a release window. A good outcome would be a few weeks. A typical one would be longer.
The speed is the part people notice. I think the bigger change is what it does to feedback. When a change costs hours instead of a sprint, small signals become worth acting on. You stop saving them for a roadmap review.
How the Pipeline Works
The pipeline is not exotic. It has four parts.
It starts with spec-driven development. Every change begins as a written spec: what the user needs, what the change does, and how we will know it works. The spec is the contract between me and the tools.
A coding agent does most of the implementation against that spec, backed by strong models (currently Claude Opus and Sonnet). Then automated testing and a pull request review check the work. Once a change passes, it deploys automatically to Vercel.
The tools will change. The shape will probably hold: a clear spec in, a reviewed and tested change out, and no manual handoffs in between.
The Part AI Does Not Replace
Quality testing and code review are not optional in this process. They matter more than they did before.
A coding agent produces a lot of plausible code quickly. Plausible is not correct. Without tests that exercise real behavior and a review that reads the change with intent, speed just means shipping defects faster.
This is where the enterprise lesson gets practical. The controls that matter are not the ones that slow work down before it starts. They are the ones that check the work after it is built. A same-day release is safe only because the testing and review are strict.
What Enterprises Are Not Set Up For
Enterprise teams can buy the same tools. Most cannot use them the same way, because the process around the tools assumes a different cost of change.
Approval gates assume building is slow and expensive, so they demand certainty before work starts. Release calendars assume deployment is risky, so they batch changes. Funding models assume a fixed scope, so they penalize learning that changes it.
Many of these controls exist for good reasons, especially in regulated industries like life insurance. But they were tuned for a world where a wrong guess cost months. When a wrong guess costs a day, some of them add more drag than protection.
I am not arguing for removing them. I am arguing for asking which ones still match the risk, and which ones only match the old cost.
I also want to be careful about the bridge. A consumer pilot has no regulators, no legacy core systems, and no policyholders depending on it. A bug in a league schedule is an annoyance. A bug in a claims workflow can hurt someone. An enterprise version of this pipeline needs stronger testing, audit trails, and human review wherever the cost of error is high.
The Skills That Made It Work
The tools were not the hard part. The hard part was knowing what to build, what to leave out, and whether the result was good.
That takes a mix of skills: creative framing to decide what the problem is, systems thinking to see what a change touches, problem solving to find causes instead of patching symptoms, and taste to know the difference between something that works and something that only runs. I wrote about these in New Skills for the New Era. Rival Nights gave me a live test of them.
My view is that a well-designed, AI-first process lets one person or a small team do work that used to take multiple teams, long delays, and very large budgets. I hold that view with confidence for a product at this scale. I do not yet have a measured comparison for a regulated enterprise platform, and I would not assume the result transfers whole.
What I am confident about is the direction. If one person can hold the whole loop, narrow specialization becomes a constraint. Depth still matters. But the premium is moving toward people who learn quickly, work across domains, and judge quality well. We need thinkers and learners more than we need a long list of niche roles.
What I Would Try Next
If you lead delivery in an enterprise, start small.
Pick one low-risk product or internal tool. Run it end to end with a small team, a spec-driven process, and AI-assisted delivery, with testing and review held to a high bar. Measure the time from user feedback to release. Then look at your approval gates against that number and ask which ones still earn their place.
I will keep running Rival Nights as a testbed and share what holds up as the pilot grows.