Jordan Bench

So every Christmas break when I have a couple weeks off of work, as any excited software engineer or developer, I get a wild hair and I have some time to play and experiment and build. It's honestly one of the more fun times of the year, getting to really experiment and build. This year with the wave of AI and how it's affecting the software development life cycle and building product and generating code and all the things it's doing, this was a particularly fun Christmas break.

As I self-reflect on problems that I face within the workforce and particularly in my career as a software engineer, I recognized that organizations are really excited about AI adoption and what it means to their SaaS model. Yet there's a disconnect with knowledge sharing and keeping engineering teams plugged in to the latest and greatest AI tooling. They know what things actually matter and what things are actually worth experimenting with because everyone has a finite amount of time they can allocate towards experimentation. Trying new tools and new workflows that will make them more efficient and a better employee and provide more value to the org. It's really hard to know what is worth your time.

And I sort of observed that the best engineers they sort of figure it out on their own. They experiment and they find workflows that work for them and then it ends at that. We're really bad at sharing those wins and those workflows with those around us.

At Podium we had a Slack channel called Guild AI. There was just one person that was really active in there, trying to keep everybody up to date. I saw how it sort of propelled that one person's career, going from technical support to engineering, and how people really valued his insights and his Slack messages, despite the low amount of engagement with them. They were highly valued.

Mind you that these updates were just general AI model hype. Sometimes they applied to our tech stack at Podium but for the most part it was, "Hey Anthropic came out with a new model and this is what it might mean for us," or "Hey OpenAI came out with a new model. This is what it could look like," and I just thought, "Man, we need more relevant signals in Slack and Slack being a place where we already spend our time, we're there."

At the same time I was subscribed to a handful of newsletters so that I could keep up to date with the latest and greatest and sort of be plugged in to what's happening and how that applies to software engineering so that I was on the bleeding edge.

So that's when the idea came to me. I decided I'm going to build a Slack app that lets me curate messages, sort of in a way that a newsletter would, but instead of requiring people to subscribe to my newsletter, I would get organizations to install my Slack app. Then they'd choose the channel and my same updates go out to all subscribed organizations.

That's what I set out to build this last Christmas break. I successfully was able to create the Slack app. I built a Python backend, fast API server that handles all the Slack webhooks and publishing to organizations, as well as a frontend landing page for people to find my product, sign up and pay for it, authenticate, and add the Slack app to their workspace.

So why did I build Newzlio? Why this problem?

Well for two reasons:

I wanted to take advantage of a marketplace with some distribution since that's been the biggest challenge for me.
It felt like a problem that was true to me, something I felt I wanted and I needed and I would benefit from as an engineer.

Additionally, I felt uniquely equipped to solve this problem and to helping other people was something I was excited to build.

The idea itself checked some boxes that I was looking to check with:

distribution
personal relevancy
scalability
opportunity size