PromptCast started because I wanted my desktop to appear the right way round in a teleprompter. It grew into a Windows-to-Android streamer with touch input, audio, and dictation. An AI coding agent wrote the code; I directed the work and tested it on my hardware.
The video could work while the microphone clicked or Windows Explorer crashed. Both problems are in that project’s write-up. Plausible fixes kept missing the cause. I asked for a recorded waveform to investigate the clicks and logging that could show what happened before Explorer died.
Those failures changed what I needed to check. Streaming video was enough to demonstrate the idea. To keep using it on my own computer, I needed the audio and input features to behave too. I would be living with whatever problems we left behind.
I like reaching a working prototype while I’m still interested in the idea. PromptCast also made me consider what I’d be taking on by keeping it.
Give the experiment a question#
Before building a prototype, I want to know what I expect to learn. Testing whether an interaction is understandable may need a convincing screen and no real backend. Testing whether a technical approach is possible may need an ugly implementation and a careful measurement. Sometimes I’m making a tool for myself, and learning from it is enough reason to continue.
The scope should follow that purpose. Otherwise, every feature that’s easy to add becomes another feature to evaluate. The prototype gradually takes on the obligations of a product without anyone deciding to support one.
I also consider an existing tool, a smaller change, or leaving the problem alone for now. Being able to build quickly makes another option available; I still need to compare it with those choices.
Leave room to decide against it#
A polished prototype makes continuing appealing. There’s already something to show, and another improvement is within reach.
I try to judge the next investment by the problem the project solves, the people it helps, and the cost of supporting it. The demonstration is evidence in that decision. A clear written proposal deserves consideration on the same terms, even if nobody has built it yet.
A prototype can do its job by showing that an idea is awkward to use, expensive to maintain, or less useful than expected. Stopping there is a result I want the experiment to allow.
Make the next change possible#
Once I decide to keep a project, I need to be able to understand and change it later, even if the first version took little effort.
Version control lets me inspect changes and compare or return to earlier versions. That’s useful when an AI agent makes several edits at once. The Git book’s introduction explains how that history helps.
A fresh checkout also needs a documented route to a working environment. For a Node project, a committed lockfile and npm ci help make dependency installation consistent. The command rejects a mismatch between the manifest and lockfile instead of quietly updating the lockfile. Reproducing the environment also depends on the runtime, configuration, and other services the application needs. npm documents the installation behavior here.
The remaining work depends on who uses the product. I need to decide which failures matter enough to test, where credentials belong, and how to release a change and recover if it goes wrong. A tool I use alone and a service other people depend on need different levels of preparation.
I want to try those steps: set up the project again, change it, catch a meaningful failure, and recover from a bad release. Checking off a list without demonstrating them would leave me guessing about whether they work.