go podcast()

In this episode, we dive into the dangerous "pre-launch purgatory"—that final stretch after reaching V1 but before the first paying customers arrive. It’s a period where the temptation to start over is at its peak, armed with all the lessons learned during the build. We discuss how to resist the urge to refactor your SaaS into oblivion and why shipping "imperfect" code is the only way to get the feedback you actually need.In the second half, the conversation shifts to the challenges of maintainership. My co-host shares the hurdles he’s currently facing with his open-source project, Andurel. When you’re building in a vacuum without a clear signal from users, how do you decide which features matter? We explore the shared struggle of finding a "North Star" when the feedback loop is quiet and the roadmap feels uncertain.

This week we talk about what's new with what we're working on. And as always we cover / comment what we've found intreesting or disturbing in the last week or so.

We talk to the author of Uncloud, a tool that helps with self-hosting and managing your own infrastructure / make it easy to deploy your services to your servers. Links:Uncloud on GitHub

Ramesh contacted me regarding what we've been saying lately in the pod regarding using LLM and some bad experiences we've had and maybe even some negativity etc. He wanted to give his perspective and experiences using LLMs, where it's working well for him and his team and give some tips regarding potential miss-use and what have been working good for him.

We hop into the call and start recording, and what we found, we had both issues / concerns about quality of LLM produce code. Morten is reviewing some aspect of his project before releasing the public version and found some interesting thing that would make it hard to justify leaving them there. I had very similar issues, entering into a full refactor of a Go backend server I let the LLM cook for a rare time in Go, and decided at some point that enough is enough and decided to refactor the code.It's not like it's big surprise, and I think we're a lot in that situation. When you truly start to review the code that is generated, let's just say that sometimes it's not the best work you'd have done yourself. It's quicker though, no question there. But at what cost.I also finally ditched nginx and installed Caddy for my production servers.

Andy, the creator of the Fyne toolkit returns and talk about a new visual designer for Fyne apps and a service to make building to all platform very easy. We talk about the state of Fyne, AppTrix Andy's product and how it's now possible to use a visual designer to create Fyne UI if you're more of a visual person than defining the UI via code.Links:Fyne websiteAppTrix

We give an update on our respective projects and talk about the difficulties of changing license from MIT to LGPL once there's contributions to the project.

This week we talk about multiple in-the-news topics like the SalesForce announcement that Heroku is in ~maintenance mode and we surface the big observability topic as I'm preparing to implement something basic for StaticBackend and since Morten already have this in his open source project we duscuss about ways to add this after the fct and some parts of tracing your system.

This week we're talking about the tools we're using in our day-to-day as Go software engineers. Which tools we like, of course there's always the story driven aspect of go podcast(), so there's a couple of tangents here and there ;).

We're trying something, each first episode of the month we'll talk about our respective open source projects. This episode will be more story driven than others, and you'll be able to follow our journey maintaining open source Go projects.Links:Andurel Morten's projectStaticBackend Dominic's project

Meet Morten, I said I wanted to try and bring co-hosts in 2026 to test how it feel to have co-hosts. We're starting this with a discussion on LLM and tech education and a little bit of education more extended. As someone that create courses we've all more or less felt a drop as AI and LLM are used in ~tech training or does people even still wants to get new skills and what not. It's a major concerns and like most people are realizing after using an LLM seriously, well let's just say that an expert is kind of very hard to replace, especially when it's time to learn new skills.

I'm restarting this year after a small break, go podcast() turned 4 years which is crazy, although I'd have hope to have had a better consistency publishing episodes, it is what it is ;). I'm looking at bringing co-hosts from multiple background to add some diversity to the episodes, if you're intrigued please reach out.I've also decided to un-archived and restart working on StaticBackend, my Go open source backend-as-a-service project I started in 2019. I'm missing the pace of working on a problem, thinking about it for some time and implementing a solution while adding tests etc. I've recorded this episode twice because the first time I kind of sliped into a more dark / negative mood, and that's not what I want for the pod and not how I'm feeling about bringing StaticBackend back.Go's v1 "it will build" compatibility is underrated.Links:StaticBackend (GitHub)StaticBackend (website)Act run GitHub action locallyPlease if you can talk about the podcast it would help greatly. You can always purchase my Go courses, which are 50% off for listeners: Build SaaS apps in Go | Build a Google Analytics in Go | Zero to Gopher

I asked Delaney Gillilan to return to go podcast() to revisit datastar, a very impressive tool that enable backend to push changes to the frontend of a web application. In episode 54 we covered the "what is datastar", in this episode I wanted to dive a little deeper since I personally finally started to jump and use the library in projects. I have been a dedicated user of HTMX and Alpine for a long time already and once I tried datastar I found myself capable of great interactions between the frontend and backend and mostly keep the state that made sense in the backend. It's hard to explain, you'd have to test it to realize it's true power.Links:Datastar websiteIf you'd want to support the show you may talk about it, join the Slack channel #gopodcast. You may also purchase my courses, always at 50% off for listeners of the show, my last course is Zero to Gopher.

This week I try to keep an open mind and we talk LLMs and AI with Markus Wüstenberg. Markus is a friend of the show and I noticed he was using a lot of LLM lately, I basically learn a lot by doing these podcast interviews, so I was interested to hear about what Markus is using LLM and AI in the systems he ships and also how does he uses AI as a software engineer in the day-to-day.Personally my experience so far is very mixed, sometimes it's good other it's pretty frustrating with LLMs either integrating functionalities augmented by LLMs or trying to integrate a coding agent in my day-to-day, let's just say that I'm not there yet. But I wanted to hear about someone that do have real production experiences using these things, and Markus gives a solid fundation to demistified some aspects, at least for me ;).Links:gomponents + Datastar:Markus's Claude Code skillsMarkus's own LLM abstraction layer in Go called GAIAndy Masley on AI and the environmentCharm's AI library in GoMarkus's websiteAs always if you're finding value in the pod talk about it, you may also purchase my courses, I launched Zero to Gopher 3 weeks ago, there's 50% off for listeners of the show.

Jon helped a lot of teams improve their software engineer processes. We talk about the importance of testing, having sane Ci and CD pipeline, pairing and a lot of other extreme programing concepts.Links:Tuple pair programming guide:The Mob ToolPop — Screen sharing for remote teamsIf you'd like to support the show spread the words about it, join the slack channel #gopodcast, take a Patron subscription, purchase Zero to Gopher, my latest course.