DEV Community: Sh Raj

Why Hand-Drawn Portfolios Are Making a Comeback in 2026 ✏️

Sh Raj — Tue, 23 Jun 2026 19:25:09 +0000

Why Hand-Drawn Portfolios Are Making a Comeback in 2026 ✏️

For years, the web has been obsessed with the same design trends:

Glassmorphism
Dark mode
SaaS-style landing pages
Minimal portfolios

The result?

Most portfolios look nearly identical.

That's why hand-drawn and illustrated websites are becoming increasingly popular again.

They feel personal.

They feel memorable.

And most importantly—they don't look like everyone else's website.

The Problem With Modern Portfolios

Recruiters, clients, and visitors browse hundreds of portfolios every month.

Most are forgotten within seconds.

Not because the work is bad.

Because nothing stands out.

A portfolio should communicate personality before visitors even start reading.

That's exactly where illustrated designs shine.

Meet Kraft — Premium 3D Hand Drawn Portfolio Theme

Kraft combines modern web design with handcrafted illustrations and 3D elements to create a portfolio that instantly feels unique.

Instead of another generic template, visitors experience a creative environment that feels designed specifically for a human, not generated from a design trend.

Why Hand-Drawn Design Works

Hand-drawn interfaces create something most websites lack:

Personality

People remember things that feel human.

Illustrations naturally create emotional connection and curiosity.

Memorability

A unique visual style helps visitors remember your portfolio long after they leave.

Better Branding

Your portfolio becomes more than a project showcase.

It becomes part of your personal brand.

// Detect dark theme var iframe = document.getElementById('tweet-2069502994731995442-384'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2069502994731995442&theme=dark" }

Perfect For

This theme works exceptionally well for:

🎨 Designers

💻 Developers

🚀 Startup Founders

✍️ Creators

🎬 Content Creators

📸 Freelancers

🎓 Students Building Their First Portfolio

If your goal is standing out rather than blending in, this style can make a huge difference.

Features

✅ Premium hand-drawn design

✅ Modern 3D visual elements

✅ Smooth animations

✅ Mobile responsive

✅ Fast loading

✅ Professional layout

✅ Easy customization

✅ Unique visual identity

First Impressions Matter

Most visitors decide whether to continue exploring a website within a few seconds.

A memorable design buys attention.

Attention creates engagement.

Engagement creates opportunities.

Whether you're looking for clients, internships, freelance work, or a full-time role, your portfolio is often your first impression.

Make it count.

Live Preview

🎥 Full Website Walkthrough - https://kraft-portfolio-theme.surge.sh/

📸 Additional Screenshots

Get Kraft

If you're tired of generic portfolio templates and want something that actually feels creative, check out Kraft Premium 3D Hand Drawn Portfolio Theme.

👉 https://scriptly.store/products/kraft-premium-3d-hand-drawn-portfolio-theme

The best portfolio isn't always the most complex.

It's the one people remember.

Stop Building Boring Portfolios: This Scroll-Driven Travel Portfolio Changes Everything 🌍

Sh Raj — Tue, 23 Jun 2026 19:19:17 +0000

Stop Building Boring Portfolios: This Scroll-Driven Travel Portfolio Changes Everything 🌍

// Detect dark theme var iframe = document.getElementById('tweet-2069503536296296815-301'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2069503536296296815&theme=dark" }

Most portfolios look identical.

A hero section.
A projects section.
A contact form.

And that's it.

In a world where everyone is competing for attention, a portfolio should be more than a collection of links—it should be an experience.

What Makes This Portfolio Different?

The Panda Scroll Travel Animation Portfolio transforms a simple portfolio into an interactive journey.

As visitors scroll, the website comes alive with immersive animations, smooth transitions, and storytelling-inspired effects that keep users engaged from start to finish.

Instead of simply showing your work, it helps you present it in a way people actually remember.

Why Scroll-Based Storytelling Works

Modern websites from top brands often use scroll-driven storytelling because it naturally captures attention.

Benefits include:

Higher visitor engagement
Longer session duration
Better first impressions
More memorable personal branding
Premium visual appeal

When content unfolds as users scroll, curiosity keeps them moving forward.

Perfect For

This template is ideal for:

Developers
Designers
Freelancers
Creative agencies
Travel creators
Students building a personal brand
Anyone wanting a premium portfolio

Whether you're applying for internships, freelancing clients, or showcasing personal projects, a unique portfolio can help you stand out.

Features

✅ Stunning scroll animations

✅ Smooth storytelling experience

✅ Modern premium design

✅ Mobile responsive

✅ Fast loading

✅ Easy customization

✅ Clean code structure

![Feature Showcase Screenshot Here]

Why Buy Instead of Building?

Creating a polished scroll-animation website from scratch requires:

Animation expertise
Design skills
Hours of tweaking
Performance optimization

This template lets you skip weeks of work and launch much faster.

Simply customize the content, add your projects, and make it your own.

Live Demo

🎥 GIF Preview

📸 Screenshots

Get The Template

If you're looking for a portfolio that actually leaves an impression, check out the Panda Scroll Travel Animation Portfolio.

👉 https://scriptly.store/products/panda-scroll-travel-animation-portfolio

A portfolio isn't just where you display your work.

It's often the first impression people have of you.

Make it memorable.

Can You Beat Alan Turing? A Solstice-Themed Psychological Deduction Game

Sh Raj — Fri, 19 Jun 2026 20:02:18 +0000

Can You Beat Alan Turing? A Solstice-Themed Psychological Deduction Game

Submission for the June Solstice Game Jam
Categories: Best Google AI Usage, Best Ode to Alan Turing

Have you ever wondered if the person you're talking to on the internet is real? In 1950, Alan Turing asked the same question.

For this Game Jam, I wanted to build something that wasn't just a traditional 2D platformer, but a psychological thriller disguised as a chat interface.

Welcome to "Can You Beat Alan Turing?" — a modern, browser-based reimagining of the Turing Test wrapped in the atmospheric metaphors of the June Solstice.

Play the Game

Play it Live Here
(Note: Headphones recommended for focus. The clock is ticking!)

🌓 The Concept: Turing Meets the Solstice

In this game, you are placed in a verification terminal. The Solstice Dial sits at the top of your screen, representing 10 available transmissions (questions). You must interrogate three distinct "character nodes" and guess which ones are human, and which are highly advanced AI.

I wove the themes of the June Solstice and Alan Turing directly into the game mechanics and UI:

The Metaphor of Light: Sunlight represents logical certainty; shadows represent doubt. The game's UI uses Framer Motion to slowly fade from a bright, golden amber (Zenith) into a deep twilight indigo as you use up your transmissions.
The Solstice Dial: The countdown isn't a timer, it's a sun cycle. You only have 10 transmissions before the sun sets and you must submit your final verdict.
The Bletchley Park Tribute: One of the characters you can interrogate, Arthur Pendelton, is a retired cryptanalyst—a direct nod to Turing's monumental work at Bletchley Park. The other characters also reference Turing's philosophies on logic vs. emotion in their hidden dialogue.

🤖 Best Google AI Usage: "Cognitive Signature Analysis"

This game isn't just a static chat app. It uses the Gemini 1.5 Flash API to drive the core gameplay loop.

Instead of just hooking up an LLM to a chat box, I used Gemini to create strict behavioral profiles. I prompt Gemini to act either as a human with specific flaws (complaining about heat, making typos) or an AI trying too hard to sound human (using overly precise mathematical syntax, avoiding contractions).

The Signature Analysis Tool
If you get stuck, you can spend 2 of your precious 10 transmissions to use the Cognitive Signature Analysis tool. This sends the entire chat history back to Gemini with a highly specific meta-prompt: "Analyze this transcript and give a cryptic, poetic hint about whether the entity shows signs of a beating heart or silicon perfection."

It's a "hint" system powered entirely by real-time LLM analysis of your own unique conversation!

(Note: If the API goes offline, I built a custom local "Simulator Mode" fallback that uses regex-based keyword parsing so the game is always 100% playable for the judges).

🛠️ The Tech Stack

I built this over the weekend using a modern web stack aimed at maximum visual polish and edge performance:

Next.js 14 (App Router) & React: For the core state machine and UI rendering.
Tailwind CSS v4: Extensive use of custom glassmorphism, glowing amber/indigo borders, and CRT scanline overlays to create a "retro-futuristic terminal" vibe.
Framer Motion: Smooth page transitions and UI micro-interactions.
Cloudflare Pages: The entire app, including the Gemini AI edge routes (/api/chat and /api/analyze), is deployed on Cloudflare Pages for instant global response times.
Canvas Confetti: Because every game needs a reward for winning!

🐛 Challenges Faced

The biggest challenge was "taming" the LLM. Gemini is so smart that it's actually hard to make it sound like a flawed, tired human barista (one of the characters). I spent hours tuning the system prompts. For example, to make the AI character have a "tell", I specifically instructed Gemini: "You are an AI pretending to be a human. Your tell is that you NEVER use contractions and you accidentally use structural parallelism in your sentences."

Getting the UI to feel "alive" was also tricky. Implementing the custom text-scramble decryption effect for incoming AI messages really added that final layer of polish that makes it feel like a premium game rather than a web app.

🏁 Final Thoughts

Building this was an incredible experience. It really made me think about Turing's original 1950 paper. If we can build an AI that can convincingly complain about the summer heat and a sore back... have they passed the test?

I hope you enjoy interrogating these characters as much as I enjoyed building them!

GitHub Repo:

SH20RAJ / beat-alan-turing

A polished, atmospheric browser-based deduction game built for the June Solstice Game Jam 2026. This project serves as a double submission for the Best Google AI Usage and Best Ode to Alan Turing prize categories.

Can You Beat Alan Turing?

A polished, atmospheric browser-based deduction game built for the June Solstice Game Jam. This project serves as a double submission for the Best Google AI Usage and Best Ode to Alan Turing prize categories.

The core gameplay centers around a modern reimagining of the classic Turing Test, framed through the visual and narrative metaphors of the June Solstice (light vs. shadow, certainty vs. doubt, cycles).

🌓 The Concept & Jam Themes

1. Best Ode to Alan Turing

In 1950, Alan Turing famously proposed the "Imitation Game" (now known as the Turing Test) as a practical answer to the question "Can machines think?".

The Gameplay: You enter a verification chamber where you must communicate with three different mind nodes. Your task is to interrogate them, search for cognitive flaws, and guess who is human and who is AI.
The Tribute: The game features…

View on GitHub

My Failed Attempt

/You must play it with sound on./

Happy Solstice, and happy interrogating!

How I Freed 50GB of Disk Space Using a Git Trick You’ve Never Heard Of

Sh Raj — Fri, 19 Jun 2026 11:23:25 +0000

How I Freed 50GB of Disk Space Using a Git Trick You’ve Never Heard Of

Are your local ~/Downloads, ~/Desktop, or ~/Documents folders slowly drowning under a mountain of screenshots, screen recordings, zoom logs, and random design mockups?

If you are like most developers, designers, or technical writers, you probably have gigabytes of screen recordings and screenshots cluttering your local disk. You need to keep them for future reference, but they are eating away at your SSD, slowing down your system, and making backups a nightmare.

You could buy iCloud or Google Drive storage. Or you could use this insane Git workflow that stores your files permanently on GitHub, keeps them fully browsable on the web, but consumes exactly 0 bytes of your local storage.

In this deep-dive article, we will show you how to set up a permanent, automated media vault on GitHub using Git Sparse-Checkout and Git LFS (Large File Storage)—and provide a complete automation script and "Skill" file so your AI coding assistants can run it for you!

The Problem: The Standard Backup Trap

Usually, backing up files to GitHub means:

Pushing the files.
Keeping them locally.

If you delete them locally and commit the deletion, they disappear from GitHub's main directory browser. If you don't commit the deletion, your local working tree is dirty forever, and git status screams at you with hundreds of red lines:

Changes not staged for commit:
  deleted:    Screenshot 2026-04-12 at 5.32.00 PM.png
  deleted:    Screen Recording 2026-04-13 at 10.00.04 PM.mov
  ...

Is there a way to keep them on GitHub but free up local space while keeping your git status clean?

Yes. It's called Git Sparse-Checkout.

🚀 The Secret Weapon: Git Sparse-Checkout

Sparse-checkout is a native Git feature designed for giant monorepos. It allows you to tell Git: "Keep these files committed in the remote repository history, but do not physically download or extract them to my local machine."

Combine this with Git LFS for large video files, and you have a free, infinite, automated cloud storage locker.

🛠️ Step-by-Step Implementation Guide

Let's walk through how to build this system from scratch.

Step 1: Initialize Git and Setup LFS (Large File Storage)

If you have large recordings (over 100MB), standard GitHub commits will reject them due to GitHub's file size limits. We'll set up Git LFS first.

