1. Two Worlds
For a long time, software development had an unspoken boundary. Prototype and production.
The prototype was the world of trying. It just needed to work. The code could be messy. It was disposable, built only to answer: "Is this idea viable?"
Production was the world of shipping. You wrote error handling. You wrote tests. You wrote documentation. The idea validated in the prototype was rebuilt — "properly" — from scratch.
This two-phase process carries structural waste. Code written for the prototype is discarded, and the same functionality is reimplemented for production. One week for validation, two weeks for reimplementation. Of the three-week total, one week's work vanishes.
2. The Conditions for the Boundary to Disappear
If the prototype could become production directly, that one week would not vanish. It would accumulate.
This "disappearance of the boundary" occurs when three conditions are met simultaneously.
- Identical infrastructure — the environment for trying and the environment for shipping are the same
- Near-zero modification cost — the cost of elevating prototype quality to production standards is negligible
- Instant deployment — changes are reflected immediately
At TokiStorage, all three hold true.
GitHub Pages makes the development environment and production environment identical. Merge to the main branch, and that is production. Google Apps Script works the same way — save, and it is deployed. And through vibe coding, the cost of modifying code approaches zero.
3. Non-Disposable Prototypes
The problem with traditional prototyping was the assumption that what you build will be thrown away.
Code built to be discarded gives permission to compromise on quality. "We'll rewrite it anyway" justifies skipping error handling, hardcoding constants, and omitting documentation.
But in a world without the boundary, prototypes are not discarded. The very first line of code may end up in production. So a new mode emerges: "prototype at production quality."
This might sound contradictory. Surely the speed of prototyping and the quality of production are incompatible.
Vibe coding resolves this contradiction. Say "build this" to an AI, and code with error handling, I18N support, and production-grade structure appears from the start. You get the speed of a prototype with the quality of production.
4. Accumulating Trials
The true value of rapid prototyping is not speed. It is accumulation.
In TokiStorage's development, a single remark — "I'm worried about the email sending limit" — expanded into all of the following within a single conversation.
- Consolidation of admin emails (sendDailyReport function)
- Centralization into a sendEmail helper function
- SES migration roadmap document
- Lambda relay function code
- Complete scaling roadmap design
- The "Designing Migration" essay
All of these were generated, reviewed, committed, and deployed to production within a few hours of conversation. Not a single item was prototyped first and then rewritten. The initial output, after review, became production directly.
Speed is a byproduct. The essence is that every trial adds to the production asset base.
5. Building at the Speed of Thought
The ultimate form of rapid prototyping is building at the speed of thought.
The moment you think "the delivery timeline of 14 business days on the commercial transactions page isn't realistic," the Japanese and English text is updated. The moment you think "maybe the payment reminder should be 7 days instead," the GAS constant and the tokutei.html text change simultaneously. The moment you think "this could be an essay," bilingual essays are generated and a pull request is created.
The distance from thought to deployment approaches zero. In conventional prototyping, you pass through a pipeline: idea, design, implementation, testing, deployment. But with vibe coding plus GitHub Pages plus GAS, the pipeline compresses to: idea, deployment.
This compression means more than being able to try things quickly. It means that what you think of immediately becomes a production asset.
6. Freedom from the Prototype Curse
Software development has a "prototype curse."
A quickly-built prototype is well received, and the decision is made: "let's just use this." But the prototype was built with compromised quality. As it continues to serve as production, those compromises accumulate as technical debt. Eventually, the system becomes immovable.
This curse exists because there is a quality gap between prototype and production.
With vibe coding, AI generates production-quality code from the start. Code that began moving at prototype speed already has error handling, internationalization support, and proper structure. So there is no guilt in "continuing to use the prototype as-is." It was production from the beginning.
7. The Integration of Three Concepts
Rapid prototyping, vibe coding, and burn rate zero. These three are not independent concepts. Each presupposes and amplifies the others.
Burn rate zero eliminates the constraint of time.
Vibe coding eliminates the constraint of implementation.
Rapid prototyping eliminates the boundary between trial and production.
When all three are in place, "if you think of it, it is a product."
TokiStorage is the product of this integration. With zero fixed costs and no time pressure, building through dialogue with AI, trials accumulate directly as production assets. One person's judgment alone determines the shape of the product.
The goal is not to build fast.
The goal is that everything you try remains as it is.