Fixing SSR Cookie Issues & Daily-JS Call Machine — September 2, 2026

Today, I set out to address some critical issues with the SSR cookie handling and the daily-js call machine, both of which were affecting the functionality of my platform. In roughly an hour of focused work, I shipped two important fixes that not only improved the user experience but also reinforced the integrity of my system's caching mechanisms.

The first fix was related to how the gp_theme cookie was being handled for anonymous requests. It turns out that the shared nginx page caches were not varying based on the gp_theme cookie. This meant that a user visiting the site anonymously could inadvertently bake a dark-variant page into the cache, which would then be served to every subsequent visitor. This was a classic case of cache poisoning, and I knew I had to address it to maintain the integrity of the user experience. I implemented a guard that prevents SSR (Server-Side Rendering) of the gp_theme cookie for anonymous requests. This change ensures that the theme of the page is correctly rendered based on the user's preferences rather than a cached version that could misrepresent the site’s look and feel.

The second fix involved the daily-js call machine. I discovered that the enforced Content Security Policy (CSP) was causing issues with loading the daily-js default loader, which relied on eval() for fetching the call-machine bundle. The CSP allowed wasm-unsafe-eval but not unsafe-eval, leading to a situation where every Tavus portal call was failing at the join stage. This was a significant blocker, and resolving it required a deep dive into the CSP settings. I modified the loading mechanism to avoid the use of eval altogether. By implementing dailyConfig.avoidEval, I ensured that the call machine could load without running afoul of the CSP restrictions. This fix not only resolved the immediate problem but also enhanced the overall security posture of the application.

As I reflected on these fixes, I couldn't help but appreciate the learning curve involved in building this platform solo, especially with the help of AI tools like Claude Code in VS Code. While I could have opted for more comprehensive solutions or even paid for additional resources, I find that tackling these challenges on my own, with AI as my assistant, has been both rewarding and enlightening. It reinforces my long-term vision of building a one-man-show company with a billion-dollar valuation by relying on my own skills and AI capabilities rather than outsourcing every little task.

The progress made today highlights the importance of both technical precision and a deep understanding of the systems at play. Each bug fixed is a step closer to a more robust platform, and I’m proud of the strides I’m making. While I still face hurdles and dead ends—like the time I spent debugging the CSP configuration—it’s all part of the journey. I’ve learned that every fix not only improves the product but also strengthens my understanding of the underlying architecture.

Looking ahead, I’m excited to see how these fixes contribute to the broader goal of creating an agentic web experience. As I continue to refine the portal CRM and spatial AI functionalities, I’m reminded that each small improvement compounds over time. The work I do today lays the foundation for tomorrow’s success, and I’m committed to this path, however challenging it may be. Building in public means sharing both the victories and the struggles, and I hope that by documenting this journey, I can inspire others to take on their own ambitious projects, no matter how daunting they may seem.

In conclusion, the fixes I deployed today were not just technical necessities; they were crucial steps in realizing my vision for a seamless, user-friendly platform. As I gear up for the next set of challenges, I remain focused on my goal, knowing that every line of code and every problem solved gets me closer to the billion-dollar valuation I aspire to achieve.