I'm not building the next HubSpot killer. I run a handful of small content sites—one affiliate blog, a documentation site for a side project, and a newsletter archive that somehow grew a readership. Nothing sexy. Nothing that warrants a VC pitch. Just sites that need to work, stay updated, and not eat my evenings.
This month, I'm testing a few practical changes. Some are working. Some are already showing cracks. Here's what's happening.
Patching the RSS Pipeline
I killed my IFTTT recipes last year after three outages in two months. The replacement was a simple cron job pulling RSS feeds into a SQLite database, then rendering HTML. It worked fine until it didn't.
This month I swapped the cron approach for a systemd timer on a small VPS. Why? Because cron runs whenever the machine boots if you're not careful, and I got tired of checking if my feed reader had run at all on some days. Systemd timers are more reliable, log better, and survive the weird edge cases you get with cheap cloud VMs that suspend unexpectedly.
The new setup runs every 15 minutes instead of hourly. Not because I need 15-minute freshness, but because the shorter interval makes failures obvious faster. If the job fails twice in a row, I get an alert. Hourly failures were easy to miss.
Failure mode I'm watching: systemd timers on low-memory VPS instances can OOM if the feed parser hits a monster XML file. I've already seen one instance hang for ten minutes on a 2MB RSS feed from a site that apparently imports every blog post since 2008. I added a timeout to the script and a memory limit. We'll see if that holds.
AI Summaries: Keeping It Boring
I added AI-generated summaries to my documentation site last month. Not because anyone asked—they didn't—but because I was tired of scrolling through 2,000-word pages to find the one config option I needed. The summaries appear in search results and as expandable previews.
The implementation is not fancy. I'm using a small open-source model running locally via Ollama, triggered by a webhook whenever I push new content. The summary gets stored in the front matter, not generated on every page load. Static site, no runtime AI cost.
What I'm testing: whether anyone actually clicks the summaries, and whether they reduce time-on-page in a way that signals "this is useful" versus "this is broken." So far, clicks are low but not zero. Time-on-page dropped, which could mean people find what they need faster—or that the summaries are misleading. I can't tell yet.
Tradeoff: generating summaries adds about eight seconds to my build pipeline. For a small site that's fine. For something with thousands of pages, I'd need a different approach—probably batch processing during off-hours and caching.
Smarter Image Handling
Every content site has the same problem: images get uploaded at 4,000 pixels wide, wrapped in a paragraph tag, with no lazy loading and no WebP conversion. I've been there. You fix it once, then someone uploads a fresh batch and you're back to slow load times.
This month I'm testing an automated pipeline using Sharp (the Node.js image library) running in a GitHub Actions workflow. When someone pushes to the main branch, the workflow converts all images in the /content/images folder to WebP, generates responsive srcset attributes, and adds width/height metadata to the markdown files. No human steps.
The srcset generation is the part I'm still tuning. I went with 400px, 800px, and 1,200px widths. For most blog images that's overkill—most never get viewed at full width. But for my documentation site where people zoom in on screenshots, the extra sizes matter.
What broke: one of my contributors uses a CMS that auto-rotates images based on EXIF data. The Sharp pipeline strips EXIF by default, which is good for file size but broke the auto-rotation. I had to add an EXIF preservation step specifically for orientation metadata. Took an hour to track down why random screenshots were sideways.
Email Capture Without the Gating Games
I've resisted putting email signups behind content gates for years. It feels slimy. But the newsletter needs readers, and I needed a way to grow it without becoming one of those "enter your email to read the rest" sites.
This month I tried something different: inline, non-intrusive signup forms that appear after the third paragraph in long posts. Not a popup. Not a slide-in. Just a small form embedded in the content flow, matching the site's typography.
Conversion is about 1.2% of visitors who reach that point—lower than the aggressive gate approaches I've seen on other sites, but higher than my old footer-only form. The real test is whether these subscribers stick around. Previous signups from the footer had a 40% unsubscribe rate within 90 days. I'm betting that readers who see the form in context are more engaged.
What I'm skeptical about: I'm not convinced inline forms work on mobile. The positioning can feel awkward, and on small screens, it interrupts reading flow. I'm running a separate mobile variant that shows the form only at the end of the article instead of inline. Two weeks of data isn't enough to draw a conclusion yet.
Monitoring Without the Dashboard Overload
I used to run Prometheus + Grafana for my sites. It was overkill. I don't need to see request latency broken down by geographic region. I need to know if the site is down or slow.
Now I'm testing a simpler stack: a shell script that runs every five minutes, hits the homepage and three internal pages, logs the response time, and alerts me via a Telegram bot if anything exceeds 3 seconds or returns a non-200 status. The entire monitoring solution is under 100 lines of bash and costs nothing beyond the VPS it's running on.
The Telegram bot is the part that actually matters. Getting an alert that says "homepage timed out" at 2 AM is useful. Getting an alert that says "homepage CPU spike – check Grafana" is not useful when I'm half asleep. My script includes the exact URL that failed and the last three log lines. That's enough to decide whether to log in or go back to sleep.
Maintenance reality: this script has false positives when the VPS itself gets slow (which happens on cheap instances under heavy load). I'm adding a secondary check that pings the server's own health endpoint before trusting the page response times. Otherwise, I'd be waking up every time a neighbor's botnet spikes CPU usage.
What I Would Do First
If you're running small content sites and feeling the urge to "optimize" everything at once: don't. Pick the thing that wakes you up at night.
For me, that's the RSS feed pipeline—because when it breaks, I don't notice for days, and then I have a gap in content that looks unprofessional. Fix your most invisible failure first. Everything else is nice-to-have.
If your site loads slowly, start with the image pipeline. If you can't tell if your site is up, start with the monitoring script. Don't build a monitoring dashboard before you have something worth monitoring.
The point of these tests isn't to find the perfect setup. It's to find the setup that stops being a problem so you can focus on writing, building, or whatever you're actually trying to do.