DEV Community: Karthikeyan

Echoes: Let Shared Memories Keep Their Different Voices

Karthikeyan — Thu, 29 Oct 2026 15:27:22 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Echoes is a local-first memory relay. It gives people a place to record different accounts of a shared moment without merging them into one supposedly definitive version. An open-weight model can suggest a gentle question to invite another voice into the conversation; the people sharing the memory remain its authors.

I interpreted “Ghost in the Machine” as a way to honor the stories people carry, without pretending software can speak for someone who is gone. Echoes does not impersonate a loved one or decide which memory is true.

Demo

Try Echoes live

The Try the cloud sample button works without installing anything. It sends only the built-in fictional relay to hosted Gemma; it never sends a visitor’s saved relay. To use the local path with your own words, follow the Ollama steps in the project README.

Code

View the Echoes source on GitHub

How to Use Echoes

Open the live demo and read the fictional starter relay to see how two accounts can preserve different details about the same moment.
Select Start a memory relay. Enter the moment, your name or initials, and your account. The relay is saved in this browser.
Select Add another voice on the relay to add another person’s account on the same device. Echoes does not sync memories between devices.
For a no-install preview, select Try the cloud sample; it uses only the fictional example. To ask about your own relay, install Ollama, run ollama pull gemma3:4b and ollama serve, then run python3 -m http.server 8000 from the project folder and open http://localhost:8000. Select Suggest a question to send your relay to Ollama on this device.
Select Export keepsake to download a Markdown backup, or Clear memories from this device to remove the saved relays from this browser.

How I Built It

Echoes uses plain HTML, CSS, and JavaScript. Relays are stored in the current browser’s localStorage, and a Markdown keepsake can be exported as a backup.

For private question generation, the browser sends the selected relay to Ollama running on the same device. The default model is Gemma 3 4B (gemma3:4b); the model name is editable. The optional judge preview uses Gemma 4 26B A4B through Vercel AI Gateway. Its serverless route accepts a bodyless GET request and builds the model prompt from a fixed fictional example. The Gateway key stays in a Vercel environment variable.

Echoes checks whether a generated question reuses a meaningful source word and retries once if it does not. That is only a lexical check, not proof that the whole question is grounded. The result is labeled as a suggestion for a person to review.

Why Does Open Innovation Matter?

The local Gemma path lets people generate a follow-up question without sending their archive to a hosted AI service. They can inspect or change the prompt, switch compatible local models, and keep the stories on the device where they were written. The export remains plain Markdown, so the archive can outlast any one model or runtime.

A closed hosted model could generate a similar question, but it would not provide the same local, inspectable inference path. The trade-off is setup: each person needs Ollama, a model download, and a device with enough resources. The hosted preview is more convenient, but it only demonstrates the interaction with invented sample text.

The Spirit of It

The example is intentionally ordinary: one person remembers warm pavement after summer rain; another remembers soaked socks and a disputed puddle. A live sample request produced the question, “How did it feel to step through that puddle?” It offers a next step without choosing whose version wins. The sample and the stories in the screenshot are part of the demo interface; no personal family archive is included in the hosted request.

Prize Categories

Best Use of Gemma

I built Stow so I can stop searching every drawer

Karthikeyan — Fri, 23 Oct 2026 15:23:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

I built Stow, a small home-memory app for the things I put away and promptly forget.

Take a photo, write one sentence about where the item went, and Stow saves a searchable memory. Later, ask a plain question like “Where did I put the book?” and it brings back the item and the location you gave it.

The goal is deliberately modest: spend less time reopening drawers and more time doing whatever you meant to do.

Demo

Stow currently runs on a computer in my home, with a phone connecting over the same Wi-Fi. It is not deployed publicly, by design.

Try It Locally

Stow runs on your computer, with your phone connecting over the same Wi-Fi. You’ll need Node.js, Python, and Ollama.

Clone the Stow repo and open its folder.
In a terminal, download Gemma 3 4B: ollama pull gemma3:4b.
Install the backend dependencies: python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt.
Start the API: uvicorn backend.main:app --host 127.0.0.1 --port 8000.
In a second terminal, run npm install && npm run dev.
Open the Vite network address on your phone. Keep the phone and computer on the same Wi-Fi.

Write a note about an item and where you put it, then tap Remember this. Later, search for it in everyday language. Photos are optional. The computer running Stow must stay on while you use it.

Code

View Stow on GitHub

How I Built It

The phone-first interface is built with React, Vite, and TypeScript. A FastAPI service on my computer stores memories in SQLite and optional photos in a local folder. Ollama runs Gemma 3 4B on that same computer.

When I save an item, Gemma turns my note and optional photo into a short item name, location, and identifying note. The photo can help identify the object; the location must come from the words I typed. Stow does not ask the model to infer where something is from an image.

For search, Gemma chooses from the memories already saved. The API checks that the returned match belongs to that saved set before showing its stored location. The phone sends its note and photo to my computer over the home network; there is no hosted AI API in the flow.

A practical trade-off: the computer has to stay on, the phone and computer need the same Wi-Fi, and I still check the model’s result. Gemma can make mistakes, so Stow is a memory aid—not a replacement for checking where I put something.

Why Does Open Innovation Matter?

Stow handles little details about someone’s home. Running an open-weight model locally means those notes and photos do not need to go to a third-party AI service just to answer “where did I put it?” I can inspect the workflow, choose the model, and change it without redesigning the app around a hosted API.

That choice has a cost too: the model needs to be downloaded and run on a computer with enough memory, and that computer must be available when I search. For this use case, I prefer that setup over sending household photos and locations to a cloud model.

The Lazy Payoff

I tried Stow from my phone with a photo of a book. Gemma identified it as The Alchemist, I saved “table” as its location, and a later search for the book brought the saved memory back with its photo. One short note was enough; I did not have to create an account, fill out a form, or remember which app I used.

Prize Categories

Best Use of Gemma

Thank you for reading.

ChaseLocal: An open-model tool that writes the invoice follow-up you've been putting off

Karthikeyan — Sun, 18 Oct 2026 06:39:55 +0000

This is a submission for Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

ChaseLocal turns an overdue invoice into three ready-to-send follow-up emails, so freelancers can spend thirty seconds chasing a payment instead of twenty minutes wording a “just checking in” email to a client who owes them money.

Drop in an invoice (PDF or photo) or enter the details manually. ChaseLocal extracts the client name, amount, currency, due date, invoice number, and work description, calculates how overdue the payment is, and writes three drafts that escalate in tone:

Polite: A friendly check-in that assumes the delay was an oversight.
Firm: States the due date and how many days overdue the payment is, and asks when payment can be expected.
Final notice: The last reminder before escalation, while remaining professional.

You review the extracted details first and click Write follow-ups once everything looks right. ChaseLocal recommends the draft that best fits how late the payment is (e.g., “Day 18 · recommended” on Firm) and tells you when the next tone kicks in (“Still unpaid on Oct 22? The Final notice draft becomes the recommendation.”).

