DEV Community: David Rueda

I built an Astro theme with a perfect 100/100 Lighthouse score and Enterprise SEO (Open Source)

David Rueda — Fri, 25 Sep 2026 10:43:27 +0000

When building a website for a B2B SaaS or a startup, everyone tells you that SEO and performance are crucial. Yet, when you look for a starter template, most of them look beautiful but fail miserably under the hood: no proper structured data, duplicate content issues, heavily bloated JavaScript, and terrible Lighthouse scores.

I got tired of wrestling with Core Web Vitals and fixing missing hreflang tags on every new project. So, I decided to build the ultimate solution from scratch.

Today, I’m open-sourcing Astro SEO Theme.

It is a premium, 100% free, and open-source website template engineered specifically to dominate search engine rankings and generative AI engines (GEO).

druedaro / astro-seo-theme

An ultra-fast, SEO-first blog template for Astro. Features automatic JSON-LD, i18n, Open Graph image generation, and 100/100 Lighthouse scores. Built for AEO and GEO.

Astro SEO Theme

The ultimate open-source SEO theme for Astro, designed for B2B SaaS and Enterprise.

Astro SEO Theme is an open-source website template built with Astro, Tailwind CSS v4, and React. You get a highly-optimized landing page, dynamic blog, case studies section, and enterprise-grade SEO tooling in one repo. It's designed so you can launch a premium web presence for a B2B SaaS or startup just by editing content, instead of wrestling with Core Web Vitals from scratch. Unlike generic themes, it ships with an incredibly strict SEO setup, multilingual i18n, security headers, and CI pipelines already wired up.

Live demo: astro-seo-theme.vercel.app

Validated perfectly for Mobile & Desktop Performance, Accessibility, Best Practices, and SEO.

Three content hubs in one. High-converting landing page, markdown-driven blog, and case studies portfolio, all sharing a single responsive layout and megamenu.
Enterprise-grade SEO.…

View on GitHub

🚀 Why another Astro theme?

Astro is already incredibly fast, but speed is only half the battle. To rank well in 2026, you need proper metadata, schema markup for Rich Snippets (AEO), and localized routes to avoid duplicate content penalties.

I built Astro SEO Theme to solve all of this out of the box. You get three content hubs (a high-converting Landing Page, a Markdown-driven Blog, and a Case Studies portfolio), all sharing a unified architecture.

🔥 Killer Features

Here is what makes this theme different from generic templates:

Zero-JS by Default (100/100 Lighthouse): Built using Astro Islands. We ship exactly 0 KB of client-side JavaScript unless it's strictly necessary (like for the React-based dark mode toggle).
Enterprise-Grade SEO: It automatically generates centralized hreflang tags, dynamic JSON-LD structured data (for Articles, Breadcrumbs, and FAQSchemas), auto-generated sitemaps, and canonical URLs.
Multilingual Ready (i18n): File-based routing makes it trivial to scale globally. It currently ships with complete English and Spanish implementations.
Author E-E-A-T Support: Dedicated JSON collections for authors to establish expertise and trust with Google's search algorithms.
Modern Stack: Powered by the latest and greatest: Astro, Tailwind CSS v4, and React.
Production Hardened: Includes a strict Content Security Policy (CSP) and security headers configured for Vercel deployments.

🛠️ How to get started

You don't need to clone the repo manually. You can scaffold a new project directly using the Astro CLI in seconds:

npm create astro@latest -- --template druedaro/astro-seo-theme my-saas-website
cd my-saas-website
npm install
npm run dev

If you want to see it in action first, check out the Live Demo.

🙌 Let me know what you think!

I built this to save developers and founders dozens of hours of technical SEO configuration. I would love to hear your thoughts, feedback, or feature requests.

If you find it useful for your next project, dropping a ⭐ on GitHub would mean the world to me!

Happy building! 🚀

