Side project 1: Daylies

After six years at Shopify, I was excited to go back to starting new projects. Less people coordination, processes, and a wider spectrum of tasks and problems to work on.

I have a few ideas that I'm dabbling with, but first, I wanted to get into "building mode" and focus on improving my most undeveloped skill: software engineering.

Starting with a problem

I started with a simple problem that I have. I want to listen to articles, but there are a few issues with that:

• Most articles are not in audio format.

• If they are in audio format, you can only listen to them on their platform (website or app) most of the time.

• I cannot actually queue the articles in audio format from multiple sources in one place, such as my preferred podcast app.

• Some articles are just way too long and could be shortened or summarized.

I have been a big fan of Ben Thompson's small Stratechery empire, and I really love that all his written articles are also available in audio format. I don't read any of them and instead listen to all articles in my preferred podcast app.

I want the ability to turn any article into a podcast episode so that I can listen to them whenever and wherever I want.

My assumption is that if I had more articles as audio files that I find interesting, I would "read" more.

Defining the prototype

The idea seemed simple enough that I could execute it myself. It is useful to me and allows me to play around with various technologies. First, I had to build a prototype to better understand what I need, how it all works, and if I can do it myself without much help. The end-to-experience for my prototype should do that more or less:

1. Send a URL from the frontend to the backend.

2. The backend should be able to reliably scrape any website article, extract information such as title, text, and author, and save it to a database.

3. Convert the text into an audio file and host it.

4. Create and host a podcast feed.

5. Subscribe to the feed in any podcast app.

I did not work by myself but instead worked with the OpenAI API through a chat interface. However, at some point, the chat history (requests) became too long, which caused the OpenAI API to fail. I did not want to figure out how to add long-term memory, so I eventually switched to ChatGPT and Github Copilot Chat.

I have been using Next.js + Python for my app. Next.js as the frontend and Flask as the API backend. The primary reasons for that were that a lot of machine learning/AI stuff is in Python, and I wanted to brush up on my Python skills. Python is also known for having great native libraries to scrape content.

I deployed to Vercel and used Supabase for my database and to serve files.

The prototype

The final prototype is a simple browser extension that will extract the text, convert the text to audio, host it and updates the podcast feed.

Now, it will just show up as a podcast episode in my podcast app. It’s really simple, but I already love it.

The voice quality is also not bad either. See example below

Things that surprised me when building the app

It felt like playing a Text-Based Adventure Game in co-op mode with ChatGPT as my non-player character (NPC) on my team. I could not have imagined building all of this by myself without ChatGPT/Github Copilot Chat. It was incredible to be able to ask my NPC any question at any time. That takes a lot of friction away, especially for a junior engineer like me. I did not have to worry about disturbing my NPC or that I might say things not in the right way or that it is a dumb question.

ChatGPT is a great NPC, but that's all for now. My NPC was great for planning the app, creating basic frontend code such as the browser extension, and simply writing boilerplate code, but it also got a lot of things wrong. I spent a good amount of time trying to figure out what it got wrong. It made me think that for the foreseeable future, it will primarily augment engineers and not replace them. It will make it easier and faster for junior devs to level up, and for more senior devs, they will be a lot more efficient as well. I'm pretty confident that if you don't choose to use AI in your workflow, you will be less efficient in your job for sure. Is that obvious?

Text-to-Voice is expensive. Initially, I wanted to use the Google Text-to-Speech API, but it was surprisingly hard to make it work outside of Google Cloud with Python. The documentation and API were simply shit. I ended up using Play.ht, but the cost is basically 10x, and 500 words end up costing about ~50 cents, which is fine for now but makes no sense in terms of cost structure long-term. The Play.ht API is okay, but so many things in the documentation were outdated and hard to find. Meta is about to release their new Voicebox API, which looks promising, but most likely I'll have to replace Play.ht with the Google Text-to-Speech API.

Next Steps

The entire app is still very rough, but good enough for my personal use, and I will continue testing it and

More features:

• Summarise article: In order to reduce the word count and cost, I will probably integrate an LLM to summarise/shorten any articles.

• User authentication: In order for more people to use it, I need to add authentication and make it more robust in general.