🔊 Voiced by Amazon Polly You’ve probably noticed the audio player at the top of this post. That’s Amazon Polly — AWS’s neural Text-to-Speech service. Here’s how it works and why I built it the way I did. The Goal Every blog post should have a “listen” option. Audio is generated automatically when a post is published or updated — no manual steps, no third-party service. Architecture Git Push → Frontend Pipeline (Hugo build + S3 sync) → Markdown files synced to S3 (_content/posts/) → S3 Event triggers Lambda → Lambda reads HTML from S3 → Polly synthesizes speech (SSML) → MP3 saved to S3 (audio/{slug}.

🔊 Voiced by Amazon Polly Static blogs have no backend — but sometimes you still need a way for visitors to get in touch. The usual solution is a third-party service like Formspree or Netlify Forms. My solution: build everything on AWS myself. The Architecture Browser → API Gateway → Lambda → SES → Email Three AWS services, all serverless. The visitor fills out the form, Lambda validates the input and calls SES — the email lands in my inbox.

🔊 Voiced by Amazon Polly Static blogs have a problem: no interaction. Comment systems like Disqus exist, but they load third-party JavaScript, track visitors, and never quite fit the blog’s look. My solution: build a custom real-time comment section directly on AWS. The result is the widget at the bottom of this post — you can try it out right now. The Architecture Browser ←→ WebSocket API Gateway ←→ Lambda ←→ DynamoDB The key difference from a regular REST widget: WebSocket.