It was a rainy Thursday in March when I set up the webcam, pointed it at my desk, and hit ‘Go Live’ on YouTube. I had been building iCharles for months, a single‑person community platform powered by Bun, Elysia, and SQLite. The plan was simple: let people watch the process, ask questions, and maybe click a link to sign up later. I imagined the stream as a billboard, a way to turn strangers into users.
Two hours in, a comment popped up in the chat: “Hey, that query is returning duplicate rows.” I glanced at the console, saw the error, and felt a familiar sting of embarrassment. In my old life as a real‑estate agent, I could excuse a missed showing with “I’ll follow up tomorrow.” In code, that excuse is a silent bug waiting to explode in production.
The First Mistake
When I first opened the stream, I was still selling myself on the idea that I was merely “showing the work.” I talked about the UI mockups, the color palette, the way I liked the feel of Bun’s fast startup. I never intended to let the audience see the mess underneath. I kept the same habits I had cultivated in sales: I’d promise to clean up later, to refactor after the demo, to hide the rough edges until the next version.
That mindset showed up in the code. I wrote a route that handled both user registration and password reset in a single, sprawling function. I shoved a try/catch block at the bottom, promising I’d split it out later. I whispered, “I’ll fix that after the stream,” while the chat kept ticking.
The Camera’s Mirror
When you have a camera on, you become a mirror for yourself. Every keystroke is visible, every hesitation is recorded. The audience isn’t judging my voice; they’re judging the quality of the code I’m producing in real time. The moment that chat message about duplicate rows appeared, I felt a pressure I hadn’t felt in a private IDE.
I stopped the function, rewrote it from the ground up, and walked the chat through each decision. I explained why I chose a SELECT DISTINCT clause, why I added an index, and how I was now returning a single JSON payload instead of a nested object that required a second pass on the client. The chat asked, “Why not just use a unique constraint?” I paused, thought about the trade‑off, and answered honestly. I wasn’t trying to impress anyone; I was trying not to embarrass myself.
That moment changed the rhythm of the entire stream. I stopped treating the broadcast as a performance and started treating it as an audit.
Shipping Smaller, Faster
With the audience watching, I could no longer afford the luxury of a massive pull request that sat on my desk for days. The habit of “I’ll push this when I’m done” gave way to a new discipline: ship the smallest thing that works, then iterate.
Instead of building a full user profile page in one go, I released a bare‑bones endpoint that returned a user’s name and avatar. I announced the feature, let the chat test it, and collected immediate feedback. A viewer pointed out that the avatar URL was hard‑coded to my local development server. I switched to a relative path on the spot. The next hour, I added a pagination parameter to the messages endpoint, then immediately wrote a test in the console to verify the limit.
Every commit became a public promise. If I pushed a broken patch, the camera would capture the angry stare from the chat. If I shipped a clean, functional piece, the chat would cheer, and I would feel a genuine sense of progress. The fear of being caught made me double‑check every line before I saved.
The Unexpected Moat
What I thought would be a marketing gimmick turned into a moat that no competitor could easily replicate: live accountability.
Other developers can watch a polished tutorial, read a well‑written blog post, or even glance at a polished GitHub repo. But they can’t watch the messy, unfiltered process of a single person wrestling with a bug in real time. That rawness creates a barrier. Viewers learn to trust me because they’ve seen me stumble, fix, and explain every step. They know I’m not hiding a secret “magic” function that only works after a hidden refactor. They see the whole pipeline, from idea to broken query to patched solution.
The moat isn’t the content of the video; it’s the fact that I’m on camera, day after day, committing to a standard that I can’t cheat on. It forces me to write code that survives scrutiny, to document decisions in spoken language, and to keep the scope tight enough that I can finish before the day’s stream ends.
When the Camera Breaks
There was a night when my internet hiccuped and the stream dropped at 3:17 am. I was in the middle of debugging a race condition that only appeared when two users posted to the same thread simultaneously. I could have ignored it, closed the editor, and fixed it tomorrow.
Instead, I opened a new stream on a backup phone, turned on the microphone, and narrated what I was doing in plain English. I wrote the same code on a fresh terminal, explained each line, and asked the chat to help spot the flaw. Someone suggested adding a mutex lock; another proposed restructuring the database schema. Together, we isolated the bug in under ten minutes.
When the video finally came back online, I edited the clip to include the broken stream and the quick recovery. The final video showed not just a working feature, but the entire debugging dance. New viewers later told me that moment convinced them to join iCharles because they could see the honesty in the process.
What I Unlearned From Sales
In real estate, I learned to smooth over objections, to promise a future fix, to keep the deal alive with vague assurances. In code, those habits become toxic. The camera stripped me of that veneer. I could no longer say “I’ll clean this up later” without the audience immediately holding me to it.
Now, when I see a “TODO” comment, I treat it like a line item in a contract. I either resolve it before the next stream or announce it as a backlog item, complete with an estimated time frame. The audience becomes a stakeholder, and I can’t ignore them.
Conclusion
Streaming iCharles wasn’t a marketing stunt; it was a crucible. The camera forced me to write cleaner code, ship smaller increments, and stop hiding behind the promise of “later.” Live accountability became my most valuable tool, a moat that protects the quality of the product and builds trust with the community. If you’re thinking about broadcasting your build, remember: the lens doesn’t care about your pitch. It cares about the truth you write in real time.
Discussion