I Built a Voice-First AI Sports Journal (And Why I Didn't Over-Engineer It)

David Rueda — Fri, 28 Aug 2026 11:15:08 +0000

There is a fundamental problem with fitness tracking apps today: friction.

After a grueling workout, when your hands are sweaty, your heart rate is 160 BPM, and you are trying to catch your breath, the absolute last thing you want to do is open an app, navigate through five different dropdown menus, search for the exact exercise variant you did, and type out how you felt on a tiny mobile keyboard.

Because of this friction, most of us either default to raw data (Apple Watch rings) which lacks context, or we stop tracking our subjective experiences entirely.

That’s why I built Trainlog — a voice-first sports reflection journal that uses AI to understand your training through natural speech. You just hit record, talk about your session for 15 seconds ("I ran 5k today, felt great but my calves are tight"), and the app transcribes it, extracts structured metrics (fatigue, sleep, emotions), and builds a persistent calendar history.

But this isn't just a product pitch. Building an AI wrapper in 2024 is easy. Building a production-ready AI application that feels native, respects user privacy, and doesn't break when the LLM hallucinates is hard.

When planning the architecture, it was tempting to fall into the classic AI trap: vector databases, multi-agent orchestrators, and infinite LangChain wrappers. Instead, I chose a boring, robust stack: React 19, Firebase, Tailwind, Zod, and Groq (Whisper + Llama 3).
Here are the 7 technical lessons I learned building a resilient AI app without over-engineering it.

1. Voice is the ultimate UI, but it needs a safety net

The core interaction of Trainlog relies on the browser-native MediaRecorder API to capture audio, which is then sent to a Vercel Serverless Function and processed by Groq's Whisper model.

Whisper is incredibly fast and accurate, but ambient gym noise or heavy breathing can still confuse it. Initially, I passed the transcription directly to the AI for analysis. This was a mistake. If the transcription missed a "not" (e.g., "I did not sleep well"), the entire analysis was poisoned.

The Fix: Human-in-the-loop. Before any AI analysis happens, the user is presented with the raw transcription in an editable text area. They can fix typos or add context before hitting "Analyze". Never trust raw sensory input without giving the user the steering wheel.

2. You don't need a complex Agent framework (Just Prompt + Zod)

When you start building AI features, every tutorial tells you to use a heavy agentic framework. But for extracting structured data (Activities, Intensity, Fatigue level, Emotions), a massive agent graph is pure overhead that introduces latency and points of failure.

Instead of an agent, Trainlog relies on Strict Schema Validation. I defined the exact TypeScript interfaces I needed for the frontend, translated them into a Zod schema, and instructed Llama 3 to output raw JSON matching that exact shape.

When the response hits the server, Zod parses it. If the LLM hallucinates a string where a number should be for the "fatigue" metric, Zod catches it, the server gracefully handles the error, and the UI doesn't crash. Strict boundaries > Complex Agents.

3. PWA is the secret weapon for solo developers

I wanted Trainlog to feel like a native app on iOS and Android — full screen, no browser UI, offline capabilities, and an app icon on the home screen.

Instead of rewriting the codebase in React Native or Swift, I used vite-plugin-pwa. With a simple manifest.json and a Service Worker, Trainlog became installable. To make it feel truly native, I implemented Mobile-First UI patterns: bottom navigation bars on mobile, side navigation rails on tablets/desktop (md:flex-row), and smooth CSS micro-animations (animate-in fade-in).

If you are a solo developer building a consumer app, don't build two codebases. Build a spectacular PWA.

4. Push Notifications on the Web are finally viable

One of the biggest missing pieces of Web Apps used to be engagement. Users forget to log their workouts. I needed a daily reminder system.
Thanks to Firebase Cloud Messaging (FCM) and the Web Push API, Trainlog now asks for notification permissions during the onboarding flow. If granted, the frontend registers a Service Worker (firebase-messaging-sw.js), securely stores the FCM token in Firestore, and a Vercel Cron Job runs every evening at 20:00 to ping users who haven't logged a session that day.

Getting Apple to play nice with Web Push on iOS was a journey, but it works flawlessly now.

5. AI features must be rate-limited from day one

When you expose an endpoint that calls an LLM, you are essentially putting an open tab at a bar on the internet. If a malicious user or a bot spams your /api/analyze endpoint, your API bills will skyrocket.

I didn't want to build a complex queueing system, so I reached for Upstash Redis. With just a few lines of code in the Vercel Serverless functions, I implemented a sliding window rate limiter. If an IP or User ID requests more than 10 analyses per minute, the server responds with a 429 Too Many Requests. It’s a 5-minute implementation that saves you from a massive headache.

6. Gamification shouldn't cause anxiety

Health and fitness apps love "Streaks" (doing something for X consecutive days). But streaks are psychologically punishing; if you get sick or take a rest day, losing a 100-day streak feels devastating and often causes users to abandon the app entirely.

For Trainlog, I built a gamification system based on Milestones and Exploration, not just consistency. Users earn badges for emotional resilience (logging after a bad day), exploration (trying new activities), and total volume, rather than punishing them for breaking a chain. The logic is handled seamlessly on the backend when saving an entry, comparing their historical Firestore data against achievement criteria.

7. Data Privacy is a feature, not an afterthought

When dealing with health data, sleep metrics, and personal reflections, privacy is paramount.

I architected Trainlog with strict Firebase Security Rules to ensure per-user data isolation. But more importantly, I applied PII Sanitization before the data ever reaches the LLM.
Regular expressions scrub potential phone numbers, emails, or IDs from the voice transcripts before they are sent to Groq. Furthermore, no entry is ever saved to the database until the user explicitly reviews the AI's analysis and clicks "Confirm". If they delete their account, a cloud function wipes their entire Firestore document tree instantly.

The Boring Stack Wins Again

If there’s a single takeaway from building Trainlog, it’s this: Start with the smallest stack that solves the problem.
I didn't need a vector database because users can filter their calendar history by date and activity natively in the UI. I didn't need a heavy memory layer because the AI Coach ("Anna") simply loads the user's recent Firestore history into the system prompt context window.

Complexity is easy to add and brutally hard to remove. The best AI apps aren't the ones with the most impressive architecture diagrams. They are the ones that solve a real user problem with zero friction.

Try it out!

I’ve open-sourced the entire project. You can check out the code, steal the prompt architecture, or just use the app to track your next gym session.

🌐 Live Demo: trainlog-journal.vercel.app
💻 GitHub Repo: github.com/druedaro/trainlog
Portfolio: davidrueda.vercel.app

I’d love to hear your thoughts! Have you fallen into the AI over-engineering trap recently? Drop a comment below or let me know what you think of the app. Happy coding (and training)! 🏋️‍♂️