This Syntax episode is basically therapy for anyone with a side-project folder full of half-built ideas, weird experiments, and one app you definitely were going to finish in 2021.
Wes and Scott talk about the messy middle of side projects: where ideas come from, how to decide what’s worth building, and the difference between making something to learn, making something to sell, and making something because your brain won’t shut up until you try it.
The examples are the good kind of nerdy. Wes is playing with a thermal receipt printer so Sentry errors can print out like kitchen orders, which is completely unnecessary and therefore excellent. Scott is working on a Syntax production assistant app to chew through the boring parts of their workflow. There’s also talk about local-first apps, breakdancing tools, habit trackers, and the sort of personal software that only exists because one person got mildly annoyed enough to build it.
That’s the bit I liked most.
The episode doesn’t treat every side project like it has to become a startup. Sometimes the point is to learn Rust, Tauri, Svelte, IndexDB, or whatever shiny thing has lodged itself in your brain this week. Sometimes the point is to solve your own stupidly specific problem. Sometimes there might be money in it. Sometimes there absolutely won’t be, and that’s fine too.
There’s also a useful reality check around choosing tech. If the goal is to learn, go wild. Use the new thing. Break stuff. Make a mess. But if the goal is to actually finish the project, maybe don’t spend three weekends rebuilding the stack because another framework winked at you from Hacker News.
I say this as a man with folders that could be used as archaeological evidence.
The practical takeaway is simple: side projects work better when you know what job they’re doing. Is this for learning? For fun? For money? For solving one annoying workflow? For testing an idea quickly before it grows legs and starts demanding OAuth?
Once you know that, the whole thing gets easier to steer.
This is a good listen for solo builders because it’s not really about “launching big”. It’s about noticing small problems, following curiosity, and using code to make something that didn’t exist yesterday.
Which, even when the project is ugly, unfinished, or useful to precisely seven people, is still a pretty decent use of a developer brain.