The Movie Night MVP

Pressing 'Go'

In the last article, my software factory had taken a simple vision and auto-generated a complete development plan, populating my Linear board with well structured tickets. The assembly line was built and the workers were waiting. All that was left to do was to turn it on.

I assigned the first ticket to my lead "Coding Agent" and sat down with my family to watch a movie. I was both nervous and excited. Was this entire experiment about to come together, or would it fall apart under the weight of a real-world task?

The Assembly Line in Motion

As the movie's opening credits rolled, my phone buzzed. It was a notification from the factory.

Factory Notification: "Story [API-01] is in progress. Generating business logic implementation."

Here's what was happening behind the scenes:

1. The Coding Agent read the ticket from Linear, which contained the requirements and links to the Smithy API definition and Capacitor data schema.
2. The factory had already used these definitions to generate all the boilerplate: the server stubs from Smithy, the type-safe data client from Capacitor, and the UI components from Flux.
3. The agent's only job was to generate the one function required to wire them together: take the request data, use the Capacitor client to persist it, and return the response.
4. The generated code was then passed to my (now much more efficient) "LLM Checkers" to write tests, validate security, and confirm everything compiled.

A few minutes later, another buzz.

Factory Notification: "Story [API-01] is ready for review. A temporary deployment is available at https://.... Tests are passing."

I pulled out my phone, tapped the link, and used a simple web client to test the new endpoint. It worked. Almost. The input validation wasn't quite right. I replied directly to the notification:

My Reply: "Bug: Input validation failing. Should return proper error codes."

Immediately, my phone buzzed again.

Factory Notification: "New bug ticket [BUG-01] has been created and is now in progress."

The factory had parsed my reply, created a new bug report in Linear, and assigned an agent to fix it. While I continued watching the movie, the factory was already at work on the fix, regenerating the logic with the new requirement and re-running the test suite.

This cycle repeated throughout the movie. More endpoints were completed. I tested them and reported issues. The factory fixed them. Additional features were implemented. By the time the movie's end credits were rolling, my phone buzzed one last time.

Factory Notification: "All tickets in the 'MVP' epic have been completed. The final application is deployed at https://...."

The Result

In the space of about two and a half hours, my software factory had built and deployed a fully functional, tested, and bug-fixed MVP. I had spent most of that time enjoying a movie with my family, only occasionally being pulled away by a notification to provide a quick test or a human piece of feedback.

And the punchline? I checked my cloud billing dashboard the next morning. The total token cost for the entire end-to-end process—from generating the PRD to writing the code, running the checkers, and fixing the bugs—was just under $40.

It wasn't the "no-code" dream the YouTubers had promised. It was something much more real and, to me, much more powerful. It was a true partnership between human vision and machine execution, a system that handled the tedious work and left me to focus on the important parts: the initial idea and the final user experience. I hadn't replaced a billion-dollar company, but I had built my own software factory.

In the final article of this series, I'll reflect on the complete software factory ecosystem—Smithy for APIs, Capacitor for data, and Flux for UIs—and how these generative domain languages work together to eliminate boilerplate across the entire stack.