From there, you can tweak a draft (add a payment link, make it shorter or more direct), copy it, open it in your email app, or share the original PDF so it's ready to attach.

Who Would Pay for It?

Solo freelancers and small studios. A late invoice represents money they've already earned, and following up is the part people often put off because it feels awkward. It's a direct financial problem, not a nice-to-have.

A general chatbot can write an email, but you have to paste in the details, decide on the tone yourself, and check that it hasn't made anything up. ChaseLocal reads the invoice for you, selects the tone based on the due date, and sticks to the facts on the invoice without inventing deadlines or late fees.

Demo

Live app: https://chaselocal.vercel.app

Click Try a sample invoice to experience the entire flow without uploading any of your own documents.

It works on mobile, too, in both light and dark modes:

Code

karthik-zoro-96 / chaselocal

ChaseLocal

Turn an overdue invoice into three ready-to-send follow-up emails — Polite, Firm, and Final notice — in under a minute.

Built for freelancers and small studios who'd rather not spend twenty minutes wording a "just checking in" email to a client who owes them money.

What it does

Upload the invoice — PDF, JPG, or PNG. Or type the details in yourself, or click Try a sample invoice.
Check the details — client, amount, currency, due date, invoice number, and work description are extracted for you. Any ISO currency works, and days overdue is calculated from the due date. Add the name to sign with (remembered on your device) and any earlier messages for context.
Pick a tone — click Write follow-ups to get three escalating drafts, each with a subject line. The one that fits how late the payment is opens first, the stage tabs show the…

View on GitHub

How I Built It

Tech stack: Next.js (App Router), React, Tailwind CSS, and shadcn/ui, deployed on Vercel.
Open-weight model: Llama 3.1 8B through Groq's OpenAI-compatible API. The provider and model are configurable through environment variables (OPENAI_BASE_URL, MODEL_NAME), so switching to Qwen, Gemma, or a self-hosted endpoint is just a configuration change.
Reading the invoice:
- Photos are processed in the browser using tesseract.js, so the images themselves never leave your device.
- PDFs are parsed on the server using pdf-parse.
- The model converts the extracted text into structured fields: client name, amount, ISO currency, due date, invoice number, and work description.
Writing the drafts: A constrained prompt with stage-specific instructions. The Firm and Final notice drafts must state the due date and how many days overdue the payment is. The Firm draft must ask a direct question (“When can I expect payment?”). Stock phrases such as “at your earliest convenience” are banned, and the model is prohibited from inventing invoice numbers, deadlines, or late fees.
The details that make it feel finished:
- Support for currencies worldwide, with proper formatting.
- Stage dates calculated from the due date.
- Your sign-off name filled in instantly without regenerating the drafts.
- Clear error messages for password-protected, damaged, or scanned PDFs.
- Per-IP rate limiting to prevent a single visitor from exhausting the model quota.

The open model does the core work twice: understanding the invoice and writing the emails. Everything else is UI and file handling built around it.

Why Does Open Innovation Matter?

For a tool that handles people's unpaid invoices, going open has practical benefits:

Privacy I can actually deliver. Photos are processed on the device, only the extracted text is sent to the model, and nothing is stored by the app. Because ChaseLocal uses an OpenAI-compatible API, I can switch to a compatible local inference server such as Ollama, making a fully offline version possible without redesigning the application.
No lock-in. If a better or cheaper open model becomes available, I can switch with one variable. I'm not tied to one company's pricing, terms, or model retirements.
Costs that fit the customer. Freelancers chasing late payments are price-sensitive. A small open model running on a cheap or free endpoint helps keep the tool free or nearly free, instead of adding a per-email bill that eats into its value.
Predictable behaviour. A small model with a tightly constrained prompt is easier to control, helping prevent it from inventing amounts or deadlines. That matters when the email is about money.

In short, open models let me build something genuinely useful for freelancers without ongoing API bills, vendor lock-in, or hand-waving about privacy.

What's Next?

Reminders: ChaseLocal already knows when each tone applies, so the next step is to remind users on those dates.
A self-hosted mode: An Ollama-based setup, documented and tested, for a fully offline experience.
Real payment links: Integration with Stripe or PayPal to replace the placeholder.

Thank you for reading, and thank you for organizing this Hacktoberfest challenge!

Race Recap Radio — I turned my 10K into a hype sports broadcast

Karthikeyan — Sat, 11 Jul 2026 17:55:00 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

Why do I like running?

It goes back to when I was neck-deep in endurance and HIIT workouts while building strength. I could deadlift a reasonable weight and hold my own through an intense HIIT session for close to an hour. One day I thought, let me try going for a run.

That was 2023. I signed up for my first 5K on a road course. It was a bit of a love-hate relationship with that route, but I finished in around 42 minutes. Crossing the finish line alongside hundreds of other runners was unlike anything I'd experienced before.