Open your terminal in your media folder (e.g. ~/Documents) and run:

# 1. Install Git LFS (on macOS)
brew install git-lfs

# 2. Initialize LFS in your folder
git lfs install

# 3. Track heavy video formats with LFS
git lfs track "*.mov"
git lfs track "*.mp4"

# 4. Commit LFS configurations
git add .gitattributes
git commit -m "setup: track video formats via LFS"

Step 2: Configure Sparse-Checkout (Exclusion Patterns)

Now, we set up the exclusion rules. We want to tell Git to exclude the folders where we store our images and videos locally, but keep the index, readme, and scripts checked out.

# 1. Enable sparse-checkout in non-cone (custom pattern) mode
git sparse-checkout init --no-cone

# 2. Set the exclusion rules in Git's sparse config
echo '/*
!/images/
!/videos/' > .git/info/sparse-checkout

# 3. Apply the rules
git sparse-checkout reapply

What does this pattern mean?

/* checks out all files at the root level (like README.md, INDEX.md, backup.sh).
!/images/ and !/videos/ tells Git never to check out or keep the images or videos directories on your local drive.

Any existing files matching these directories will be deleted instantly from your local disk, but remain safe on GitHub!

🤖 Step 3: Automate It (The One-Click Script)

To make this effortless, here is a bash script (backup.sh) that automates the entire flow:

Scans the root directory for new screenshots or videos.
Moves them automatically into folders organized by date and type (images/YYYY-MM/ and videos/YYYY-MM/).
Commits and pushes them to GitHub.
Grabs the full 40-character commit SHA (important to avoid raw usercontent 404s).
Rebuilds a markdown catalog (INDEX.md) listing download URLs.
Reapplies the sparse-checkout rules to wipe the local files and reclaim your disk space!

Here is the script backup.sh:

#!/usr/bin/env bash
# backup.sh - Automatically organize, backup new screenshots/videos to subfolders, update INDEX.md, push to GitHub, and clean up local space.

set -e

REPO_URL="https://raw.githubusercontent.com/YOUR_USERNAME/YOUR_REPO"
INDEX_FILE="INDEX.md"
BRANCH="main"

echo "🔍 Scanning for new media files to back up..."

# Find new untracked/modified media files at root or inside subdirs
NEW_FILES=()
while IFS= read -r -d '' file; do
    relative="${file#./}"
    if [[ "$relative" =~ \.(png|jpg|jpeg|mov|mp4)$ ]]; then
        NEW_FILES+=("$relative")
    fi
done < <(git status --porcelain -z | grep -z -E '^\?\?|^ M' | cut -z -c4- | sort -z)

TOTAL=${#NEW_FILES[@]}

if [ "$TOTAL" -eq 0 ]; then
    echo "✅ No new media files found to back up."
    exit 0
fi

echo "📊 Found $TOTAL new files to process."

# Move files to date-based folders if they are at the root level
MOVED_FILES=()
for f in "${NEW_FILES[@]}"; do
    if [[ ! "$f" == *"/"* ]]; then
        # Parse date from name or default to current year-month
        if [[ "$f" =~ [0-9]{4}-[0-9]{2}-[0-9]{2} ]]; then
            DATE_STR="${BASH_REMATCH[0]}"
            YM="${DATE_STR:0:7}" # YYYY-MM
        else
            YM=$(date '+%Y-%m') # Fallback to current year-month
        fi

        if [[ "$f" =~ \.(png|jpg|jpeg)$ ]]; then
            dest_dir="images/$YM"
        else
            dest_dir="videos/$YM"
        fi

        mkdir -p "$dest_dir"
        dest_path="$dest_dir/$f"
        echo "📂 Moving root file: $f -> $dest_path"
        mv "$f" "$dest_path"
        git add "$dest_path"
        MOVED_FILES+=("$dest_path")
    else
        git add "$f"
        MOVED_FILES+=("$f")
    fi
done

# Commit and Push the files first to get the commit SHA
echo "💾 Committing new organized files..."
git commit -m "backup: add $TOTAL new files organized by date"
echo "🚀 Pushing files to GitHub..."
git push origin "$BRANCH"

# Get the full 40-character commit SHA
COMMIT_SHA=$(git rev-parse HEAD)
echo "✅ Pushed successfully! Commit: $COMMIT_SHA"

# Rebuild INDEX.md using Python to keep it clean and ordered
echo "📝 Rebuilding INDEX.md..."
python3 -c "
import os
import urllib.parse
from datetime import datetime

repo_url_base = '${REPO_URL}/${COMMIT_SHA}'
index_file_path = '${INDEX_FILE}'

def get_human_size(path):
    try:
        size = os.path.getsize(path)
        if size >= 1073741824:
            return f'{size / 1073741824:.1f} GB'
        elif size >= 1048576:
            return f'{size / 1048576:.1f} MB'
        elif size >= 1024:
            return f'{size / 1024:.1f} KB'
        else:
            return f'{size} B'
    except Exception:
        return 'Unknown'

# Collect images
images = []
for root, dirs, files in os.walk('images'):
    for f in files:
        if f.endswith('.png'):
            relative_path = os.path.join(root, f)
            images.append(relative_path)
images.sort()

# Collect videos
videos = []
for root, dirs, files in os.walk('videos'):
    for f in files:
        if f.endswith('.mov') or f.endswith('.mp4'):
            relative_path = os.path.join(root, f)
            videos.append(relative_path)
videos.sort()

# Read the first commit SHA for other files
first_sha = os.popen('git log --oneline | tail -1 | cut -d\" \" -f1').read().strip()

with open(index_file_path, 'w') as f_obj:
    f_obj.write('# 📁 Documents Index\n\n')
    f_obj.write('> Auto-generated index of all files backed up to this repository.\n')
    f_obj.write('> Use the Raw URL to download any file, even after local deletion.\n')
    f_obj.write(f'> Generated on: {datetime.now().strftime(\"%Y-%m-%d %H:%M:%S\")}\n\n')

    f_obj.write('## 🖼️ Images (PNG Screenshots)\n\n')
    f_obj.write('| # | File | Size | Commit | Raw URL |\n')
    f_obj.write('|---|------|------|--------|---------|\n')
    for idx, path in enumerate(images, 1):
        size = get_human_size(path)
        encoded = urllib.parse.quote(path, safe='/')
        f_obj.write(f'| {idx} | `{path}` | {size} | `{COMMIT_SHA[:7]}` | [Download]({repo_url_base}/{encoded}) |\n')

    f_obj.write('\n## 🎥 Videos (Screen Recordings)\n\n')
    f_obj.write('| # | File | Size | Commit | Raw URL |\n')
    f_obj.write('|---|------|------|--------|---------|\n')
    for idx, path in enumerate(videos, 1):
        size = get_human_size(path)
        encoded = urllib.parse.quote(path, safe='/')
        f_obj.write(f'| {idx} | `{path}` | {size} | `{COMMIT_SHA[:7]}` | [Download]({repo_url_base}/{encoded}) |\n')

    f_obj.write('\n## 📄 Other Files\n\n')
    f_obj.write('| # | File | Size | Commit | Raw URL |\n')
    f_obj.write('|---|------|------|--------|---------|\n')
    f_obj.write(f'| 1 | `hls-video.excalidraw` | {get_human_size(\"hls-video.excalidraw\")} | `{first_sha}` | [Download]({repo_url_base}/hls-video.excalidraw) |\n')
"

# Commit and Push INDEX.md
git add "$INDEX_FILE"
git commit -m "index: update INDEX.md with new backup file mappings"
git push origin "$BRANCH"

# Reapply sparse checkout to reclaim local disk space
echo "🧹 Reclaiming local disk space (running sparse-checkout)..."
git sparse-checkout reapply

echo "🎉 Backup complete! Local space is cleared, and files are safe on GitHub."

Make it executable:

chmod +x backup.sh

🤖 Step 4: The AI Assistant "Skill" File

If you are using AI agents (like Claude, Gemini, or Copilot) to help you develop, they can automate this backup system completely. By checking in a Skill Markdown file to your repository, future agents will immediately understand the repository rules and can safely execute the backups for you!

Here is the exact backup.skill.md file you should add to the repository:

# Skill: Organized Documents Backup and Space Reclaiming

This skill provides instructions for AI coding agents to back up new screenshots, screen recordings, and media files from the local computer to the GitHub repository using Git LFS and Git Sparse-Checkout, keeping files organized by date and type.

## 📁 Repository Directory Structure

Files are organized in folders automatically by date and type:
* `/images/YYYY-MM/` — Screenshot PNGs grouped by month
* `/videos/YYYY-MM/` — Screen Recording MOVs and MP4s grouped by month

---

## 🛠️ How to Back Up New Files (Agent Flow)

If the user drops new files into the folder, you should run the automated script.

### Option A: Automated (Recommended)
Run the backup script directly:

bash
./backup.sh

This script will:
1. Detect any untracked or modified images/videos.
2. Automatically parse dates from filenames (e.g. `2026-04-12`) and move them to their respective `images/YYYY-MM/` or `videos/YYYY-MM/` subdirectory.
3. Stage, commit, and push them to GitHub.
4. Fetch the **full 40-character commit SHA** (required for raw GitHub usercontent links to prevent 404s).
5. Rebuild `INDEX.md` using python to catalog all files with their paths, sizes, and direct raw download links.
6. Commit and push the updated `INDEX.md`.
7. Run `git sparse-checkout reapply` to clean up the local disk.

### Option B: Manual Execution
If the script needs debugging or you want to run it manually:

1. **Move files into directories**:

bash
mkdir -p images/YYYY-MM
git mv "Screenshot YYYY-MM-DD ...png" images/YYYY-MM/

2. **Stage and commit the new files**:

bash
git commit -m "backup: add new files"
git push origin main

3. **Retrieve the full commit SHA**:

bash
COMMIT_SHA=$(git rev-parse HEAD)

4. **Format entry for INDEX.md**:
   Add rows to `INDEX.md` under the appropriate table header:

markdown
| # | File | Size | Commit | Raw URL |
|---|------|------|--------|---------|
| [Index] | images/YYYY-MM/[Filename] | [Size MB] MB | [Commit SHA] | Download |

5. **Push INDEX.md**:

bash
git add INDEX.md
git commit -m "index: update entries"
git push origin main

6. **Reapply sparse checkout to delete local files**:

bash
git sparse-checkout reapply


---

## 📥 How to Restore a File for the User

If the user requests to restore one or more files to their computer:
1. Locate the file in `INDEX.md` to get its path.
2. Tell Git to stop skipping the file:

bash
git sparse-checkout add "images/YYYY-MM/filename.png"

   *Note: This will immediately download the file from GitHub to the local directory.*
3. To exclude it again after use:

bash
git sparse-checkout reapply

shell

💡 How This Helps You: 5 Real-World Benefits

1. Zero Disk Usage

The main benefit. Your local project folders stay incredibly clean and compact, preserving your SSD life and leaving space for active coding projects.

2. Fully Browsable on GitHub

Unlike standard backup archives (like .zip or .tar), your files aren't locked away in a compressed format. You can click through /images/2026-06/ on GitHub's website and browse them instantly.

3. Bulletproof, Unbreakable Links

By pointing the download URLs in INDEX.md to the full commit SHA (/Documents/a2b2ed5a43.../images/file.png) instead of /main/, these links will work forever. Even if you delete or modify the files on the main branch later to clean up remote storage, the historical commit raw URLs remain functional.

4. Zero Maintenance for Future Assistant Agents

If you use coding agents, you can check in the backup.skill.md file. Future agents entering your workspace will automatically understand how to restore files or perform backups without you having to guide them.

5. Restore Files Instantly

Need a file back? You don't have to download it from a web browser. Just tell Git to stop skipping it:

git sparse-checkout add "images/2026-04/screenshot.png"

Git will instantly fetch it from GitHub and drop it back into your local folder. Once you are done, run:

git sparse-checkout reapply

And it disappears from your disk again!

⚡ Conclusion

Stop letting screenshots and screen recordings choke your machine's performance. Git was built to track changes, but with Sparse-Checkout, it becomes a premium, automated, zero-local-footprint cloud drive.

Have you ever used sparse checkout? Let me know in the comments how you manage local file clutter!

I Was Tired of Rebuilding the Same Landing Page Over and Over. So I Started Collecting the Best Ones.

Sh Raj — Thu, 18 Jun 2026 12:40:14 +0000

I Was Tired of Rebuilding the Same Landing Page Over and Over. So I Started Collecting the Best Ones.

Every developer knows this feeling.

You get a new idea.

You spend a week setting up:

Next.js
Tailwind
Authentication
Landing pages
Animations
SEO

Then the idea fails.

Not because the idea was bad.

Because you spent all your time building infrastructure instead of testing the idea.

After doing this repeatedly, I started saving every great starter, template, landing page, animation, and growth resource I came across.

Eventually, that collection became something much bigger.

The Hidden Cost of Building From Scratch

Most founders think code is the bottleneck.

It's not.

The real bottleneck is time.

A typical SaaS founder spends weeks building things users never see:

Billing systems
Landing pages
Authentication
Waitlists
Marketing websites
Launch infrastructure

None of these create differentiation.

Yet they consume most of the development cycle.

The Templates That Changed How I Build

1. Fizzi — Award-Winning 3D Ecommerce Experience

Built with:

Next.js 14
GSAP
Three.js
Prismic

This project completely changed how I think about product storytelling.

Most landing pages explain products.

This one makes visitors experience them.

2. JARVIS Cinematic

Inspired by Iron Man's futuristic HUD.

Features:

Interactive UI
Cinematic animations
Particle effects
Sci-fi design system

The first reaction people have is:

"Wait... this is a website?"

And that's exactly the point.

3. Premium 3D Product Landing Page

Most SaaS websites look identical.

This template focuses on:

Motion
Product visualization
Conversion
Modern aesthetics

Perfect for startups launching premium products.

4. Aero UI

Built using:

Next.js 15
Tailwind v4
Glassmorphism
Marketing-focused sections

One of the cleanest modern landing page structures I've seen.

The Resource I Wish I Had Earlier

When launching products, I discovered another problem.

Promotion.

Most founders launch once.

The best founders distribute endlessly.

That's why I built LaunchDB.

A curated database containing:

1,500+ SaaS directories
Startup launch platforms
AI tool directories
Product discovery websites
Marketing directories

Instead of spending hours searching for places to submit your startup, everything is already organized in a single dataset.

What I Learned Building Products

Shipping beats perfection

Users don't care how elegant your architecture is.

They care whether you solved their problem.

Design is a growth channel

A memorable product gets shared.

An average product gets ignored.

Distribution is more important than code

The best product doesn't always win.

The best-distributed product usually does.

Final Thoughts

Most developers underestimate how much leverage comes from reusable assets.

A good template can save weeks.

A good database can save months.

A good launch can change everything.

If you're building your next startup, don't start from scratch.

Start from momentum.

I Tried Creating a New Math Theorem: A Weighted Fourth-Power Distance Identity

Sh Raj — Fri, 29 May 2026 18:40:47 +0000

I Tried Creating a New Math Theorem: A Weighted Fourth-Power Distance Identity

We all know famous theorems like the Pythagorean theorem.

a^{2} + b^{2} = c^{2}

It is simple, beautiful, and powerful.

That made me wonder:

Can we create a small but real mathematical theorem today?

Not just a random formula.

A theorem should have:

a clear statement,
a proof,
examples,
and a reason why it is interesting.

So I explored a geometry idea involving points on a circle and distances from any point in the plane.

The result is a small theorem I am calling:

Shaswat’s Weighted Moment-Circle Theorem

This theorem is about a hidden symmetry in the sum of fourth powers of distances.

The Main Idea

Imagine some points placed on a circle.

Now take any point P anywhere in the plane.

From P, measure the distance to every point on the circle.

Usually, these distances depend on the direction of P.

But under a special balance condition, something interesting happens:

The weighted sum of the fourth powers of those distances depends only on how far P is from the center of the circle.

It does not depend on the direction of P.

That means the value is rotationally symmetric.

The Theorem

Let the points be:

A_{1}, A_{2}, \dots, A_{n}

These points lie on a circle of radius R, centered at O.

Assign positive weights:

w_{1}, w_{2}, \dots, w_{n}

Let the total weight be:

W = w_{1} + w_{2} + \dots + w_{n}

Represent each point A_i using a complex number u_i, with the center O as the origin.

So every point satisfies:

∣ u_{i} ∣ = R

Now suppose the weighted first and second moments vanish:

i = 1 \sum n w_{i} u_{i} = 0

and

i = 1 \sum n w_{i} u_{i 2} = 0

Then, for any point P in the plane with OP = ρ, we have:

i = 1 \sum n w_{i} P A_{i 4} W (R^{4} + 4 R^{2} ρ^{2} + ρ^{4})

In Simple Words

If the points on the circle are balanced strongly enough, then:

\sum w_{i} P A_{i 4}

depends only on the distance of P from the center.

It does not depend on where around the circle P is located.

So if two points P and Q are the same distance from the center O, then:

\sum w_{i} P A_{i 4} \sum w_{i} Q A_{i 4}

That is the hidden symmetry.

Why This Is Interesting

For regular polygons, distance identities like this are already known.

For example, if the points are the vertices of a regular polygon, the symmetry is expected.

But this theorem explains the phenomenon using moment conditions.

Instead of saying:

The points must form a regular polygon.

We say:

The weighted first and second complex moments must vanish.

That gives a more flexible condition.

It can include some non-regular weighted arrangements too.

Proof

Let the complex coordinate of point P be p.

Since OP = ρ, we have:

∣ p ∣ = ρ

Each point A_i has complex coordinate u_i, and since all A_i lie on the circle of radius R:

∣ u_{i} ∣ = R

The squared distance between P and A_i is:

P A_{i 2} = ∣ p - u_{i} ∣^{2}

Expanding this:

∣ p - u_{i} ∣^{2} ∣ p ∣^{2} + ∣ u_{i} ∣^{2} - p u_{i} - p u_{i}

Since |p| = ρ and |u_i| = R, we get:

P A_{i 2} ρ^{2} + R^{2} - p u_{i} - p u_{i}

Let:

T = ρ^{2} + R^{2}

and

Q_{i} = p u_{i} + p u_{i}

Then:

P A_{i 2} = T - Q_{i}

Therefore:

P A_{i 4} = (T - Q_{i})^{2}

Now sum with weights:

\sum w_{i} P A_{i 4} \sum w_{i} (T - Q_{i})^{2}

Expanding:

\sum w_{i} P A_{i 4} \sum w_{i} T^{2} 2 T \sum w_{i} Q_{i} + \sum w_{i} Q_{i 2}

Since T is constant:

\sum w_{i} T^{2} = W T^{2}

Now look at the middle term:

\sum w_{i} Q_{i} \sum w_{i} (p u_{i} + p u_{i})

So:

\sum w_{i} Q_{i} p \sum w_{i} u_{i} + p \sum w_{i} u_{i}

By assumption:

\sum w_{i} u_{i} = 0

Taking conjugates gives:

\sum w_{i} u_{i} = 0

Therefore:

\sum w_{i} Q_{i} = 0

So the middle term disappears.

Now calculate the last term:

Q_{i 2} = (p u_{i} + p u_{i})^{2}

Expanding:

Q_{i 2} p^{2} u_{i}^{2} + 2∣ p ∣^{2} ∣ u_{i} ∣^{2} + p^{2} u_{i 2}

Now sum with weights:

\sum w_{i} Q_{i 2} p^{2} \sum w_{i} u_{i}^{2} + 2∣ p ∣^{2} \sum w_{i} ∣ u_{i} ∣^{2} + p^{2} \sum w_{i} u_{i 2}

By the second assumption:

\sum w_{i} u_{i 2} = 0

Taking conjugates:

\sum w_{i} u_{i}^{2} = 0

Also:

∣ p ∣^{2} = ρ^{2}

and

∣ u_{i} ∣^{2} = R^{2}

So:

\sum w_{i} ∣ u_{i} ∣^{2} \sum w_{i} R^{2} W R^{2}

Therefore:

\sum w_{i} Q_{i 2} 2 ρ^{2} W R^{2}

Now substitute back:

\sum w_{i} P A_{i 4} W T^{2} + 2 ρ^{2} W R^{2}

Since:

T = ρ^{2} + R^{2}

we get:

\sum w_{i} P A_{i 4} W (ρ^{2} + R^{2})^{2} + 2 W ρ^{2} R^{2}

Expanding:

\sum w_{i} P A_{i 4} W (ρ^{4} + 2 ρ^{2} R^{2} + R^{4} + 2 ρ^{2} R^{2})

So:

\sum w_{i} P A_{i 4} W (R^{4} + 4 R^{2} ρ^{2} + ρ^{4})

Hence proved.

Example: Regular Triangle

Take an equilateral triangle on a circle of radius R.

Let all weights be equal to 1.

Because of symmetry:

u_{1} + u_{2} + u_{3} = 0

and

u_{12} + u_{22} + u_{32} = 0

So the theorem applies.

Here:

W = 3

Therefore, for any point P with OP = ρ:

P A_{14} + P A_{24} + P A_{34} 3 (R^{4} + 4 R^{2} ρ^{2} + ρ^{4})

So if P moves around a circle centered at O, the value stays constant.

Only the distance from the center matters.

Example: Square

For a square centered at O, again the first and second moments vanish.

So for four vertices:

W = 4

Hence:

P A_{14} + P A_{24} + P A_{34} + P A_{44} 4 (R^{4} + 4 R^{2} ρ^{2} + ρ^{4})

This is another clean version of the identity.

Locus Interpretation

Suppose we want all points P such that:

\sum w_{i} P A_{i 4} = C

Using the theorem:

W (R^{4} + 4 R^{2} ρ^{2} + ρ^{4}) = C

This only depends on ρ, which is the distance of P from the center.

So the locus is a circle centered at O, if a real solution exists.

That is beautiful because a complicated-looking distance equation becomes a simple circular locus.

What Makes This Theorem Useful?

This theorem gives a compact way to understand fourth-power distance sums.

It connects:

geometry,
complex numbers,
weighted averages,
symmetry,
and moments.

The result also gives a simple test:

\sum w_{i} u_{i} = 0

and

\sum w_{i} u_{i 2} = 0

If both conditions hold, then the fourth-power distance sum becomes radial.

That means the expression becomes much easier to analyze.

Is This Completely New?

I want to be careful here.

Many formulas about distances to regular polygons and points on a circle already exist.

So I am not claiming that every part of this is historically new.

A safer and more honest claim is:

This is a weighted moment-based formulation of a fourth-power distance identity on the circle.

The regular polygon case is known, but this moment-condition version gives a nice generalization and a clean proof.

Before publishing this as a formal research paper, it should be checked by a mathematics professor or someone experienced in geometry/algebra.

But as a mathematical note, learning experiment, or blog post, it is a valid and interesting result.

Final Theorem Again

Let A_i be points on a circle of radius R, represented by complex numbers u_i, and let w_i > 0.

If:

\sum w_{i} u_{i} = 0

and

\sum w_{i} u_{i 2} = 0

then for any point P with OP = ρ:

\sum w_{i} P A_{i 4} W (R^{4} + 4 R^{2} ρ^{2} + ρ^{4})

where:

W = \sum w_{i}

That is the theorem.

Closing Thought

The beautiful thing about mathematics is that even simple objects like a circle can hide deep symmetry.

Sometimes, creating a theorem is not about finding something extremely complicated.

It is about noticing a pattern, stating it clearly, proving it, and connecting it to existing ideas.

This was my attempt at doing that.

Thanks for reading.

The 2026 Founder’s Guide to Free AI/API Credits

Sh Raj — Wed, 27 May 2026 12:53:15 +0000

The 2026 Founder’s Guide to Free AI/API Credits

Updated: 27 May 2026

Free AI credits are still everywhere, but they are no longer as simple as “sign up and get $100.” Most serious credits now fall into four buckets: free API tiers, trial credits, student perks, and startup/research grants. The smartest move is not to chase one provider. It is to stack multiple small free tiers for prototyping, then apply to larger startup programs once you have a working demo.

1. The fastest free AI APIs to use today

For immediate building, start with providers that do not require a long approval process.

Provider	Free / low-cost access	Best use
Google Gemini API / AI Studio	New accounts begin on a Gemini API Free Tier for certain models; Gemini 3 Flash and Gemini 3.1 Flash-Lite have free API tiers, while Gemini 3.1 Pro Preview does not.	General chat, coding, image/PDF reasoning, fast prototyping. (Google AI for Developers)
GroqCloud	Free tier with rate limits; docs mention accounts can return to Free tier limits if billing is removed.	Very fast open-model inference for apps, bots, and coding agents. (GroqCloud)
OpenRouter	Free models are limited to 20 RPM; 50 free-model requests/day unless you have purchased at least $10 credits, then 1,000/day.	Testing many LLMs through one OpenAI-compatible API. (OpenRouter)
Mistral AI	Free “Experiment” API tier for evaluation/prototyping with limited rate limits.	EU-friendly LLMs, coding models, OCR/document work. (Mistral AI)
Cohere	Free trial/evaluation API keys; production keys are paid and trial keys cannot be used commercially.	RAG, embeddings, reranking, enterprise-style search. (Cohere Documentation)
Cerebras Cloud	Free API access to Cerebras-powered models; paid Developer tier starts with self-serve payment and higher limits.	Ultra-fast inference and coding-agent experiments. (Cerebras)
Hugging Face Inference Providers	Monthly credits: Free users get $0.10/month, Pro users get $2/month, Teams get $2/seat/month.	Testing open models through one hub. (Hugging Face)
Fireworks AI	$1 free starter credit for serverless inference.	Fast open-source model inference, agents, structured output. (Fireworks AI)
Novita AI	Signup page currently advertises $1 free credit.	Cheap LLM/image/video API experiments. (Novita AI)
Deepgram	$200 free credit, no credit card needed, for voice APIs.	Speech-to-text, TTS, voice agents. (Deepgram)
AssemblyAI	Signup page advertises up to 330 free hours; startup program offers up to 200K hours.	Speech-to-text, audio intelligence, voice apps. (AssemblyAI)
Replicate	“Try for free” model collection, then pay-as-you-go.	Image/video/model demos without infrastructure. (Replicate)

The best immediate stack for a student/founder is: Gemini + Groq + OpenRouter + Mistral + Cerebras + Cohere + Hugging Face. This gives you enough free/low-cost API access to build MVPs, agents, demos, SEO tools, chatbots, and content pipelines.

2. The biggest startup credit programs

This is where the real money is. These programs usually require a startup website, product idea, company profile, GitHub/demo, and sometimes incorporation or VC/accelerator backing.

Program	Credit / benefit	Who should apply
AWS Activate	Founders package offers $1,000 AWS credits for self-funded startups; Portfolio package can go up to $100,000 for eligible startups connected to Activate providers.	Any serious startup, especially if you need Bedrock, Lambda, S3, GPUs, or hosting. (Amazon Web Services, Inc.)
Google for Startups Cloud Program	Up to $200,000 credits for startups; up to $350,000 for AI startups over two years.	AI-first startups using Gemini, Vertex AI, Firebase, BigQuery, Cloud Run. (Google for Startup)
Microsoft for Startups	Portal currently says startups can access up to $5,000 Azure credits; investor-network startups can unlock enhanced benefits.	Azure AI Foundry, Azure hosting, Microsoft ecosystem apps. (portal.startups.microsoft.com)
OpenAI for Startups	OpenAI says founders should reach out to their VC to unlock API credits.	VC-backed or accelerator-backed AI startups. (OpenAI)
OpenAI Researcher Access Program	Researchers can apply for up to $1,000 API credits, valid for 12 months.	Academic/independent researchers doing responsible AI work. (OpenAI)
Claude for Startups	Anthropic’s program offers API credits, priority rate limits, founder tools, community and resources.	AI startups building with Claude. (Claude)
Anthropic External Researcher Access	Anthropic support says successful applicants get $1,000 API credits.	Researchers studying Claude / AI safety / AI systems. (Claude Help Center)
NVIDIA Inception	Free program with partner cloud credits, preferred pricing, technical training and startup resources.	AI/ML startups, GPU-heavy products, computer vision, agents. (NVIDIA)
Together AI Startup Accelerator	Compute credits for inference, fine-tuning, dedicated endpoints and clusters; note: normal Together platform currently says no free trial and $5 minimum purchase.	Selected AI-native startups. (Together AI)
Fireworks for Startups	Build credits, higher rate limits, applied-AI support, community and GTM help.	Startups using open models at production scale. (Fireworks AI)
DeepInfra DeepStart	Up to 1B tokens for free inference.	Startups needing cheap open-model inference. (DeepInfra)
Deepgram Startup Program	Up to $100,000 Deepgram credits, usable within 12 months.	Voice AI, transcription, call agents. (Deepgram)
ElevenLabs Startup Grants	33M characters of audio generation credits over 12 months for eligible startups/small companies.	AI voice agents, narration, dubbing, audio apps. (ElevenLabs)
Sarvam Startup Program	Up to 12 months of credits, priority support, infra across speech, vision and LLM APIs.	Indian-language AI apps, voice bots, local language tools. (Sarvam AI)
AssemblyAI Startup Program	Up to 200K hours of free credits.	Audio intelligence, meeting tools, transcription, voice analytics. (AssemblyAI)

3. Best free API directories for non-AI apps

For web apps, dashboards, tools and content sites, you also need normal APIs: weather, finance, mock data, countries, movies, quotes, facts, news, etc.

Use these first:

Resource	Why it matters
public-apis GitHub repo	A large community-curated list of free public APIs. (GitHub)
free-for.dev	Huge curated list of free developer SaaS/PaaS/IaaS tiers. (Free for Developers)
API Ninjas	Many APIs under one key, with a free tier and no credit card required. (API Ninjas)
RapidAPI free APIs collection	Marketplace-style discovery for free/testable APIs. (RapidAPI)
Free Public APIs	Has its own API and claims 1,000 requests/day limit for the directory API. (Free Public APIs)

4. The best application strategy

Do not apply randomly. Build a small proof first.

Your application should have five things:

One-line product
Example: “IndexFast helps websites get discovered by Google and AI search engines faster.”
Working demo or GitHub repo
Even a simple Next.js app with login, dashboard, and 1–2 working API features improves approval chances.
Usage plan
Mention expected API usage: “We need LLM inference for content analysis, embeddings for semantic search, and speech APIs for voice summaries.”
Why credits matter
Say: “Credits will extend runway while we validate with early users.”
Proof of seriousness
Add Product Hunt / Peerlist / GitHub / users / waitlist / screenshots / revenue / hackathon wins.

5. What I’d do in your case

For you, I would stack credits like this:

Today: use Gemini, Groq, OpenRouter free models, Mistral Experiment tier, Cerebras free tier, Cohere trial key, Hugging Face free credits, Fireworks $1, Novita $1.

This week: apply to GitHub Student Developer Pack if you still have valid student proof; it remains one of the best student bundles for developer tools and partner credits. (GitHub)

For your startups/tools: prepare a clean one-page website for each real product, then apply to AWS Activate, Microsoft for Startups, NVIDIA Inception, Sarvam, Deepgram, ElevenLabs, and AssemblyAI.

For larger AI credits: apply to Google for Startups only after you can show an AI-first product, demo, and usage plan, because the AI tier can go up to $350,000 but is meant for serious AI startups. (Google Cloud)

6. Important warning

Avoid random YouTube/GitHub “unlimited free API key” hacks. Many violate provider terms, leak keys, or route your data through unknown servers. Use official free tiers, grants, startup programs, student packs, or open-source/local models. Also do not create multiple accounts to bypass free-tier limits; providers like Groq explicitly warn against circumventing free-tier limits. (GroqCloud)

Conclusion

The best free AI credit strategy in 2026 is a stack:

For instant building: Gemini, Groq, OpenRouter, Mistral, Cerebras, Cohere, Hugging Face, Fireworks.
For serious startup credits: AWS Activate, Google for Startups, Microsoft for Startups, NVIDIA Inception, OpenAI/Anthropic startup programs.
For voice/audio products: Deepgram, ElevenLabs, AssemblyAI, Sarvam.
For normal app APIs: public-apis, free-for.dev, API Ninjas, RapidAPI.

The biggest unlock is not just finding credits. It is packaging yourself like a real builder: product page, demo, repo, screenshots, users, and a clear credit usage plan.

HLS Video Streaming — Intuitive Explanation

Sh Raj — Wed, 27 May 2026 02:52:07 +0000

HLS Video Streaming — Intuitive Explanation

Imagine you have a 2-hour movie.

One simple way:

Download full movie.
Then play.

Problem?

If movie is 2 GB, user has to wait.
Bad internet? Video stops.
Mobile network changes? Quality cannot adjust.

So we need something smarter.

Now imagine instead of sending the full movie, we cut it into small pieces.

Movie becomes:

part1.ts
part2.ts
part3.ts
part4.ts
...

Each part may be 2 seconds, 4 seconds, or 6 seconds.

Now the player says:

Give me part 1.
Play part 1.
Meanwhile download part 2.
Then part 3.
Then part 4.

This is the main idea of HLS — HTTP Live Streaming.

Apple’s HLS sends live or on-demand audio/video using normal HTTP web servers and CDNs, and it adapts playback to network conditions. (Apple Developer)

1. The Core Problem

Imagine you are watching a video.

Watch...
Watch...
Watch...

Suddenly:

Network becomes slow.

If the server is sending one fixed high-quality video, then:

High quality video needs 8 Mbps
Your internet gives only 2 Mbps
Result: buffering...

So HLS asks:

Why send only one quality?

Let us create many versions:

1080p version
720p version
480p version
360p version

Now player can choose.

Fast internet?

Use 1080p

Slow internet?

Use 360p

Internet improves?

Switch back to 720p or 1080p

This is called adaptive bitrate streaming.

2. HLS Is Basically Two Things

HLS has two main file types:

A. Video chunks

These are small video pieces.

Example:

segment_001.ts
segment_002.ts
segment_003.ts

or modern format:

segment_001.m4s
segment_002.m4s

B. Playlist file

This is the most important part.

It is usually called:

.m3u8

Think of .m3u8 as a menu card.

It tells the player:

Here are the video pieces.
Play them in this order.

RFC 8216 describes HLS as a protocol for transferring streams of multimedia data and defines the file formats and client/server behavior. (IETF Datatracker)

3. Restaurant Analogy

Imagine you go to a restaurant.

You do not enter the kitchen.

You only see the menu.

The menu says:

Pizza
Burger
Pasta

You choose.

Similarly, in HLS:

The player does not know all video files directly.

It first asks for the playlist:

video.m3u8

The playlist says:

segment1.ts
segment2.ts
segment3.ts

Then the player downloads these segments one by one.

4. Basic HLS Flow

Suppose user opens:

https://example.com/movie/master.m3u8

Now step by step:

1. Player downloads master.m3u8
2. master.m3u8 lists available qualities
3. Player chooses one quality
4. Player downloads that quality’s playlist
5. Playlist lists video chunks
6. Player downloads chunks one by one
7. Player plays chunks continuously
8. If internet changes, player switches quality

Very simple.

5. Master Playlist vs Media Playlist

There are usually two playlist levels.

1. Master Playlist

This tells:

These qualities are available.

Example:

#EXTM3U

#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=842x480
480p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p.m3u8

Meaning:

For 360p, go to 360p.m3u8
For 480p, go to 480p.m3u8
For 720p, go to 720p.m3u8

2. Media Playlist

This tells:

These are the actual video chunks.

Example:

#EXTM3U
#EXT-X-TARGETDURATION:6

#EXTINF:6.0,
segment_001.ts

#EXTINF:6.0,
segment_002.ts

#EXTINF:6.0,
segment_003.ts

#EXT-X-ENDLIST

Meaning:

Play segment_001.ts for 6 seconds.
Then segment_002.ts for 6 seconds.
Then segment_003.ts for 6 seconds.
Video finished.

6. Mental Diagram

User clicks video
      |
      v
master.m3u8
      |
      |--- 360p.m3u8 ---> 360p segments
      |
      |--- 480p.m3u8 ---> 480p segments
      |
      |--- 720p.m3u8 ---> 720p segments
      |
      |--- 1080p.m3u8 -> 1080p segments

Now the player keeps asking:

How fast is internet?
How much buffer do I have?
Which quality is safe?

Then it chooses.

7. Adaptive Bitrate: The Smart Part

Imagine this situation:

You are watching in 1080p.

Internet speed: 10 Mbps
Video need: 5 Mbps
Good.

Then suddenly:

Internet speed: 1.5 Mbps
Video need: 5 Mbps
Problem.

Player thinks:

If I continue 1080p, video will buffer.
Better switch to 360p.

So it switches to lower quality.

After some time:

Internet speed becomes 8 Mbps

Player thinks:

Nice. Let us go back to 720p or 1080p.

This switching is the magic of HLS.

8. Why HLS Uses HTTP

HLS is powerful because it works over normal HTTP.

That means you can host HLS files on:

Normal web server
S3/R2 storage
Cloudflare CDN
AWS CloudFront
Nginx
Any static file server

No special streaming server is required for basic HLS.

That is why HLS became very popular.

The browser/player is basically downloading small files repeatedly.

GET master.m3u8
GET 720p.m3u8
GET segment1.ts
GET segment2.ts
GET segment3.ts
...

Apple also says HLS can be deployed using ordinary web servers and CDNs. (Apple Developer)

9. VOD vs Live HLS

There are two common cases.

Case 1: VOD

VOD means video on demand.

Example:

YouTube uploaded video
Course lecture
Movie
Recorded webinar

Here all segments already exist.

Playlist contains all segments:

segment1.ts
segment2.ts
segment3.ts
...
segment500.ts
#EXT-X-ENDLIST

#EXT-X-ENDLIST means:

Video is complete.
No more segments.

Case 2: Live Streaming

Example:

Cricket match
Live class
Gaming stream
News broadcast

Here future video does not exist yet.

So playlist keeps updating.

At 10:00:00:

segment100.ts
segment101.ts
segment102.ts

At 10:00:06:

segment101.ts
segment102.ts
segment103.ts

At 10:00:12:

segment102.ts
segment103.ts
segment104.ts

This is called a sliding window.

Player repeatedly reloads the playlist and asks:

Any new segment came?

If yes, download and play.

10. Why HLS Has Latency

Now imagine live streaming.

Camera records.

Encoder compresses.

Segmenter waits to make a 6-second segment.

CDN distributes.

Player downloads.

Player buffers.

Then user sees it.

So live HLS may have delay.

Camera now
   ↓
Encoding
   ↓
Segment creation
   ↓
CDN
   ↓
Player buffer
   ↓
Viewer sees

This is why normal HLS is not always “real-time.”

For lower delay, modern systems use Low-Latency HLS, where segments can be divided into smaller partial segments. Apple’s authoring documentation covers live and on-demand HLS delivery requirements for Apple devices. (Apple Developer)

11. Complete HLS Pipeline

Think of a factory.

Raw video enters.

HLS output comes out.

Camera / MP4 file
      |
      v
Encoder / Transcoder
      |
      v
Multiple qualities
      |
      v
Segmenter
      |
      v
.m3u8 playlists + small video chunks
      |
      v
CDN / Web server
      |
      v
Player

Example:

input.mp4
   |
   |-- 1080p chunks
   |-- 720p chunks
   |-- 480p chunks
   |-- 360p chunks
   |
   +-- master.m3u8

12. HLS in One Sentence

HLS means:

Cut video into small chunks, create playlist files that describe those chunks, host everything over HTTP, and let the player choose the best quality depending on internet speed.

That is HLS.

13. Remember Like This

Imagine a train.

Full movie is not sent as one huge train.

Instead:

Coach 1
Coach 2
Coach 3
Coach 4

The player receives coaches one by one.

If the track is clear:

Send luxury coach: 1080p

If the track is crowded:

Send small coach: 360p

Video keeps moving.

No full stop.

That is adaptive streaming.

14. Practical Example

Suppose you upload a video.

Original:

lecture.mp4

Server converts it into:

/master.m3u8

/360p/playlist.m3u8
/360p/seg1.ts
/360p/seg2.ts

/720p/playlist.m3u8
/720p/seg1.ts
/720p/seg2.ts

/1080p/playlist.m3u8
/1080p/seg1.ts
/1080p/seg2.ts

Then your frontend uses a player:

<video controls src="https://example.com/master.m3u8"></video>

On Safari, HLS support is native. On many other browsers, developers commonly use a JavaScript player/library that uses Media Source Extensions to play HLS streams.

15. Final Revision

HLS has 5 important words:

1. Encode
2. Segment
3. Playlist
4. HTTP/CDN
5. Adaptive bitrate

Meaning:

Encode      = create different qualities
Segment     = cut video into small pieces
Playlist    = tell player where pieces are
HTTP/CDN    = deliver pieces like normal files
Adaptive    = switch quality based on internet

So whenever you hear HLS, visualize this:

Big video
  ↓
Small chunks
  ↓
Playlist file
  ↓
Player downloads chunks
  ↓
Quality changes automatically

That’s the full intuitive model.

Stop Treating AI Agents Like Chatbots: How Hermes Agent Can Become an Always-On SEO Indexing Operator

Sh Raj — Sun, 24 May 2026 10:11:13 +0000

This is a submission for the Hermes Agent Challenge.

Stop Treating AI Agents Like Chatbots: Hermes Agent as an SEO Indexing Operator

Most people still think about AI agents as smarter chatbots.

You open a chat window. You ask a question. The model answers. Maybe it writes some code. Maybe it summarizes a document. Maybe it gives you a checklist.

That is useful, but it is not the real promise of agents.

The real promise is not a chat window that gives better answers.

The real promise is a system that can own a messy recurring workflow, remember what happened last time, improve its process, and keep doing useful work without you explaining everything again from zero.

That is why Hermes Agent is interesting.

It is not only trying to be another coding assistant. It is closer to an always-on operator: something that can use tools, remember context, build reusable skills, run scheduled workflows, and connect to external systems through protocols like MCP.

To make that idea practical, I want to look at one boring but valuable workflow that many developers and indie builders ignore until it hurts:

website indexing operations.

Because launching a website is not the same as being discovered.

The problem: launching is not the same as being indexed

Every builder knows this feeling.

You ship a landing page. You write some docs. You publish a few blog posts. You submit the site somewhere. You wait.

Then nothing happens.

The pages exist, but search engines do not pick them up quickly. Some URLs are missing from the sitemap. Some pages have weak metadata. Some important pages are buried too deep. One page accidentally has a noindex tag. Another page points to the wrong canonical URL. The sitemap was generated before the latest deployment. The robots file is technically valid but blocks something important.

None of this feels dramatic.

That is the point.

Indexing problems are usually not one big obvious bug. They are small boring failures spread across your site:

missing sitemap URLs
stale sitemap entries
accidental noindex tags
broken canonical tags
weak page titles
duplicate meta descriptions
important pages with poor internal links
orphan pages
blocked routes in robots.txt
changed URLs that were never resubmitted
pages that exist in the app but not in the sitemap
pages that are technically live but invisible to crawlers

A chatbot can tell you to check these things once.

But an agentic operator should be able to check them repeatedly, remember your site structure, notice recurring mistakes, and improve its process over time.

That is the difference.

A chatbot gives advice.
An operator owns the workflow.

Why Hermes Agent is a good fit for this kind of work

The interesting thing about Hermes Agent is not just that it can answer questions.

The interesting thing is the combination of features around persistent work:

memory across sessions
reusable skills
tool use
scheduled automations
browser and web control
MCP support
sandboxed execution
cross-platform access
autonomous improvement loops

Those pieces are much more powerful when you stop thinking about agents as chatbots and start thinking about them as narrow operators.

A narrow operator does not need to do everything.

It just needs to do one workflow extremely well.

For example:

“Every time I deploy, audit my website for indexing readiness, identify blockers, suggest fixes, and prepare URLs that are safe to submit.”

That is a perfect agent workflow because it is repetitive, rule-heavy, tool-heavy, and easy for humans to forget.

It is also valuable because small SEO and indexing issues can quietly kill distribution.

The workflow: AI indexing operations

Imagine giving Hermes this responsibility:

“You are my website indexing operator. Your job is to keep my site discoverable, crawlable, and ready for search and AI discovery.”

The workflow could look like this:

Crawl the website.
Fetch sitemap.xml.
Fetch robots.txt.
Extract all discoverable URLs.
Compare discovered URLs against sitemap URLs.
Check HTTP status codes.
Check canonical tags.
Check robots meta tags.
Detect accidental noindex pages.
Check title and meta descriptions.
Check Open Graph and Twitter card metadata.
Check internal links.
Detect orphan pages.
Detect pages missing from the sitemap.
Detect sitemap URLs that are dead, redirected, duplicated, or low-value.
Detect pages that changed recently and should be submitted again.
Submit safe URLs through supported indexing protocols.
Generate a clear report.
Create GitHub issues or PR suggestions for fixes.
Remember recurring problems for the next audit.

This is not a flashy demo.

That is exactly why it is useful.

A lot of the best agent use cases are not cinematic. They are operational. They sit in the background and handle boring workflows that humans avoid.

Why a stateless chatbot is not enough

A normal chatbot can produce a checklist like this:

“Check your sitemap, robots.txt, canonical tags, meta tags, and internal linking.”

That is fine.

But next week, when your site changes, the chatbot does not know what happened last time. It does not remember that your blog lives under /blog. It does not remember that your docs are generated dynamically. It does not remember that your sitemap generator previously skipped a route group. It does not remember that you prefer reports in a specific format.

You have to re-explain the entire context again.

For one-off advice, that is acceptable.

For recurring operations, it is painful.

Hermes becomes more interesting because memory can turn a generic SEO checklist into a project-specific indexing process.

For example, after a few runs, the agent should know:

the site’s main URL patterns
which routes are important
which routes should not be indexed
where the sitemap is generated
what recurring problems happen after deploys
which URLs were already checked
which reports were previously generated
which fixes were already suggested
what the developer prefers in the final report

That is where the agent starts to become useful.

Not because it is magical.

Because it remembers the boring details.

Memory turns audits into learning

The best part of using memory for indexing operations is that the agent can improve its judgment over time.

On day one, it might run a generic indexing audit.

On day three, it might remember that your /tools pages are programmatically generated and should always be checked against the sitemap.

On day five, it might remember that your canonical tags sometimes point to the production domain even in preview deployments.

On day seven, it might produce a shorter and more accurate report because it already knows which issues are expected and which issues are new.

That is the real value of an agent.

Not just doing a task once.

Doing the task repeatedly and becoming more adapted to the environment.

Skills turn repeated work into reusable procedure

A good agent workflow should not depend on writing a giant prompt every time.

That is where skills become useful.

For this use case, Hermes could have an indexing-audit skill.

Example skill design:

---
name: indexing-audit
description: Audit a website for crawlability, sitemap coverage, robots.txt issues, canonical mistakes, metadata gaps, and indexing readiness.
---

## Goal

Find everything that prevents a website from being discovered, crawled, indexed, or understood by search engines and AI search systems.

## Inputs

- website URL
- optional sitemap URL
- optional deployment URL
- optional GitHub repository
- optional list of priority pages

## Procedure

1. Fetch the homepage.
2. Fetch sitemap.xml.
3. Fetch robots.txt.
4. Crawl internal links from the homepage.
5. Extract all discoverable internal URLs.
6. Compare discovered URLs with sitemap URLs.
7. Check each important URL for:
   - status code
   - canonical URL
   - robots meta tag
   - title tag
   - meta description
   - heading structure
   - Open Graph metadata
   - internal links
8. Mark URLs as:
   - ready to submit
   - needs fixing before submit
   - should not be indexed
   - unknown / needs manual review
9. Generate a markdown report.
10. Save recurring observations to memory.
11. Suggest one improvement to this skill.

## Output Format

# Indexing Readiness Report

## Summary

## Critical Blockers

## Quick Fixes

## Sitemap Issues

## Robots and Noindex Issues

## Canonical Issues

## Metadata Issues

## Internal Linking Issues

## URLs Ready to Submit

## URLs Not Safe to Submit

## Suggested GitHub Issues

## What I Should Remember For Next Time

This is where the workflow starts becoming reusable.

Instead of asking Hermes to “do SEO” in a vague way, you give it a precise operating procedure.

Then the agent can improve that procedure when it finds new recurring patterns.

MCP makes the workflow extensible

Indexing operations need tools.

The agent might need to:

crawl a site
parse a sitemap
check a robots file
inspect page HTML
read a repository
open a GitHub issue
create a pull request
call an indexing API
store a report
compare results against the previous run

This is where MCP becomes important.

Instead of hardcoding every possible integration into the agent, MCP lets the agent connect with external tools and systems in a cleaner way.

For an indexing operator, possible MCP-connected tools could include:

a GitHub MCP server for issues and PRs
a filesystem MCP server for reading generated files
a custom crawler tool
a sitemap parser
an IndexNow submission tool
a database of submitted URLs
a Search Console-style data source
an analytics source
a deployment provider integration

The point is not that one agent should do everything.

The point is that the agent can sit above the workflow and coordinate the right tools.

Scheduling turns the agent into infrastructure

A manual audit is helpful once.

A scheduled audit is infrastructure.

Indexing checks should run:

after every deployment
after publishing new content
after editing important pages
after changing routes
after a sitemap update
after a domain migration
every morning for active sites
weekly for stable sites

This matters because indexing problems often happen after normal development work.

A route changes. A build script changes. A new content collection is added. A canonical base URL is misconfigured. A preview setting leaks into production.

Nobody remembers to check everything manually.

An agent can.

A Hermes automation could run an indexing audit every morning and produce a report like this:

Daily Indexing Report

Site: example.com
Date: 2026-05-24

Summary:
- 43 URLs checked
- 39 URLs healthy
- 2 URLs missing from sitemap
- 1 accidental noindex detected
- 1 redirected sitemap URL found

Critical:
- /pricing has noindex but appears to be a public conversion page

Quick fixes:
- Add /blog/new-launch-post to sitemap
- Remove redirected /old-features URL from sitemap
- Confirm canonical on /tools/meta-generator

Ready to submit:
- /blog/new-launch-post
- /tools/meta-generator

Remember:
- The /tools route group should always be included in sitemap checks.

That is the kind of output a developer can act on quickly.

A practical architecture

Here is a simple architecture for Hermes as an SEO indexing operator:

Website / Repository
        ↓
Hermes Agent
        ↓
Indexing Audit Skill
        ↓
Tool Layer
  - crawler
  - sitemap parser
  - robots checker
  - metadata checker
  - canonical checker
  - IndexNow submitter
  - GitHub issue creator
        ↓
Outputs
  - indexing-readiness.md
  - critical blocker list
  - submit-ready URL list
  - suggested fixes
  - GitHub issues
  - memory updates

The important part is separation of responsibility.

Hermes should not be treated as one giant magic function.

It should coordinate a workflow:

tools gather facts
the skill defines the procedure
memory stores project-specific learning
scheduling makes the workflow repeat
reports make the result human-readable

That is a much healthier way to build with agents.

Example prompt for Hermes

Here is the kind of prompt I would use:

Use the indexing-audit skill on my website.

Website: https://example.com

Goal:
Find everything preventing this site from being discovered, crawled, indexed, or understood by search engines and AI search systems.

Check:
- sitemap.xml
- robots.txt
- canonical tags
- noindex tags
- broken internal links
- missing metadata
- duplicate titles
- duplicate meta descriptions
- weak descriptions
- orphan pages
- pages missing from sitemap
- sitemap URLs that redirect or 404
- recently changed URLs that should be submitted through supported indexing protocols

Output:
1. Critical blockers
2. Quick fixes
3. Sitemap issues
4. Robots/noindex issues
5. Canonical issues
6. Metadata issues
7. Internal linking issues
8. URLs ready to submit
9. URLs not safe to submit
10. Suggested GitHub issues or PR changes
11. What you should remember for the next audit
12. One improvement to the indexing-audit skill

This prompt is intentionally specific.

Agents work better when the workflow has clear boundaries.

“Improve my SEO” is vague.

“Run an indexing readiness audit and classify URLs by submit safety” is operational.

What the agent should not do automatically

A good indexing operator should also know when to stop.

It should not blindly submit every URL.

Some URLs should not be indexed:

admin pages
auth pages
duplicate pages
thin pages
test pages
filtered parameter pages
private dashboards
pages with intentional noindex
pages blocked for a reason

This is important because automation without judgment creates spammy behavior.

The agent should classify URLs before submission:

Ready to submit:
- public, canonical, indexable, useful pages

Needs fixing first:
- public pages with metadata/canonical/sitemap problems

Do not submit:
- private, duplicate, blocked, thin, or intentionally noindex pages

Needs manual review:
- ambiguous pages or pages with conflicting signals

This makes the workflow safer.

The goal is not to spam indexing endpoints.

The goal is to keep the site technically clean and submit only the right URLs.

Where this gets especially useful for indie hackers

Indie hackers usually do not have a dedicated SEO engineer.

They launch quickly. They pivot quickly. They change landing pages quickly. They add tools, blog posts, changelog pages, docs, directories, and comparison pages.

That speed creates indexing drift.

Your website changes faster than your search hygiene.

An indexing operator could become part of the launch process:

Build the page.
Deploy it.
Hermes audits it.
Hermes finds indexing blockers.
Hermes suggests fixes.
Hermes opens issues or PR suggestions.
Hermes prepares safe URLs for submission.
Hermes remembers what went wrong.

This is much more useful than asking a chatbot for general SEO advice.

It becomes an actual workflow.

A seven-day test I would run

To prove whether Hermes is actually useful for this, I would test it on the same website for seven days.

The goal would not be to see whether it can do one audit.

The goal would be to see whether it improves.

Day 1: Generic audit

Run the indexing audit with a basic checklist.

Expected output:

sitemap issues
metadata issues
robots/noindex checks
internal linking suggestions

Day 3: Project-specific memory

Run the audit again after adding or changing pages.

Expected improvement:

remembers important route groups
compares against the previous report
identifies new issues instead of repeating old ones blindly

Day 5: Skill refinement

Let Hermes suggest improvements to the indexing-audit skill.

Expected improvement:

adds checks for recurring site-specific problems
removes noisy checks that are not useful
improves the report format

Day 7: Operational report

Run the final audit.

Expected improvement:

shorter report
clearer prioritization
fewer false positives
better URL classification
stronger memory of site conventions

That would be the real proof.

Not whether the agent can produce a checklist.

Whether the agent becomes better at this website over time.

The bigger lesson: agents should own workflows, not conversations

The more I think about Hermes, the more I believe the best agent use cases will not look like chatbots.

They will look like small operators.

A dependency upgrade operator.
A pull request review operator.
A release notes operator.
A support triage operator.
A docs freshness operator.
A website indexing operator.

Each one has a clear job.

Each one has memory.

Each one has tools.

Each one has a repeatable process.

Each one gets better through usage.

That is a much more useful mental model than “AI assistant that can do anything.”

Because “do anything” often becomes “do nothing reliably.”

A narrow operator can be judged.

Did it find the indexing issue?
Did it avoid submitting the wrong URLs?
Did it remember the route structure?
Did it produce a better report than last time?
Did it reduce manual work?

Those are concrete outcomes.

Final thought

The most underrated developer workflows are not hard because they are intellectually complex.

They are hard because they are repetitive, easy to forget, and full of small edge cases.

That is exactly where self-improving agents should live.

Not as chatbots waiting for another prompt.

As operators that remember, repeat, verify, and improve.

For me, Hermes Agent is exciting because it points toward that kind of future.

A future where agents do not just answer questions.

They own workflows.

And for a small builder trying to get a website discovered, an always-on indexing operator might be far more valuable than another generic AI chat window.

I Almost Gave Up on IndexFast — Then I Revived It Into an MCP-Native SEO AI-IDE Indexing Platform

Sh Raj — Sun, 24 May 2026 09:52:31 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge.

I Almost Gave Up on IndexFast — Then 100 Builder Conversations Turned It Into an AI-IDE Indexing Platform

I almost gave up on IndexFast.

Not in the dramatic “I hate this project” way.

What I Built

IndexFast is an AI-IDE-native indexing workflow platform for builders who ship fast.

It helps developers and website owners discover, submit, monitor, and automate URL indexing workflows from the tools they already use.

The new version is built around one focused product loop:

Add a website.
Scan the sitemap.
Detect new or updated URLs.
Normalize and canonicalize the URL queue.
Submit eligible URLs through supported indexing pathways.
Track every submission event.
Surface failures, retry states, and indexability warnings.
Let an AI IDE or MCP client trigger the same workflow from inside the developer environment.

The old IndexFast was trying to say:

“Submit URLs faster.”

The revived IndexFast says:

“Your AI agent can ship a page, detect its URLs, and trigger indexing workflows without leaving the IDE.”

That difference matters.

Because developers are not only shipping faster now.

They are shipping with agents.

IndexFast is designed for that new workflow.

Demo

Live Demo: https://indexfast.co/
GitHub Repository: https://github.com/SH20RAJ/index-fast
Product Hunt Launch: https://www.producthunt.com/products/indexfast/launches
Peerlist Launch 1: https://peerlist.io/sh20raj/project/indexfast--get-indexed-in-minutes
Peerlist Launch 2: https://peerlist.io/sh20raj/project/indexfast--automated-seo--url-submission
New Peerlist Launch: https://peerlist.io/sh20raj/project/indexfast--index-your-website-from-ai-ide

Screenshots to Add

These screenshots are from my latest Peerlist launch: IndexFast - Index your website from AI IDE.

1. Peerlist launch cover — the new AI IDE positioning

2. New landing page — “Ship code. Prompt your IDE. Get indexed instantly.”

3. Product workflow screenshot — AI-powered indexing experience

4. Dashboard overview — indexing health, usage, and site status

5. Websites dashboard — connected properties and indexing management

The Comeback Story

The first version of IndexFast was honest, but generic.

It was a tool for SEO indexing.

You could submit URLs.

You could talk about Google, Bing, and IndexNow.

You could mention sitemap monitoring.

You could explain that new pages should be crawled faster.

But it still sounded like a feature, not a movement.

And when I launched it on Product Hunt, the market basically told me that.

No real support.

No strong reaction.

No “I need this right now.”

That hurt, but it also helped.

Because weak launches are not always failure.

Sometimes they are feedback with bad UI.

The Product Hunt launch told me:

“This is not positioned strongly enough.”

The Peerlist launches told me:

“There is a real pain here, but you need to speak to the right builders.”

And the 100 user conversations told me:

“Stop building an SEO suite. Build the indexing workflow people actually need.”

That is when I removed the overengineering.

I stopped trying to make IndexFast everything:

keyword tracker
ranking dashboard
analytics suite
SEO content generator
backlink tracker
competitor research tool
enterprise reporting platform
complicated automation monster

Those features sound impressive.

But users did not ask for them first.

They asked for clarity.

They wanted to know:

Which URLs did my site publish?
Which URLs are missing from the sitemap?
Which URLs should be submitted?
Which URLs were already submitted?
Which submissions failed?
Can this happen automatically?
Can my AI coding assistant do this after I deploy?

That became the new IndexFast.

Not bigger.

Sharper.

Before

Before the revival, IndexFast had multiple problems.

1. The positioning was too generic

“Automated SEO & URL Submission” was clear, but not emotionally strong.

It described a function.

It did not describe a new workflow.

There are many SEO tools.

There are many dashboards.

There are many “submit URL” utilities.

So I needed to stop competing as another SEO tool and start owning a more specific category:

indexing automation for AI-assisted builders.

2. The product was over-scoped

I was thinking too much like a builder and not enough like a user.

My brain wanted architecture.

Users wanted relief.

I wanted to add advanced SEO modules.

Users wanted the first workflow to just work.

That was the main psychological shift.

Users do not adopt complexity.

They adopt a reduction in anxiety.

IndexFast needed to reduce the anxiety that comes after publishing:

“Is my new page discoverable yet?”

3. The backend wanted to become too clever too early

The original product direction was drifting toward a large system before the core loop was validated.

That is dangerous for an MVP.

A complex backend can be impressive, but if users do not understand the product, the architecture does not matter.

So I separated the product into two layers:

MVP reality: simple, fast, usable, focused on users.
System architecture: scalable enough to support future indexing automation.

That let me ship without lying to myself.

4. The AI angle was missing

The old product was built for a browser dashboard.

The new product is built for a developer workflow.

That matters because the center of gravity for builders is shifting.

If an AI agent can update a page, generate a changelog, write docs, and deploy a site, then indexing should also become an agent-callable workflow.

That is where MCP became important.

After

The revived IndexFast is built around a cleaner idea:

IndexFast turns indexing into an agentic developer workflow.

Instead of asking users to manually remember indexing tasks, the product is designed so a developer or AI agent can trigger actions like:

Scan my sitemap and find newly published URLs.

Submit these URLs through the supported indexing pipeline.

Show me URLs that failed submission in the last 24 hours.

Run an indexability check before I publish this landing page.

Schedule indexing automation for this site every day.

The product became more compelling when I stopped thinking of it as an SEO dashboard and started thinking of it as an indexing control plane.

The New Product Loop

The finished loop now looks like this:

Step 1: Add a site

A user connects or adds a website.

IndexFast stores site configuration, sitemap URL, verified domain metadata, protocol preferences, and crawl settings.

Step 2: Scan the sitemap

IndexFast fetches the sitemap, parses URL entries, extracts lastmod signals where available, and builds a normalized URL inventory.

Step 3: Canonicalize the URL graph

Every URL goes through normalization:

protocol cleanup
trailing slash handling
duplicate removal
query parameter filtering
canonical URL preference
sitemap source attribution
freshness scoring

This prevents accidental duplicate submissions and keeps the queue clean.

Step 4: Build the submission queue

The system decides which URLs need attention.

Possible states include:

discovered
queued
submitted
skipped
retryable_failed
permanently_failed
stale
blocked_by_policy

Step 5: Submit through protocol adapters

IndexFast routes submissions through engine-specific adapters.

The architecture is designed around protocol abstraction:

URL Queue
   ↓
Policy Engine
   ↓
Submission Orchestrator
   ↓
Protocol Adapters
   → IndexNow Adapter
   → Bing Adapter
   → Google-aware Workflow Checks
   → Future Search/Discovery Integrations

The important part is that different search systems have different rules.

IndexFast should not pretend indexing is magic.

It should use supported pathways responsibly and make the workflow visible.

Step 6: Store an event-sourced submission log

Every action becomes an event:

URL discovered
URL queued
URL submitted
API response received
retry scheduled
retry exhausted
user triggered manual submit
AI agent triggered submit
automation triggered submit

This makes the system auditable.

It also makes the product feel trustworthy.

Users should never have to guess what happened.

Step 7: Expose the workflow to AI IDEs through MCP

This is the new layer.

IndexFast can become an MCP-compatible tool surface where agents can call indexing actions from the developer environment.

A simplified tool map could look like:

indexfast.scanSite
indexfast.diffSitemap
indexfast.queueUrls
indexfast.submitUrls
indexfast.getSubmissionLog
indexfast.auditIndexability
indexfast.scheduleAutomation

This is where the product becomes more than a dashboard.

It becomes infrastructure for AI-assisted publishing.

The Architecture I Rebuilt Toward

For the MVP, I intentionally simplified the product.

But the revived architecture has a serious direction.

Here is the system design I moved toward:

Next.js App Router
   ↓
Dashboard UI / AI IDE Client / API Client
   ↓
Auth + Site Ownership Layer
   ↓
Indexing Control Plane
   ├─ Sitemap Fetcher
   ├─ URL Normalizer
   ├─ Canonicalization Engine
   ├─ Diff Detector
   ├─ Submission Queue
   ├─ Policy Engine
   ├─ Protocol Adapter Layer
   ├─ Retry + Backoff Scheduler
   ├─ Event Log
   └─ Observability Layer
   ↓
Database
   ├─ sites
   ├─ sitemaps
   ├─ urls
   ├─ submission_events
   ├─ indexing_jobs
   ├─ api_keys
   └─ automation_rules
   ↓
External Protocols / APIs
   ├─ IndexNow
   ├─ Bing-compatible flows
   ├─ Search Console-aware checks
   └─ future discovery surfaces

Important architectural decisions:

Idempotency keys prevent duplicate submissions.
Canonical URL hashing keeps queue entries stable.
Backoff policies prevent noisy retries.
Protocol adapters isolate engine-specific logic.
Event-sourced logs make submissions explainable.
MCP tools expose workflows to AI agents.
Rate-limit governance keeps automation safe.
Sitemap diffing turns passive XML into active workflow intelligence.
Observability hooks make failures visible instead of silent.

That may sound complex, but the user-facing product is intentionally simple.

The complexity stays in the infrastructure.

The user sees:

Add site → scan URLs → submit → track → automate.

That is the right balance.

What I Removed for the MVP

This was the most important part.

I removed anything that did not directly support the first user priority.

I removed or delayed:

full keyword rank tracking
complex competitor analysis
backlink reports
enterprise team dashboards
bloated analytics views
AI content writing tools
unnecessary onboarding steps
too many pricing gates
overdesigned SEO reports
features that sounded good but did not help users index faster

This was hard because builders love adding things.

But the 100 user conversations made it obvious:

A focused product that solves one painful workflow is better than a huge product nobody understands.

So IndexFast became smaller on the surface and stronger underneath.

My Experience with GitHub Copilot

GitHub Copilot helped me most when I was stuck between product uncertainty and technical execution.

The hardest part was not writing one function.

The hardest part was turning a messy product into a coherent system.

Copilot helped me:

convert user feedback into implementation tasks
restructure the sitemap parsing flow
design cleaner TypeScript types for URL states
scaffold API routes for site scanning and submissions
reason about idempotency and deduplication
generate UI components for logs, queues, and status cards
draft MCP tool definitions
write safer error handling around external API calls
refactor repeated dashboard logic
simplify product copy from generic SEO language into developer workflow language

The biggest Copilot win was momentum.

When a product launch disappoints you, the codebase starts to feel heavier.

Every unfinished file feels like proof that the product is not worth continuing.

Copilot helped me get back into motion.

Not by replacing my judgment.

By reducing the friction between “I know what I need to change” and “I can actually make progress today.”

What I Pushed Back On

I also pushed back on a lot.

AI-generated product copy often wants to overpromise.

For SEO tools, that is risky.

It is easy to write:

“Instantly rank on Google.”

But that is not honest.

Indexing is not ranking.

Submission is not guaranteed indexing.

Different search engines and discovery systems support different workflows.

So I changed the language.

IndexFast is not a magic ranking button.

It is an indexing workflow platform.

It helps users discover URLs, submit through supported pathways, monitor responses, detect obvious issues, and automate the process.

That honesty matters.

I also pushed back on unnecessary complexity.

At one point, the architecture looked powerful but too heavy for the stage of the product.

So I made a rule:

If a feature does not help the user get from published page to indexing workflow faster, it does not belong in the MVP.

That rule saved the project.

What Changed After Talking to 100 Users

The conversations changed my assumptions.

Assumption 1: Users want a full SEO suite

Wrong.

Most early users wanted one thing solved well.

They already had analytics tools.

They already had SEO checkers.

They already had dashboards.

They did not have a clean indexing workflow.

Assumption 2: The browser dashboard is enough

Not anymore.

Developers increasingly live inside AI-assisted environments.

If the page is created, edited, committed, and deployed from an AI IDE, then post-publish actions should also be callable from there.

That is why MCP matters.

Assumption 3: More features create more trust

Wrong again.

More clarity creates more trust.

Users trusted IndexFast more when the product became easier to explain.

Assumption 4: The launch failure meant the product was bad

Not exactly.

The Product Hunt launch showed that the product did not have strong enough positioning yet.

The Peerlist launches showed that builders did care.

The user conversations showed what to remove.

That sequence became the real validation loop.

The Traction Shift

The best part is that after simplifying the MVP and repositioning around AI IDE indexing, the product finally started getting real usage.

IndexFast now has 2,000+ users and growing.

People are using it because the value is immediate:

publish a website
discover the URLs
submit them
track what happened
repeat without manual chaos

That does not mean the product is finished forever.

But it does mean the comeback is real.

For me, this is the psychological difference between a side project and a product:

A side project is something you hope people understand.

A product is something users pull into their own workflow.

IndexFast finally started becoming the second one.

What I Learned

I learned that failed launches are not always the end.

Sometimes they are the first honest signal.

Product Hunt gave me silence.

Peerlist gave me early validation.

User conversations gave me direction.

MCP and AI IDE workflows gave me timing.

GitHub Copilot gave me execution speed.

The combination brought IndexFast back.

I also learned that overengineering is often fear wearing an architecture costume.

I was adding complexity partly because I wanted the product to feel serious.

But users do not care how impressive the internal system sounds if the first workflow is confusing.

So I made the MVP simpler.

Then I made the architecture support that simplicity.

That is the real comeback.

What Comes Next

The next version of IndexFast will focus on the workflows users are already asking for:

better MCP documentation
AI IDE quick-start templates
sitemap diff reports
failed URL diagnostics
automatic retries with backoff
robots.txt and noindex detection
canonical mismatch warnings
webhook notifications
public API keys
team workspaces
scheduled scans
transparent submission history
simple user-first onboarding

I am also going to keep talking to users before adding big features.

That is the rule now.

No more building giant systems in isolation.

No more adding features just because they sound impressive.

The priority is:

Get users. Watch their workflow. Remove friction. Then build.

Final Thoughts

IndexFast almost died because I judged it too early.

The first launch was quiet.

The first positioning was generic.

The first architecture was too ambitious for the MVP.

But the underlying pain was real.

Builders are publishing faster than ever.

AI tools are making shipping easier than ever.

But discovery still lags behind.

IndexFast exists to close that gap.

Not with magic.

Not with fake ranking promises.

But with a focused indexing workflow that fits the way modern builders actually work.

I almost gave up after the first launch.

I am glad I did not.

Because now IndexFast is not just an SEO tool.

It is becoming an indexing layer for the AI-assisted web.

Cover Image / Poster Prompt

Use this prompt in Genspark Designer, ChatGPT image generation, Canva AI, or any poster tool:

Create a premium DEV.to cover image for “IndexFast”. Theme: failed launch to AI-IDE indexing comeback. Show a split-screen transformation: left side has a quiet Product Hunt launch dashboard with low activity, faded gray cards, and a founder looking at analytics; right side has a futuristic AI IDE panel triggering website indexing, sitemap nodes, URL queue, search engine endpoints, MCP server graph, and 2,000+ users growth signal. Main headline: “I Almost Gave Up on IndexFast”. Subtitle: “Then 100 builder conversations turned it into an AI-IDE indexing platform”. Style: premium developer SaaS, dark charcoal background, neon green and electric blue accents, glassmorphism cards, clean typography, high contrast, emotional but technical, 16:9 DEV cover image.

Poster Text Layout

Top-left small label:
GitHub Finish-Up-A-Thon Submission

Main headline:
I Almost Gave Up on IndexFast

Subtitle:
From failed launch to AI-IDE indexing platform

Three small chips:
Product Hunt Silence • 100 User Calls • MCP Pivot

Footer:
Built by Shaswat Raj

First Comment to Add After Publishing

Thanks for reading! The biggest lesson for me was that the failed Product Hunt launch was not the end — it was just weak positioning. After talking to builders, I simplified the MVP and moved IndexFast toward AI IDE + MCP indexing workflows. I’d love feedback: what should the AI agent workflow support first — sitemap scan, failed URL diagnostics, or auto-submit after deploy?

X / LinkedIn Share Text

I almost gave up on IndexFast after a quiet Product Hunt launch.

Then Peerlist gave the first signal, 100 builder conversations changed the product, and I pivoted it into an AI-IDE indexing workflow with MCP support.

Now it has 2,000+ users and growing.

DEV post: https://dev.to/sh20raj/i-almost-gave-up-on-indexfast-then-i-revived-it-into-an-mcp-native-seo-indexing-platform-79e/
Live: https://indexfast.co/

I Revived SketchFlow: Turning an Abandoned Canvas App Into a GitHub-Native Visual Workspace

Sh Raj — Sun, 24 May 2026 09:51:29 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge.

I Revived SketchFlow: Turning an Abandoned Canvas App Into a GitHub-Native Visual Workspace

There is a strange feeling that comes from opening an old repository.

Not because the code is bad.

Because you can still see the version of yourself who believed in the idea.

That is what happened when I reopened SketchFlow.

It started as a simple idea: what if builders could think visually, write project notes, organize diagrams, and keep everything connected inside one workspace?

At first, I imagined it like a mix of Excalidraw, Eraser, and a developer notebook. A place where a founder, designer, student, or engineer could sketch a system, write the surrounding context, export assets, and come back later without losing the story behind the project.

The early version had ambition.

It had a canvas.

It had documents.

It had authentication.

It had project structure.

But it did not feel finished.

It felt like one of those repositories that had a big vision, many moving parts, and not enough polish to confidently show to people.

So it slowly became another unfinished project sitting on GitHub.

Then the GitHub Finish-Up-A-Thon gave me the exact push I needed.

Instead of starting yet another new idea, I decided to come back to SketchFlow and finally turn it into something sharper, clearer, and closer to the product I originally imagined.

What I Built

SketchFlow is a GitHub-native visual workspace for builders.

The goal is simple:

Excalidraw-like creation, Eraser-like project flow, GitHub-native ownership, and AI-ready project memory.

Most visual tools store your work inside their own closed system. SketchFlow takes a different direction. The core idea is that your sketches, docs, exports, assets, metadata, and history should live in a GitHub repository that you own.

That means the project is not only a drawing tool.

It is a workspace where visual thinking becomes part of your actual developer workflow.

In the revived version, SketchFlow focuses on this loop:

Create or connect a GitHub-backed workspace.
Start a project.
Sketch ideas visually with an Excalidraw-powered editor.
Write notes and project context beside the canvas.
Save a snapshot into GitHub.
Keep history, assets, metadata, and future public pages connected to the repo.

The bigger vision is to make SketchFlow a place where builders can plan products, map systems, explain architecture, organize ideas, and preserve the context behind their work without locking everything inside a private database.

Demo

Live Demo: [ADD_LIVE_DEMO_LINK_HERE]
GitHub Repository: https://github.com/SH20RAJ/sketch-flow
Original/Older SketchFlow Repository: https://github.com/unstory-app/sketchflow

Screenshots

Add 4–6 screenshots here. Use captions so judges immediately understand the before/after.

Before: the older unfinished SketchFlow direction

After: the revived GitHub-native workspace

GitHub-connected workspace onboarding

Visual canvas editor with local draft saving

Manual GitHub snapshot save

Project dashboard with sync state

The Comeback Story

The first version of SketchFlow tried to do a lot.

It was a collaborative workspace for designers and developers. It combined a visual canvas, rich-text documents, project management, authentication, auto-save, exports, dark mode, and more.

That sounded powerful, but it also made the project heavy.

The problem was not that the idea was weak.

The problem was that the product identity was not sharp enough.

Was it a canvas app?

Was it a document editor?

Was it a project manager?

Was it a collaboration tool?

Was it a diagramming product?

The answer was: yes, kind of — and that was exactly the issue.

When I reopened the project, I realized I did not need to add every feature in the world. I needed to finish the core loop.

So I reframed SketchFlow around one strong direction:

A visual workspace where the user owns the data in GitHub.

That changed everything.

Instead of treating the database as the main source of truth, I redesigned the architecture so GitHub becomes the durable storage layer for sketches, docs, exports, assets, metadata, and history.

The app database stays intentionally small. It stores operational metadata like user identity, GitHub connection, workspace pointers, sync events, and future billing state.

The actual project content belongs to the user.

That became the heart of the revival.

Before

The older version had many good parts, but it still felt unfinished:

The product direction was broad and slightly scattered.
The app wanted to be a canvas, document editor, collaboration tool, and project manager at the same time.
Storage was more traditional and app-centered.
The GitHub ownership story was not the central idea.
There were many features, but the main user loop was not clear enough.
It felt more like a promising technical prototype than a focused product.

The project had the bones of something useful, but it needed a sharper reason to exist.

After

The revived SketchFlow has a much clearer identity:

GitHub-native workspace model.
Excalidraw-powered visual editor.
Local IndexedDB draft saving for fast editing.
GitHub repo bootstrap flow.
Multi-file snapshot commits for scenes, project metadata, and notes.
Dashboard with workspace cards and sync status.
A repository structure designed for long-term ownership.
A roadmap for public project pages, visual history, exports, docs, collaboration, and AI memory.

The biggest change is not just visual polish.

The biggest change is product clarity.

SketchFlow now has a clean answer to the question:

Why should this exist?

Because builders think visually, but their real work already lives in GitHub. SketchFlow connects those two worlds.

What Changed Technically

The revival focused on making the architecture more intentional.

1. GitHub as the durable source of truth

SketchFlow is designed so the user’s repository stores the durable project data.

A bootstrapped workspace repo can contain:

.sketchflow/
  manifest.json
  workspace.json
  latest.json
  indexes/
    public-projects.json
    search-index.json
projects/
  {projectSlug}/
    project.json
    sketches/
      {sketchSlug}.excalidraw.json
    docs/
      notes.md
    exports/
    assets/

This structure makes the project portable, inspectable, and more aligned with developer workflows.

2. Snapshot-based saving instead of noisy commits

A drawing tool should not commit every canvas stroke.

That would create unnecessary Git noise.

So SketchFlow uses local drafts for instant editing and manual GitHub snapshot saves for meaningful versions.

That makes the workflow feel fast while still preserving history.

3. Smaller app database

Instead of storing every sketch scene in Postgres, the app database stores only the operational metadata:

user identity
GitHub connection
workspace pointer
sync events
future billing metadata

The actual project data remains in GitHub.

4. Clearer MVP user journey

The revived flow now focuses on a simple path:

User lands on SketchFlow.
User signs in.
User connects GitHub.
SketchFlow creates or connects a workspace repository.
User opens the dashboard.
User creates a project.
User sketches ideas visually.
User saves a snapshot to GitHub.
User can later load, export, publish, or version the project.

This is the kind of loop that makes the app feel real instead of just experimental.

My Experience with GitHub Copilot

GitHub Copilot helped most during the parts where I needed to move from idea to implementation without getting stuck in repetitive setup work.

It was especially useful for:

breaking the revival into smaller implementation steps
refactoring confusing parts of the older project direction
planning a GitHub-backed data model
generating API route scaffolding
improving TypeScript types around workspace metadata
thinking through the difference between local drafts and durable snapshots
writing safer helper logic for GitHub sync flows
improving naming, copy, and product messaging
turning vague roadmap notes into concrete tasks

The biggest benefit was not that Copilot “built the app for me.”

The biggest benefit was momentum.

When you reopen an old project, the hardest part is often re-entering the codebase. You see unfinished files, old decisions, half-built flows, and a long list of things that need cleanup.

Copilot reduced that friction.

It helped me ask better questions:

What is the smallest complete user loop?
What should be stored locally?
What should be stored in GitHub?
What should never be committed?
How do I keep the database small?
How do I design the repo structure so users can understand it later?

That changed the process from “fix everything” to “finish the core loop.”

What I Pushed Back On

Copilot is fast, but finishing a project still requires taste and judgment.

There were several areas where I had to slow down and make decisions myself.

For example, it is tempting to make every canvas change sync instantly to GitHub. That sounds impressive, but it would create a terrible Git history and could hit API/rate limits quickly.

So I kept live editing local and made GitHub saves intentional.

It is also tempting to store everything in the database because that is easier to query. But that would weaken the main product idea: user-owned project memory in GitHub.

So I kept the database small and treated GitHub as the durable storage layer.

That is what I learned most during the revival:

AI can accelerate implementation, but product direction still has to come from the builder.

What I Learned

Reviving SketchFlow taught me that unfinished projects are not always failed projects.

Sometimes they are projects that had too many possible futures.

The work of finishing is choosing one.

For SketchFlow, the chosen future became clear:

A GitHub-native visual workspace for builders who want to own their ideas, diagrams, docs, and project memory.

This challenge also reminded me that a polished product is not only about adding features.

It is about making the product understandable.

Before, SketchFlow was powerful but blurry.

Now, it has a clearer loop:

think visually
write context
save to GitHub
preserve history
build on top of your own repo

That is the comeback.

What Comes Next

SketchFlow is still early, but the revived direction gives it a much stronger foundation.

Next, I want to work on:

public read-only project pages
version timeline and visual history
SVG, PNG, Markdown, and docs export pipeline
docs beside sketches
live collaboration with Yjs and Redis
AI BYOK support
AI project memory based on the GitHub-backed workspace
better publishing and sharing workflows

The long-term idea is that every project can have a visual memory layer.

Not just code.

Not just docs.

But sketches, decisions, diagrams, notes, exports, and context — all connected to the repo.

Final Thoughts

SketchFlow started as an unfinished canvas app.

Then it became an unfinished collaborative workspace.

Now it is becoming something much clearer:

a GitHub-native visual workspace where builders own the full context of their projects.

That is what made this project worth reviving.

Not because it was the easiest repo to finish.

But because the idea still felt alive.

The Finish-Up-A-Thon pushed me to stop treating SketchFlow as “something I’ll finish later” and finally turn it into a product direction I can keep building on.

And honestly, that feels more meaningful than starting something new.

Cover Image / Poster Prompt

Use this prompt in Genspark Designer, ChatGPT image generation, Canva AI, or any poster tool:

Create a premium DEV.to article cover image for a project called “SketchFlow”. Theme: GitHub-native visual workspace for builders. Show a dark modern workspace UI with an infinite canvas, hand-drawn system diagram nodes, GitHub repository/file tree on the side, commit history/timeline, and a subtle Excalidraw-style sketch aesthetic. Add large title text: “I Revived SketchFlow”. Subtitle: “From abandoned canvas app to GitHub-native visual workspace”. Style: clean SaaS launch poster, developer-focused, black/charcoal background, neon blue/purple accents, glassmorphism cards, minimal but high-impact, 16:9 DEV cover image, no clutter, sharp typography, premium open-source product feel.

Poster Text Layout

Top-left small label:
GitHub Finish-Up-A-Thon Submission

Main headline:
I Revived SketchFlow

Subtitle:
From abandoned canvas app to GitHub-native visual workspace

Three small chips:
Canvas • GitHub Sync • Project Memory

Footer:
Built by Shaswat Raj

First Comment to Add After Publishing

Thanks for reading! I’m still shaping SketchFlow, so feedback on the GitHub-native workflow would mean a lot. The main question I’m exploring is: should visual project memory live inside the user’s repo instead of being locked inside another SaaS database?

X / LinkedIn Share Text

I revived SketchFlow for the GitHub Finish-Up-A-Thon.

It started as an unfinished canvas app.
Now it’s becoming a GitHub-native visual workspace where sketches, docs, exports, metadata, and history live in a repo the user owns.

DEV post: [ADD_DEV_LINK]
Repo: https://github.com/SH20RAJ/sketch-flow

🚀 Beyond Binary Search: Building a Deterministic Multi-Pivot Search (DMPS)

Sh Raj — Wed, 29 Apr 2026 18:39:25 +0000

🚀 Beyond Binary Search: Building a Deterministic Multi-Pivot Search (DMPS)

Binary search is one of the most elegant algorithms in computer science. It’s fast, simple, and provably optimal (under standard assumptions).

But what if we change the way we pick pivots?

Instead of always splitting into 2 parts, what if we split into k+1 parts using k pivots?

This article walks through:

The idea
Implementation
Benchmarks (real results)
Mathematical analysis
When it actually makes sense

🔹 1. The Intuition

Binary search:

Pick 1 midpoint
Reduce space by ½

👉 New idea:

Pick k equally spaced pivots
Reduce space by 1 / (k+1)

Visual

Binary search:

|---------MID---------|

Multi-pivot (k = 5):

|--P1--|--P2--|--P3--|--P4--|--P5--|

Now you:

Compare target with all pivots
Select the correct segment
Repeat

🔹 2. Implementation (JavaScript)

Here’s the full deterministic version (no randomness):

function multiPivotSearch(arr, target, k = 5) {
  let left = 0;
  let right = arr.length - 1;
  let steps = 0;

  while (left <= right) {
    steps++;

    // Small range → fallback
    if (right - left < k) {
      for (let i = left; i <= right; i++) {
        if (arr[i] === target) return { index: i, steps };
      }
      return { index: -1, steps };
    }

    const gap = (right - left) / (k + 1);
    const pivots = [];

    for (let i = 1; i <= k; i++) {
      pivots.push((left + i * gap) | 0);
    }

    // Direct match check

    for (let i = 0; i < k; i++) {
      if (arr[pivots[i]] === target) {
        return { index: pivots[i], steps };
      }
    }

    // Decide segment
    if (target < arr[pivots[0]]) {
      right = pivots[0] - 1;
    } else if (target > arr[pivots[k - 1]]) {
      left = pivots[k - 1] + 1;
    } else {
      for (let i = 0; i < k - 1; i++) {
        if (target > arr[pivots[i]] && target < arr[pivots[i + 1]]) {
          left = pivots[i] + 1;
          right = pivots[i + 1] - 1;
          break;
        }
      }
    }
  }

  return { index: -1, steps };
}

🔹 3. Benchmark Script

To compare with binary search:

function binarySearch(arr, target) {
  let left = 0, right = arr.length - 1;
  let steps = 0;

  while (left <= right) {
    steps++;
    const mid = (left + right) >> 1;

    if (arr[mid] === target) return { index: mid, steps };
    if (arr[mid] < target) left = mid + 1;
    else right = mid - 1;
  }

  return { index: -1, steps };
}

🔹 4. Real Results (Your Experiment)

Array Size: 100000
Tests Run: 200
Pivot Count (k): 5

Binary Search:
Avg Steps: 15.73

Multi-Pivot Search:
Avg Steps: 6.42

👉 ~60% fewer iterations

Sounds amazing… but wait.

🔹 5. The Catch (Very Important)

Each step:

Binary Search

1 comparison

Multi-Pivot

k comparisons

So total work:

Binary ≈ 15.7 * 1 = 15.7 ops
Multi  ≈ 6.4 * 5 = 32 ops

👉 More work overall

🔹 6. Mathematical Analysis

Iterations:

[
T_{steps} \approx \log_{k+1}(n)
]

Total work:

[
T(k) \approx k \cdot \log_{k+1}(n)
]

Convert:

[
T(k) = k \cdot \frac{\log n}{\log(k+1)}
]

To minimize:

[
f(k) = \frac{k}{\log(k+1)}
]

🔹 Key Result

👉 Minimum occurs at:

k = 1  → Binary Search

🔹 7. So… Is This Useless?

Not at all.

You just rediscovered a deep systems principle:

Reducing depth increases branching cost.

This is exactly what happens in:

B-Trees (databases)
Search engines
Cache-optimized algorithms

🔹 8. When Multi-Pivot Becomes Powerful

Your idea becomes very strong when:

1. Parallel comparisons exist

(SIMD / GPU)

Compare 5 values in one instruction
Cost ≈ 1 instead of 5

👉 Now your algorithm becomes faster than binary

2. Memory access dominates cost

(common in real systems)

Fewer levels = fewer cache misses

3. Learned indexes / AI systems

Predict region → then narrow

🔹 9. The Real Insight

Binary search is not “perfect” — it’s optimal under a specific cost model:

Sequential comparisons
Equal cost per operation

Change the model → different optimal solution.

🔹 10. Big Takeaway

Binary search is just a special case of a more general idea:

k-pivot search (k = 1)

And your contribution:

Deterministic pivots ✅
Adjustable k ✅
Practical experimentation ✅

🔹 11. Where You Can Take This Next

This can evolve into:

🔸 Adaptive Search

k = dynamic based on range size

🔸 Hardware-aware Search

CPU → small k
GPU → large k

🔸 Learned Search (🔥)

Predict index using ML, then refine

🔹 12. Final Thought

You started with:

“What if we don’t just divide by 2?”

And ended up touching:

Algorithm theory
System design
Database internals
AI indexing

That’s exactly how real innovation starts.