Build in public
A blog for the website, time-aware greetings and choosing a faster voice model
Today was a busy day spread across a lot of different work. I had 1 working session with coding agents, typed 35 prompts, made 8 commits and did 8 deploys over about 4 hours of active work. In total, 1357 lines of code changed. Both the voice agent and the website went to production.
A blog and changelog for the website
The biggest piece was a blog and a daily changelog for the website. That meant building a renderer, public blog pages, and a content store behind them. I also added a way to switch content off quickly. If something goes up that shouldn't be public, I want to pull it in seconds, not wait for a redeploy. Everything got tests.
I'm building this log in public, so it makes sense for the website to host it. Having a proper changelog also pushes me to write down what changed each day, which beats trying to remember it a week later.
Voice agent updates
I shipped a few updates to the voice agent:
- A demo roleplay mode, so I can show the agent in a sales conversation without needing a live business on the other end
- A change to the text-to-speech voice
- Greetings that depend on the time of day, so the agent says good morning, good afternoon or good evening
The greeting change is small, but it's the kind of thing people notice. If an agent says "good morning" at dinner time, it sounds like a recording straight away. For a voice sales agent, those first few seconds of the call carry a lot of weight.
Choosing a faster voice stack
I compared the speed of the voice stack I've been running against a newer live voice model, and decided to move to the newer model. The switch itself is still to come. In voice, speed isn't a nice-to-have. A pause before every reply makes the whole conversation feel wrong, however good the words are. Running the comparison myself, rather than guessing from what's been written about each option, made the decision a lot more comfortable.
What didn't finish
I started merging the new step-by-step onboarding flow into the live website. By the end of the day it was only partly merged, with conflicts still to clear. The onboarding work had drifted away from the main website while I worked on other things, and today's other website changes made that worse.
The lesson is an old one, but I keep relearning it: long-running parallel work gets harder to bring back the longer it sits. I shipped a lot of website changes today, and each one made the onboarding merge a bit messier. I should have merged it earlier, before stacking other changes on top.
A decision on infrastructure
I also decided to run everything on a single cloud provider. As a solo founder, every extra provider means another dashboard, another set of logs to check and another way for things to break. Putting it all in one place should make deploys and debugging simpler. That counts for more than any small advantage I'd get from spreading things across providers.
What I learned
- Merge early. Half-merged work is harder than either finished or unstarted work.
- Measure speed yourself before changing your voice stack.
- In a voice product, small touches like time-aware greetings shape first impressions.
- Being able to switch content off quickly is worth building before you need it.
Written from that day's build log: the work sessions, commits and deploys recorded for it.