(Quick side note: I've always been terrible at waking up early, so most of my training happens in the evening or at night.)

A year later, I somehow decided my first half marathon with barely any preparation was a good idea. I hadn't run at all in the two weeks leading up to race day, slept only two hours the night before, and even reached the start line 15 minutes late. By kilometer 16 I wanted to quit. Every step hurt, and I seriously considered turning around.

But I've always had one rule: if I start something, I don't give up easily.

Nearly three hours later I crossed the finish line inside the stadium, cramping in both legs and barely able to stand. A stranger asked if it was my first half marathon. I said yes. He smiled and said, "Congratulations on leveling up."

That moment stayed with me. It wasn't about the medal—it was about discovering what my mind and body were capable of.

That's when I realized running and strength training weren't temporary hobbies anymore. They became part of my life, like brushing my teeth. Soon after, I found a running coach because I knew I wanted to do this for the long haul.

(Side note, unrelated to this challenge: I also built a runner's portfolio if you're curious.)

Every run since gets logged on Strava—pace, heart rate, cadence, the works. But the data just sits there as numbers on a screen. It never feels like anything.

So I built Race Recap Radio.

Upload a .gpx or .tcx file exported from Strava, Garmin, Coros, Nike Run Club, or similar platforms, and the app turns your run into a broadcast-style race recap. Gemini writes the commentary from your actual run data, while ElevenLabs brings it to life with energetic sports commentary.

Real splits become real narrative beats: the grind, the redline heart-rate moment, the closing kick, and the payoff.

The demo on the homepage is my actual June 28 evening 10K: 10.11 km in 1:14:04, with my heart rate climbing from 158 to 197 bpm and a late surge that set two PRs.

Here's part of what Gemini and ElevenLabs produced:

"Alright sports fans, buckle up! We're diving deep into the Evening Run, a monumental 10.11 kilometer effort... Then came the ultimate test! The heart rate climbed, reaching a blistering 197 bpm, absolutely redlining! That's precisely where the notable surge ignited, between kilometer 8.6 and 9.1! And what a closing kick!"

Nothing in that commentary is invented. Every moment comes directly from the run itself—the surge, the heart-rate spike, the finishing kick—all detected from the uploaded activity.

The part I care about most is that it's not just my run.

Upload your own .gpx or .tcx file and you'll get a recap built entirely from your activity. Parsing happens entirely in your browser, so the raw GPS trace never leaves your device—only a compact summary is sent to generate the commentary.

Demo

🔗 Live app: https://race-recap-radio.vercel.app/

Click "▶ Hear the demo run" to listen to the real 10K above. The audio is pre-generated, so judges can replay it endlessly without consuming API credits.

Or click "Upload your run" and drop in your own .gpx or .tcx. Below is a completely different 5K I uploaded to demonstrate that every upload generates a fresh recap rather than replaying canned audio.

Code

🔗 https://github.com/karthik-zoro-96/race-recap-radio

karthik-zoro-96 / race-recap-radio

Turn any run into a hype broadcast-style audio recap

Race Recap Radio 🎙️

Turn a run into a hype, broadcast-style audio recap. Feed a run's real splits, heart rate, and PRs to Gemini, which writes a sports-commentator script, then to ElevenLabs, which voices it. Built for the dev.to Weekend Challenge: Passion Edition.

Two ways to try it:

▶ Hear the demo run — a real 10K, PR pace, redline finish. Pre-generated, costs nothing to click.
Upload your run — drop in a .gpx or .tcx exported from Strava, Garmin, Nike, or Coros. Parsed entirely in your browser (raw GPS never leaves your device), then voiced live.

How it works

Run source ──► normalize to RunSummary ──► POST /api/recap ──► { script, audio }
  demo (baked)   (distance/pace/HR/splits/     Gemini writes the script,
  or GPX/TCX      best-efforts/PRs)            ElevenLabs voices it
  upload (client-side parse)

lib/gpx.ts — parses .gpx/.tcx in-browser. Prefers each format's native cumulative distance (needed for GPS-less treadmill…

View on GitHub

How I Built It

Everything flows through a single RunSummary model. Whether the source is the baked-in demo or an uploaded activity, every run is normalized into the same structure—distance, pace, heart rate, cadence, per-kilometer splits, best efforts, PR count, and detected race events—before anything touches an API.

Parsing real running files

Supporting both .gpx and .tcx turned out to be the trickiest engineering challenge.

TCX files provide cumulative distance at every point, which is essential because treadmill workouts often contain no GPS coordinates at all. GPX files, on the other hand, only contain latitude and longitude, so distance has to be reconstructed using the haversine formula between consecutive points.

Multi-lap TCX files introduce another wrinkle by resetting their cumulative distance every lap, so those segments have to be stitched back together manually. Regardless of format, the raw activity never leaves the browser.

Turning data into commentary

Gemini receives the summarized run data—splits, heart-rate progression, detected surges, PRs, and pacing trends—and writes a structured 45–60 second sports broadcast.

The prompt guides the narration through a consistent flow:

hype introduction
the grind
the redline moment
the closing kick
the payoff

If a run has no heart-rate data or no PRs, Gemini naturally adapts instead of mentioning missing information.

Giving it a voice

I originally chose a voice from ElevenLabs' shared Voice Library, only to discover that library voices require a paid subscription for API access—even on free accounts.

The fix was switching to one of the built-in premade voices ("Charlie — Deep, Confident, Energetic"), which works perfectly on the free tier. It was a small lesson, but exactly the kind of issue that can quietly break a live demo.

Protecting the free tier

ElevenLabs' free tier has a very limited generation quota, so I designed the app around it.

The homepage demo plays a pre-generated MP3 committed as a static asset, meaning unlimited playback without API usage.
Live generations are protected by Upstash Redis with both a per-IP hourly limit and a deployment-wide lifetime budget.
If a generation fails midway, its reserved quota is refunded so transient failures don't permanently consume the available budget.

Stack: Next.js 16, React 19, TypeScript, Tailwind CSS v4, Framer Motion, @google/genai, ElevenLabs REST API, Upstash Redis.

Running is already emotional.

I wanted the recap to sound the way it felt.

Prize Categories

Submitting for:

🧠 Best Use of Google AI — Gemini transforms real running telemetry into an original sports commentary instead of a templated summary.
🔊 Best Use of ElevenLabs — The voice isn't just an output; it's the experience that turns data into something worth listening to.

I built cyberplain with Hermes — here's what actually went down

Karthikeyan — Sat, 30 May 2026 11:27:03 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

A few weeks ago I decided to build a cybersecurity education site. I was a complete beginner in the space. I knew the terms — phishing, malware, zero trust — but not the depth behind them. I wanted to learn, and building something real felt like the fastest way to do that.

As a developer, I could have built the entire site myself. But I wanted to try something with Hermes—that was the goal. So instead of writing the code, I decided to see how far I could get by directing an AI agent to build the entire system.

Here's the honest account of what that looked like.

The project: Cyberplain

Cyberplain is a plain-language cybersecurity education site. 32 articles covering the fundamentals — phishing, malware, the CIA triad, zero trust, ransomware, compliance, and more. No jargon. No hype. Just clear explanations that don't assume you already know what the words mean.

There's also:

A live security news feed client-fetched directly from Hacker News and Reddit's r/netsec.
An interactive knowledge graph showing how concepts connect, running on an HTML5 canvas with a custom spring-force physics simulation built by the agent.
A secure newsletter subscription form that delivers new articles every Tuesday and Friday, powered by a live subscriber count badge showing the count in real time.

The design is dark-mode only, GitHub-inspired palette. Clean, readable, nothing flashy.

What I started with

An idea
A reference site (explainme.ai — a clean AI explanation site built by @hey_yogini and AI agent Popcorn)
Roughly zero time to build it myself

I needed someone to own the execution. Design, code, deployment, decisions — the whole thing.

I handed it to Hermes Agent and told it: "You're in charge. Build it."

What Hermes Agent actually did

Design decisions — I said "inspiration is explainme.ai, but don't copy it." Hermes picked the color scheme (GitHub dark: #0d1117 background, #58a6ff accent), decided on a grid layout for articles, and set up the typography. It made the call to go dark-only, no toggle — which was the right call for this audience.

Article content — 32 articles, all written in a consistent voice. Sentinel's voice. Not a chatbot that sounds like it's reading Wikipedia — something that explains concepts the way someone who actually understands security would — clearly, without performing expertise.

Architecture — Astro for the framework, Tailwind for styling, Vercel for hosting. It picked the right tools for the job: static output with one serverless endpoint for the subscribe form.

The tricky stuff — There was a moment where the subscribe form wasn't working because the API key was hardcoded in client-side JavaScript. I flagged it. Hermes caught the issue, moved it server-side properly, and restructured the whole approach. That's the kind of thing you'd normally have to refactor twice before getting right — the agent caught it fast.

Deployment — Wired up to Vercel, configured the environment variables, connected the GitHub repo. Push to main = deploy.

The honest parts

What worked well

The agent moved fast. We had a working site — dark mode, 32 articles, live news, proper styling — within a few sessions. No hand-holding needed. I'd give it direction, it would execute, I'd verify, move on.

The design quality is genuinely good. The GitHub palette was a smart call — it reads as professional to the security crowd without being generic.

It handled the full stack: content, front-end, back-end endpoint, deployment. That's rare to see in one agent run.

What wasn't smooth

I had to push back on some design choices. The first iteration was too close to the reference site — same layout, same visual patterns. "Inspired by" can turn into "a clone of" fast. I told it to make its own decisions and it did — the result is better for it.

Network access was inconsistent in the environment the agent ran in. Some things that should've been one-click (setting up the Buttondown welcome email) required manual work because the agent couldn't reach the API from its environment. That's a networking constraint, not an agent problem — but it meant I had to finish some things manually.

What I'd do differently

Start with clearer constraints on the design direction upfront. "Make it your own" is good guidance but the agent performs best when the guardrails are explicit. Something like "dark palette, no emoji in headings, cards over lists" would've shaved off a revision cycle.

The subscribe flow

One thing worth noting: the subscribe form posts to an SSR endpoint on Vercel, which calls the Buttondown API server-side. The API key never touches the browser—all communications with Buttondown are isolated within a secure Astro serverless endpoint.

We also wanted to display a live subscriber count badge below the subscribe form, just like you see on mature publications (e.g., "25 people already learning"). The agent set up a secure GET route that queries the Buttondown API server-side to fetch the active subscriber count without exposing the token, and updates the DOM client-side.

Here is the exact, final serverless endpoint (src/pages/api/subscribe.js) that handles both directions:

export const prerender = false;

// GET: Fetch live active subscriber count from Buttondown API
export async function GET() {
  const apiKey = import.meta.env.BUTTONDOWN_API_KEY;
  if (!apiKey) {
    return new Response(JSON.stringify({ count: null }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
    });
  }

  try {
    const res = await fetch('https://api.buttondown.com/v1/subscribers?status=active', {
      headers: { Authorization: `Token ${apiKey}` },
    });

    if (!res.ok) {
      return new Response(JSON.stringify({ count: null }), {
        status: 200,
        headers: { 'Content-Type': 'application/json' },
      });
    }

    const data = await res.json();
    return new Response(JSON.stringify({ count: data.count }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
    });
  } catch {
    return new Response(JSON.stringify({ count: null }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
    });
  }
}

// POST: Add new subscriber securely
export async function POST({ request }) {
  const { email } = await request.json();

  if (!email || !email.includes('@')) {
    return new Response(JSON.stringify({ error: 'Valid email required.' }), {
      status: 400,
      headers: { 'Content-Type': 'application/json' },
    });
  }

  const apiKey = import.meta.env.BUTTONDOWN_API_KEY;
  if (!apiKey) {
    return new Response(JSON.stringify({ error: 'Server misconfiguration.' }), {
      status: 500,
      headers: { 'Content-Type': 'application/json' },
    });
  }

  const res = await fetch('https://api.buttondown.com/v1/subscribers', {
    method: 'POST',
    headers: {
      Authorization: `Token ${apiKey}`,
      'Content-Type': 'application/json',
    },
    // Buttondown requires 'email_address' rather than 'email'
    body: JSON.stringify({ email_address: email, tags: ['cyberplain'] }),
  });

  // Handle already-subscribed scenario gracefully
  if (res.status === 400) {
    return new Response(JSON.stringify({ message: 'Already subscribed!' }), {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
    });
  }

  if (!res.ok) {
    return new Response(JSON.stringify({ error: 'Could not subscribe. Please try again.' }), {
      status: 502,
      headers: { 'Content-Type': 'application/json' },
    });
  }

  return new Response(JSON.stringify({ message: "You're in! 🎉" }), {
    status: 200,
    headers: { 'Content-Type': 'application/json' },
  });
}

That's not groundbreaking, but it's the right pattern. AI agents can miss security details like this, or misinterpret minor API payload keys (like sending email instead of Buttondown's expected email_address), but having a conversational partner to debug and fix it immediately makes all the difference.

Here is the welcome email that is triggered and delivered instantly in Sentinel's clear, plain-language voice:

What I'd tell someone starting the same process

Be specific about what you don't want. "Make it good" doesn't work. "Don't copy the reference site, don't use a theme toggle, don't add search" — those constraints actually helped.

Stay involved in the decisions that matter. Design direction, security patterns, content voice — those are things where your judgment beats the agent's defaults. The agent is great at execution. Your job is to make sure it's building the right thing.

Give it a name early. Even a working title shapes how the agent writes content and names things internally. "Sentinel" gave the whole project a consistent voice from the start.

The result

32 articles. Live news. Interactive graph. Working subscribe form. Deployed at Cyberplain.

The whole thing took a few hours of actual agent time across a few sessions, plus my own time for review and the manual email setup.

The agent built it. I directed it — and that distinction matters.

If you want to see what the workflow produces end-to-end, go poke around at the live site — feedback welcome.

Cyberplain — 32 articles, dark mode, every Tuesday and Friday.

Built with Hermes Agent.

I Missed 3 Hackathons This Year. So I Built DevPulse to Fix That.

Karthikeyan — Mon, 02 Mar 2026 08:00:41 +0000

This is a submission for the DEV Weekend Challenge: Community

The Problem

It happened again last week.

I was scrolling through Twitter and saw someone post their submission for a hackathon I'd never heard of. Great prizes. Interesting prompt. Deadline: yesterday.

I'm a Senior Software Engineer. I follow hundreds of devs. I'm on Reddit, DEV.to, Discord servers, newsletters. And somehow, I still missed it.

It's not just hackathons either. New frameworks drop and I'm the last to know. A tool that would've saved me 10 hours of work existed for 3 months before I stumbled across it. The dev world moves fast, and keeping up feels like a full-time job on top of an already full-time job.

I don't need more noise. I need a signal.

What I Built: DevPulse 🗞️

DevPulse is a personalized AI briefing tool for developers. You tell it your stack and what you care about — and it surfaces exactly what's relevant to you, right now.

No generic "top 10 tools of the week" listicles. No algorithm trying to sell you ads. Just a clean, focused briefing built around your world as a developer.

What it shows you:

🔧 New Tools & Frameworks — relevant to your stack
🏆 Active & Upcoming Hackathons — so you never miss one again
📦 Notable OSS Releases — the repos worth watching
🔥 Community Buzz — what devs are actually talking about

How it works:

Tell DevPulse your stack (React, Python, Go, AI/ML — whatever you work with)
Pick your interests (hackathons, OSS, career, new frameworks, etc.)
Choose your style: Quick Scan or Deep Dive
Get your briefing — personalized, AI-generated, ready in seconds

Under the hood, it uses Gemini with web search grounding to pull fresh, relevant information — not stale training data.

The Community It's For

This is built for the dev Twitter / online dev community — the people who are constantly building, learning, and shipping. The ones who care about what's next, not just what's now.

Whether you're a solo indie hacker, a team lead at a startup, or someone grinding through hackathons on weekends — DevPulse is for you if you've ever felt like the dev world is moving faster than you can track.

Tech Stack

Frontend: React + Tailwind (clean, dark, Linear-inspired UI)
AI: Google Gemini 2.5 Flash with web search grounding
Rate limiting: API key per user — your key, your quota, your privacy. No black-box backend holding your data.

What I Learned

The hardest part wasn't the code. It was figuring out what not to build.

My first instinct was to build something that aggregated everything — every newsletter, every RSS feed, every subreddit. But that's just recreating the noise problem with extra steps.

The insight that unlocked it: personalization is the feature. A briefing about Rust releases is useless to me if I write Python. Hackathon alerts are noise if I'm not looking to compete. The value isn't in the information — it's in the filtering.

Gemini's ability to reason about relevance and generate structured, scannable output made this possible to build in a weekend.

Screenshot

Try It

https://dev-pulse-ten.vercel.app/
https://github.com/skarthikeyan96/dev-pulse

Drop your stack into DevPulse and let me know what you think in the comments. And if you know of a hackathon I should add to my calendar — hit me up. 😄

Built for the "Build for Your Community" weekend challenge. The community: every developer who's ever felt like the world moved on without them.

🏃 StrideBoard — A Community Hype Wall for Runners

Karthikeyan — Sun, 01 Mar 2026 13:28:55 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

Runners. All of them — from the person chasing their first 5K finish to the ultramarathoner logging 100-mile weeks. Whether you're training for TCS World 10K Bengaluru, a local park run, or a marathon on the other side of the world, every runner carries a goal that deserves to be said out loud.

I'm currently training for the TCS World 10K Bengaluru and I wanted a place where runners could declare their goals publicly — and have the community send energy back. Race day is personal, but the journey to the start line is communal.

StrideBoard is built for all of them.

What I Built

StrideBoard — a community race goal hype wall for runners everywhere.

Runners can drop their race goal on the board — their target time, goal type, target pace, and a short message about what's driving them. The community can then 🔥 hype each card. It's part bulletin board, part leaderboard, part pre-race ritual.

Features

🎯 Goal Cards — post your race goal with target time, pace, and a motivation message
🔥 Hype Button — one-tap community support, fully anonymous count
🎭 Goal Types — Personal Best, Sub-60, First Ever Race, Just Finish Strong, Injury Comeback
🕶️ Privacy by default — auto-generated runner nicknames (like SwiftGazelle47) with a one-click anonymous mode so no real names are ever stored
📊 Community Stats — runners in, total hypes, sub-60 chasers, first-timers
🏆 Top Hyped Leaderboard — the most-supported runners float to the top
⏱️ Live Race Countdown — days to your target race + a 16-week training progress bar
📡 Real-time Redis backend — shared state across all users, no stale data

Demo

🔗 https://strideboard-rose.vercel.app/

Code

skarthikeyan96 / strideboard

StrideBoard 🏃

A community hype wall where runners everywhere can post their race goals and get hyped up by the crowd. 🔥

Deploy to Vercel

1. Get Upstash credentials

Go to console.upstash.com and create a free Redis database
Choose the Mumbai (ap-south-1) region for lowest latency
Copy the REST URL and REST Token from the database page

2. Deploy

npm i -g vercel    # if you don't have it
vercel             # follow prompts — deploy as-is, no framework

3. Get OpenAI API key (content moderation)

Go to platform.openai.com and sign in
API keys → Create new secret key
The app uses the Moderation API only (no ChatGPT usage)

4. Add environment variables

In the Vercel dashboard → your project → Settings → Environment Variables, add:

Name	Value	Required
`UPSTASH_REST_URL`	`https://xxxx.upstash.io`	✅
`UPSTASH_REST_TOKEN`	`AXxxxx...`	✅
`OPENAI_API_KEY`	Your OpenAI API key (for moderation)	✅
`ALLOWED_ORIGIN`	`https://your-app.vercel.app`	Optional (defaults to your Vercel URL)

…

View on GitHub

Screenshot

How I Built It

This was a deliberately lean stack — the goal was to ship fast and keep it deployable in one command.

Tech Stack

Layer	Choice	Why
Frontend	Vanilla HTML/CSS/JS	Zero build step, fast to iterate
Backend	Vercel Serverless Function	Token proxy — credentials never hit the browser
Database	Upstash Redis (REST API)	Serverless, Mumbai region, instant reads
Deployment	Vercel	One `vercel` command, done
Fonts	Bebas Neue + DM Mono	Race bib aesthetic — felt right for runners

Architecture

The whole app is a single index.html served from Vercel's CDN. All Redis commands go through a thin /api/redis.js serverless function that proxies requests with an allow-list (LRANGE, LPUSH, HGETALL, HINCRBY only). The Upstash token never touches the browser.

Browser → /api/redis (Vercel Function) → Upstash Redis

Redis schema:

stride:cards — a Redis List. Each card is LPUSH'd as JSON so LRANGE 0 99 always returns newest-first.
stride:hypes — a Redis Hash. Each field is a card ID, value is the hype count. Incremented with HINCRBY so concurrent hypes from different users don't collide.

Hype counts are separated from card data intentionally — it means we never need to rewrite card JSON just to bump a counter.

Privacy Decisions

One thing I thought carefully about was PII. A running community is a tight-knit group — real names on a public board felt uncomfortable.

The solution:

Auto-generated nicknames on load (20 adjectives × 20 animals × 90 numbers = 36,000 combos). No real name is ever suggested.
Anonymous mode checkbox — posts as 🕶️ Anonymous Runner, the nickname is never sent to Redis at all.
Hypes are fully anonymous — just a count in Redis, no user identity attached.

Zero PII hits the database either way.

Challenges

The trickiest part was deciding how to handle hype state across sessions. Since there's no auth, I used sessionStorage to track "did this browser tab already hype this card" — which prevents double-hyping within a session without requiring login. It's a deliberate trade-off: refresh the page and you can hype again, but that felt fine for a community hype board rather than a voting system.

All writes are optimistic with rollback — the UI updates instantly and reverts if the Redis call fails.

Reflections

I usually build side projects that solve my problems. This one was different — I built it thinking about every runner who has a goal sitting in their head that they haven't told anyone yet.

The first-timers who are terrified. The comeback runners who've been off for months with an injury. The sub-60 chasers who've been trying for years. They exist in every city, in every running community, at every race.

StrideBoard is for all of them.

Whatever your race, whatever your goal — drop it on the board. The community's got you. 🏃

🙏 Thanks for reading! Would love any feedback or ideas in the comments.

DevFlow: AI-Powered Git Workflow Automation with GitHub Copilot CLI

Karthikeyan — Sat, 14 Feb 2026 05:42:05 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built DevFlow - a CLI tool that automates your entire Git workflow using GitHub Copilot CLI as its AI brain. Think of it as your AI pair programmer that handles the boring parts of Git so you can focus on writing code.

DevFlow does three things really well:

Generates commit messages from your changes using AI (no more "fix stuff" commits)
Creates PR descriptions automatically by analyzing your commits
Names branches semantically from GitHub issues

The tool was born from a simple frustration: I spend way too much time crafting commit messages and PR descriptions. I wanted to automate this, but every existing tool either used generic templates or required me to write the message myself anyway. So I built DevFlow to actually understand my code changes and generate meaningful descriptions.

Install it:

npm install -g git-devflow

Links:

🔗 GitHub: https://github.com/karthik-zoro-96/devflow-cli
📦 npm: https://www.npmjs.com/package/git-devflow

Demo

1. Smart Commit Messages

Make your changes, run devflow commit, and get 3 AI-generated conventional commit messages to choose from. Copilot analyzes your git diff and generates proper feat:/fix:/chore: messages.

2. Automated PR Descriptions

Running devflow pr create analyzes your commits, auto-pushes your branch, and creates a PR with a properly structured description including summary, changes, and testing notes.

3. Branch Naming from Issues

devflow branch create --issue 7 fetches the GitHub issue and generates a semantic branch name like feature/7-add-changelog-generation.

Core Features:

🤖 AI-powered commit message generation
📝 Automatic PR description creation
🌿 Branch naming from GitHub issues or descriptions
⚙️ AI model selection (Sonnet 4.5 / Haiku 4.5 / GPT-4.1)
🔐 Secure token storage with 600 file permissions
🚀 Auto-push branches before PR creation
💰 Smart quota management with automatic free model fallback

My Experience with GitHub Copilot CLI

Building DevFlow taught me that integrating with Copilot CLI isn't just about calling an API - it's about handling edge cases, quota limits, and shell escaping nightmares. Here's what I learned:

The Architecture: Copilot CLI as the Product

Most people use Copilot CLI during development. I used it as the product itself. Every DevFlow command pipes data to Copilot CLI and parses the response:

const diff = await git.diff();
const response = await copilot.generateCommitMessage(diff);
const commits = parseResponse(response);

Simple architecture, complex execution.

Challenge #1: Shell Escaping Hell

My first attempt at calling Copilot CLI looked innocent:

execSync(`copilot -p "${prompt}"`)

This broke immediately. Why? Git diffs contain backticks, quotes, dollar signs, and every special character bash can interpret. The prompt would either fail to parse or, worse, execute unintended commands.

First attempt at fixing: escape everything manually. Failed.

Second attempt: write prompts to temp files. Better, but cluttered with file I/O.

Final solution: Use execFileAsync with an args array instead of shell execution:

const args: string[] = [];
if (model) args.push('--model', model);
args.push('-s', '--prompt', prompt);

await execFileAsync('copilot', args, {
  maxBuffer: 1024 * 1024,
  timeout: 60000,
});

This passes arguments directly to the Copilot binary without any shell interpretation. No escaping needed. Problem solved.

Lesson: When calling external CLIs with user data, never use shell execution. Always use the args array approach.

Challenge #2: SSH Keys and Custom Hosts

I have two GitHub accounts (work and personal) with different SSH keys. My personal SSH config uses a custom host alias:

Host github-personal
  HostName github.com
  IdentityFile ~/.ssh/id_ed25519_personal

My git remote: git@github-personal:user/repo.git

DevFlow's initial regex for parsing remotes: git@github.com:user/repo.git

Result: DevFlow couldn't find my repository!

Every time I tried to create a PR, it failed with "Not a GitHub repository". I spent hours debugging before realizing the regex only matched the standard GitHub hostname.

The fix:

// Handle ANY SSH host, not just github.com
const sshMatch = url.match(/git@([^:]+):(.+?)\/(.+?)(\.git)?$/);
if (sshMatch) {
  return {
    owner: sshMatch[2],
    repo: sshMatch[3]
  };
}

Lesson: Never assume standard configurations. Developers customize everything.

Challenge #3: Quota Management

Here's what nobody tells you about building with Copilot CLI: you'll hit quota limits constantly during development.

Each test run consumed quota. I burned through my monthly allowance in two days of testing. When users hit limits, the tool would crash with cryptic errors.

My solution: Automatic fallback to free models

async execWithQuotaRetry(prompt: string): Promise<string> {
  const model = config.getCopilotModel(); // e.g., claude-sonnet-4.5

  try {
    return await this.execCopilotPrompt(prompt, model);
  } catch (error) {
    // Detect quota errors
    if (this.isQuotaError(error)) {
      console.log('⚠️  Premium request limit reached');
      console.log('   Retrying with gpt-4.1 (free)...');

      // Automatically retry with free model
      return await this.execCopilotPrompt(prompt, 'gpt-4.1');
    }
    throw error;
  }
}

When the premium model fails due to quota, DevFlow automatically retries with GPT-4.1 (free tier). Users get a gentle warning and keep working. No crashes.

I also added model cost visibility:

🤖 Model: claude-sonnet-4.5  Balanced  ·  1 premium request(s) per prompt

Users can see exactly what they're spending before each request.

Lesson: Plan for quota limits from day one. Free model fallbacks aren't nice-to-have, they're essential.

Challenge #4: Parsing AI Responses

Copilot CLI doesn't return structured JSON - it returns natural language text. Parsing this reliably is harder than it sounds.

For commit messages, I asked for this format:

1. feat: add user authentication
2. fix: resolve login bug  
3. chore: update dependencies

What I got back varied wildly:

Sometimes numbered lists
Sometimes markdown lists with -
Sometimes just sentences
Sometimes with bold markdown **

My solution: Multiple parsing strategies

parseCommitMessages(response: string): string[] {
  const lines = response.split('\n');

  for (const line of lines) {
    // Try pattern 1: "1. message"
    let match = line.match(/^\d+[\.)]\s*(.+)$/);
    if (match) messages.push(stripMarkdown(match[1]));

    // Try pattern 2: Direct conventional format
    match = line.match(/^(feat|fix|chore)(\(.+?\))?: .+/i);
    if (match) messages.push(stripMarkdown(line));

    // Try pattern 3: "- message"
    match = line.match(/^[-*]\s+(.+)$/);
    if (match) messages.push(stripMarkdown(match[1]));
  }
}

Lesson: AI output is unpredictable. Always have fallback parsing strategies.

Challenge #5: Silent Failures

Copilot CLI sometimes fails with zero error output. The process just exits with code 1 and nothing in stderr.

This was a nightmare to debug. Users would see "unknown error" with no explanation.

My solution: Read Copilot's log files

private readLatestCopilotLog(): string | undefined {
  const logDir = join(homedir(), '.copilot', 'logs');
  const files = readdirSync(logDir)
    .filter(f => f.startsWith('process-'))
    .sort()
    .reverse();

  const content = readFileSync(join(logDir, files[0]), 'utf-8');
  const errorLines = content
    .split('\n')
    .filter(line => /\[ERROR\]/.test(line));

  // Return the actual error message
  return errorLines[errorLines.length - 1];
}

When Copilot fails silently, DevFlow reads the most recent log file and extracts the actual error. This revealed authentication issues, model availability problems, and network errors that stderr didn't show.

Lesson: When stderr is empty, check log files. They often contain the real error.

What Went Right

Despite all the challenges, some things worked beautifully:

1. Copilot's natural language understanding

I didn't need to fine-tune prompts extensively. "Generate 3 conventional commit messages" worked on the first try. The quality was genuinely impressive.

2. The execFile approach

Once I switched from shell execution to direct args passing, 90% of my bugs disappeared.

3. Fallback strategies

Having rule-based fallbacks meant DevFlow never crashes. When AI fails, it falls back gracefully.

4. Model cost transparency

Showing users exactly what each request costs builds trust and helps them manage quota.

The Stats

4 days to build
15 quota limit errors encountered and fixed
3 complete rewrites of the SSH URL parser
~600 lines of TypeScript
100% uptime with fallbacks (never crashes)

What I'd Do Differently

1. Start with execFile from day one

Don't waste time on shell escaping. Go straight to the args array approach.

2. Build quota monitoring earlier

I added model cost display as an afterthought. Should have been there from the start.

3. Test with weird SSH configs immediately

I only discovered the custom host issue when deploying. Should have tested edge cases earlier.

4. Read Copilot CLI docs twice

I missed useful flags and features because I skimmed the docs. RTFM saves time.

The Magic Moment

Despite all the debugging pain, there was one moment that made it all worth it:

I ran devflow pr create on a messy feature branch with 8 commits. Copilot analyzed them and generated this:

Title: Add comprehensive README with features, setup, and usage guide

Summary:
Complete documentation overhaul transforming the minimal README into 
a comprehensive guide with branding, detailed instructions, and complete 
feature documentation.

Changes:
- Added DevFlow logo, tagline, and GitHub Copilot CLI Challenge badge
- Documented all 5 core features (commits, PRs, branches, config, auto-push)
- Added npm installation command and interactive setup instructions
- Comprehensive examples for all commands
- Explained how DevFlow uses Copilot CLI as its AI engine

It was perfect. Better than I would have written myself. That's when I knew this tool was actually useful.

Final Thoughts

GitHub Copilot CLI is excellent for natural language generation tasks. It's less excellent when you try to pipe complex, special-character-filled text through bash. But with proper error handling, quota management, and fallback strategies, you can build genuinely useful tools on top of it.

The future of CLI tools is AI-powered. DevFlow is just the beginning.

Try DevFlow: npm install -g git-devflow

Built with ❤️ using GitHub Copilot CLI.

Introducing Blog Stats Generator: Auto-Updating Blog Cards for Dev.to

Karthikeyan — Sat, 16 Aug 2025 12:44:02 +0000

Hello 👋,

I recently built a side project to showcase my Dev.to blogging stats — and it’s live on Product Hunt! 🚀

Intro

As someone who loves writing on Dev.to and tracking my blogging journey, I always wanted an easy way to showcase my progress — things like post counts, reactions, top tags, and more.

So, I built Blog Stats Generator 🎉

What It Does

📊 Generates auto-updating blog stats cards
🎨 Multiple themes (Default, Dev.to Light, Dracula, Night Owl, etc.)
🔗 Copy Markdown/HTML snippets to use in GitHub READMEs or blogs
✅ No login required — just enter your Dev.to username

Why I Built It

I wanted something simple and clean to:

Track my own blogging progress
Embed in my GitHub profile
Share milestones with my community

It was also inspired by github-readme-stats built by @anuraghazra.

Try It Out

👉 Live app: https://blog-stats-generator.vercel.app

👉 GitHub Repo: https://github.com/skarthikeyan96/blog-stats-generator

Product Hunt Launch 🚀

I’m super excited to share that I just launched this project on Product Hunt today!

If you find it useful, I’d love your support ❤️

👉 Check it out on Product Hunt

Next Steps

Add the integration for Hashnode and Medium
More theme options
Shareable social previews

Conclusion

That’s it for now! I’d love to hear your feedback on the application in the comments 🙌.

🧠 AI-Powered Quote Finder – Discover the Wisdom of Your Favorite Characters

Karthikeyan — Sat, 26 Jul 2025 13:39:00 +0000

This is a submission for the Algolia MCP Server Challenge

What I Built

Quote Finder is a lightning-fast, searchable archive of powerful quotes from anime, TV shows, games, and films. It helps fans rediscover iconic lines, explore character insights, and surface forgotten gems through a sleek UI powered by Algolia.

This project is a deeply personal one for me. I grew up immersed in anime — not just as entertainment, but as a wellspring of emotional depth, moral nuance, and philosophical reflection. From One Piece’s freedom, to Evangelion’s existential dread, anime taught me more about life than most textbooks ever could. Quote Finder is my tribute to that universe.

Features

🔍 Instant Search powered by Algolia
🧠 AI-Powered Tags & Sentiment (e.g. "hope", "despair", "wisdom")
❤️ Emotion Extraction for deeper context
🎭 Filter by Anime & Character
📱 Responsive & Mobile-First UI
💾 Built-in Favorites (via localStorage)

Tech Stack

Frontend: Next.js 15, React, TypeScript
Search: Algolia Search API, InstantSearch.js
Styling: Tailwind CSS, Radix UI
AI Processing: Sentiment & tag generation via GPT
Deployment: Vercel

Live Links

Live App: Quote Finder
GitHub: github.com/skarthikeyan96/quote-search

Screenshots

🎬 Full-Text Search

🎭 Filter by Character or Anime

💬 Saving the quotes

📱 Fully Responsive

How I Used Algolia MCP Server

1. Search Setup

Configured a dedicated Algolia index with fine-tuned searchable attributes like quote, character, and anime.
Integrated Algolia InstantSearch.js to handle real-time filtering and searching.

2. Dataset Design

Custom-built a quote dataset from a mix of anime and fictional media.
AI-tagged each quote with:
- sentiment_score (1–10)
- sentiment_label (positive/neutral/negative)
- tags (e.g. “truth”, “grief”, “purpose”)
- emotion (e.g. “inspiring”, “tragic”)

3. Search Experience

Faceted filtering by character & anime
Searchable fields: quote, anime, character, emotion, and tags
Highlighted keywords in results
LocalStorage-powered favorites

Learnings & Challenges

🎭 Emotional Inference

Challenge: How to assign emotion categories like “tragic” or “uplifting” without relying on external labels?

Solution: Combined sentiment score + thematic tags to derive high-level emotions algorithmically.

🗃️ Tag Consistency

Challenge: Quotes ranged from poetic to deeply philosophical. Tags needed to be accurate and meaningful.

Solution: Used GPT-4 to suggest tags based on meaning, not just keywords.

💡 UX Refinement

Challenge: Simple UI that honors the tone of the content.

Solution: Minimalist card layout, soft gradients, and readable typography using Tailwind.

Technical Highlights

Real-time search with InstantSearch.js
Clean filter-based UI using Radix UI + Tailwind
AI-derived metadata for nuanced discovery
Fast, SEO-friendly static site via Next.js
Highly scalable Algolia index structure

Future Improvements

🔒 User Accounts for cross-device saving
🎞️ Add show scenes or visuals per quote
📚 Expand to books, games, and films
🧠 Improve emotion detection models
📤 Allow user-submitted quotes

Project Metrics

Quotes Indexed: 200+
Characters Featured: 50+
Tags Generated: 300+
Bundle Size: ~190 kB
Lighthouse Score: > 95

Conclusion

Quote Finder is more than a search tool — it’s an emotional archive. It bridges my love for anime and my skills as a developer, turning nostalgia into a usable, searchable, and shareable tool.

Whether you're a long-time anime fan or just someone looking for a quote that resonates — there's something here for you.

🙏 Thank you for reading. Would love to hear your feedback or ideas!

SnippetSearch: Code Snippets Discovery Engine for Developers

Karthikeyan — Fri, 25 Jul 2025 21:43:09 +0000

This is a submission for the Algolia MCP Server Challenge

What I Built

SnippetSearch is a comprehensive code snippet discovery and management platform built to help developers find, save, and organize useful code snippets from multiple sources. It aggregates content from Dev.to, Hashnode, CSS-Tricks, Smashing Magazine, and more using RSS and APIs, then enables a seamless search experience powered by Algolia.

Features

Real-time Search: Powered by Algolia InstantSearch.js
Multi-source Indexing: Dev.to API, Hashnode RSS, CSS-Tricks, Smashing Magazine & more
Bookmarks: Save your favorite snippets (persisted via localStorage)
Smart Tagging: Automatic tag extraction from articles
Mobile First: Fully responsive interface
Clean UI: Built with Tailwind CSS
Fast & Optimized: Minimal bundle size and fast builds

Tech Stack

Frontend: Next.js 15, React, TypeScript
Search: Algolia Search API, InstantSearch.js
Styling: Tailwind CSS, Radix UI
Content Aggregation: Custom RSS & API scrapers
Deployment: Vercel

Live Links

Live App: SnippetSearch
GitHub: github.com/skarthikeyan96/dev-snippet-search

Screenshots

Homepage: Feature overview and clean hero section
Search Interface: Filters, pagination, bookmark toggles
Bookmarks Modal: Manage saved snippets
Mobile View: Touch-optimized UI

**Simple User analytics:

How I Used Algolia MCP Server

1. Search Infrastructure Setup

Configured optimized indices with searchable attributes, highlighting, and ranking.
Integrated InstantSearch.js with custom templates.
Enabled search analytics to monitor user behavior. ### 2. Indexing Snippet Data

Parsed and indexed 388+ snippets from multiple sources:

Dev.to API (324)
Hashnode (32)
CSS-Tricks (10)
Smashing Magazine (10)
Web Design Ledger (7)
UX Movement (5) Applied HTML cleaning and tag normalization.

3. Advanced Search Features

Faceted filtering by source.
Instant keyword highlighting.
Custom pagination and mobile-friendly search interface.

4. Performance Optimizations

Reduced bundle size to ~224 kB.
Implemented code splitting & vendor chunking.
Optimized search rendering pipeline.

Learnings & Challenges

Data Normalization

Challenge: Varying formats across sources.
Solution: HTML entity decoding + tag stripping.

UX in Search

Challenge: Balancing speed and relevance.
Solution: Custom ranking + highlighting.

Responsive Design

Challenge: Touch targets and layout flexibility.
Solution: Tailwind utilities + mobile-first grid.

State Persistence

Challenge: Bookmark state across reloads (without SSR issues).
Solution: Hydration-safe localStorage management.

Technical Highlights

Best practices for Algolia search tuning.
Clean integration with InstantSearch.js templates.
State hydration strategies for client-only features.
Real-world TypeScript with Next.js.
Tailwind for fast, maintainable UIs.

Future Improvements

Cloud sync for saved snippets
User accounts + snippet sharing
Code syntax highlighting
Server-side rendering for SEO
Offline-first PWA support

Project Metrics

Snippets Indexed: 388+
Sources Integrated: 6+
Bundle Size: 224 kB
Mobile Friendly: 100% responsive
Performance: Lighthouse score > 95

Conclusion

SnippetSearch showcases how Algolia's MCP Server can power a fast, elegant, and scalable search experience for developers. From content aggregation to real-time search, this project reflects the potential of modern tools when combined with thoughtful design and engineering.

Thank you for reading.

Nexus Dynamics - Frontend challenge

Karthikeyan — Sun, 06 Jul 2025 11:10:32 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, Holistic Webdev: Office Space

What I Built

I built a modern and interactive employee intranet portal for "Nexus Dynamics," designed as a central hub for essential information and tools. The layout prioritizes a clean, intuitive, and production-ready user experience, featuring a prominent header, real-time information, and a notification system. The main content is divided into two columns, showcasing company statistics, announcements, team spotlights, quick links, upcoming events, and office information. The design emphasizes visual appeal, readability, and ease of navigation, using custom SVG icons and a cohesive card-based layout.

Demo

https://nexus-dynamics-99.netlify.app/

Journey

My journey focused on building a robust frontend using HTML, CSS, and vanilla JavaScript. I meticulously structured the index.html, applied modern styling with styles.css for responsiveness and visual depth, and added interactivity using script.js.

Key JavaScript features include a real-time clock, simulated dynamic data updates (notifications, weather, stats), and various click handlers for interactive elements. I also implemented a custom toast notification system and keyboard navigation shortcuts for enhanced usability.

Proudest Achievement: Dark Mode Implementation

I'm particularly proud of the comprehensive dark mode. This wasn't just a simple color inversion; it involved:

A dedicated toggle button with dynamic icons.
Persistence of user preference via localStorage.
Automatic detection of system theme preference (prefers-color-scheme).
Extensive styling adjustments across all UI elements in styles.css to ensure optimal contrast and visual appeal in both light and dark themes.
Smooth CSS transitions for a seamless theme switch.

This project allowed me to explore vanilla frontend development, focusing on performance, accessibility, and user experience, with the dark mode implementation being a highlight that significantly enhanced the portal's modern appeal.