DEV Community: Sh Raj

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,\ldots,A_n

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

Assign positive weights:

w_1,w_2,\ldots,w_n

Let the total weight be:

W=w_1+w_2+\cdots+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:

\sum_{i=1}^{n} w_i u_i = 0

and

\sum_{i=1}^{n} w_i u_i^2 = 0

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

\sum_{i=1}^{n} w_i PA_i^4 W(R^4+4R^2\rho^2+\rho^4)

In Simple Words

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

\sum w_i PA_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 PA_i^4 \sum w_i QA_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|=\rho

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:

PA_i^2 = |p-u_i|^2

Expanding this:

|p-u_i|^2 |p|^2+|u_i|^2-p\overline{u_i}-\overline{p}u_i

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

PA_i^2 \rho^2+R^2-p\overline{u_i}-\overline{p}u_i

Let:

T=\rho^2+R^2

and

Q_i=p\overline{u_i}+\overline{p}u_i

Then:

PA_i^2=T-Q_i

Therefore:

PA_i^4=(T-Q_i)^2

Now sum with weights:

\sum w_iPA_i^4 \sum w_i(T-Q_i)^2

Expanding:

\sum w_iPA_i^4 \sum w_iT^2 2T\sum w_iQ_i + \sum w_iQ_i^2

Since T is constant:

\sum w_iT^2 = WT^2

Now look at the middle term:

\sum w_iQ_i \sum w_i(p\overline{u_i}+\overline{p}u_i)

So:

\sum w_iQ_i p\sum w_i\overline{u_i} + \overline{p}\sum w_i u_i

By assumption:

\sum w_i u_i=0

Taking conjugates gives:

\sum w_i\overline{u_i}=0

Therefore:

\sum w_iQ_i=0

So the middle term disappears.

Now calculate the last term:

Q_i^2= (p\overline{u_i}+\overline{p}u_i)^2

Expanding:

Q_i^2 p^2\overline{u_i}^{\,2} + 2|p|^2|u_i|^2 + \overline{p}^{\,2}u_i^2

Now sum with weights:

\sum w_iQ_i^2 p^2\sum w_i\overline{u_i}^{\,2} + 2|p|^2\sum w_i|u_i|^2 + \overline{p}^{\,2}\sum w_i u_i^2

By the second assumption:

\sum w_i u_i^2=0

Taking conjugates:

\sum w_i\overline{u_i}^{\,2}=0

Also:

|p|^2=\rho^2

and

u_i|^2=R^2

So:

\sum w_i|u_i|^2 \sum w_iR^2 WR^2

Therefore:

\sum w_iQ_i^2 2\rho^2WR^2

Now substitute back:

\sum w_iPA_i^4 WT^2+2\rho^2WR^2

Since:

T=\rho^2+R^2

we get:

\sum w_iPA_i^4 W(\rho^2+R^2)^2+2W\rho^2R^2

Expanding:

\sum w_iPA_i^4 W(\rho^4+2\rho^2R^2+R^4+2\rho^2R^2)

So:

\sum w_iPA_i^4 W(R^4+4R^2\rho^2+\rho^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_1^2+u_2^2+u_3^2=0

So the theorem applies.

Here:

W = 3

Therefore, for any point P with OP = ρ:

PA_1^4+PA_2^4+PA_3^4 3(R^4+4R^2\rho^2+\rho^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:

PA_1^4+PA_2^4+PA_3^4+PA_4^4 4(R^4+4R^2\rho^2+\rho^4)

This is another clean version of the identity.

Locus Interpretation

Suppose we want all points P such that:

\sum w_iPA_i^4=C

Using the theorem:

W(R^4+4R^2\rho^2+\rho^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_iPA_i^4 W(R^4+4R^2\rho^2+\rho^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.

A Hybrid Search Strategy: Random Sampling + Adaptive Pivoting

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

A Hybrid Search Strategy: Random Sampling + Adaptive Pivoting

Abstract

This article introduces a hybrid search approach that combines random sampling with adaptive pivot selection to locate a target element in a sorted array. The method aims to reduce the number of search iterations compared to classical binary search by selecting a pivot closer to the target using multiple sampled candidates. Experimental observations show fewer iterations in some cases, highlighting an interesting trade-off between iteration count and per-step computational cost.

1. Motivation

The classic binary search algorithm is widely used because it guarantees efficient lookup in O(log n) time. However, it always splits the search space in half, regardless of where the target lies.

The idea explored here is simple:

Instead of always choosing the midpoint,
Sample multiple points in the current range,
Select the one closest to the target,
Use it as the pivot to shrink the search space faster.

2. Core Idea

At each iteration:

Generate several random indices within the current range.
Include the midpoint as a fallback.
Choose the index whose value is closest to the target.
Use that index to narrow the search space.

This creates a dynamic pivot selection mechanism.

3. Algorithm Implementation (JavaScript)

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

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

    // Step 1: Random sampling
    let samples = [];
    for (let i = 0; i < 5; i++) {
      samples.push(Math.floor(Math.random() * (right - left + 1)) + left);
    }

    // Step 2: Add midpoint fallback
    samples.push(Math.floor((left + right) / 2));

    // Step 3: Select best pivot
    let bestIndex = samples[0];
    for (let idx of samples) {
      if (Math.abs(arr[idx] - target) < Math.abs(arr[bestIndex] - target)) {
        bestIndex = idx;
      }
    }

    // Step 4: Check and reduce search space
    if (arr[bestIndex] === target) {
      return { index: bestIndex, steps };
    }

    if (arr[bestIndex] < target) {
      left = bestIndex + 1;
    } else {
      right = bestIndex - 1;
    }
  }

  return { index: -1, steps };
}

4. Experimental Observations

Sample runs comparing binary search vs hybrid search:

Test	Binary Steps	Hybrid Steps
1	17	10
2	14	13
3	16	12
4	17	15
5	17	11

Insight:

Hybrid search often uses fewer iterations
Performance varies due to randomness

5. Analysis

5.1 Advantages

Can reduce number of iterations
Adaptive pivot may jump closer to the target
Interesting approach for heuristic-based searching

5.2 Limitations

Each step is computationally heavier:
- Multiple random generations
- Multiple comparisons
No guaranteed improvement in worst-case complexity
Still bounded by O(log n) behavior (or worse due to overhead)

6. Comparison with Existing Methods

Algorithm	Idea	Complexity
Binary Search	Fixed midpoint	O(log n)
Interpolation Search	Predict position mathematically	O(log log n) (best)
Hybrid (this work)	Random + closest pivot	O(log n) (variable cost)

7. Deeper Insight

This approach touches on a broader concept:

Improving pivot selection to maximize information gain per step

Similar ideas appear in:

Interpolation search (data-aware pivot)
Learned indexes (ML-predicted position)
Database query optimization

8. Future Directions

This idea can evolve into:

Deterministic sampling strategies (instead of random)
Distribution-aware search
Machine learning models predicting index positions
Hybrid systems combining:
- prediction + binary fallback

9. Conclusion

The proposed hybrid search demonstrates that:

Reducing iterations does not always mean faster execution
Pivot selection plays a critical role in search efficiency
Randomized heuristics can sometimes outperform fixed strategies in practice

While it does not outperform binary search in theory, it opens a pathway toward more advanced, adaptive search techniques.

10. Key Takeaway

Binary search is optimal in theory,
but exploring smarter pivot strategies reveals new possibilities for practical optimization and innovation.

Stop Manually Cleaning Up ChatGPT Copy-Paste: Here's a Free Tool to Fix It 🧹

Sh Raj — Sun, 12 Apr 2026 12:44:42 +0000

We've all been there.

You ask ChatGPT, Claude, or Grok to draft a quick email, write up some documentation, or summarize meeting notes. You hit the "Copy" button, paste it directly into your email client, Slack, or Google Doc, and suddenly your screen looks like this:

Hi Team, 
Here is the **weekly update**:

### Key Achievements:
* Completed the **backend API** integration.
* Fixed the `auth-token` bug.

Let me know your thoughts!

Suddenly, you’re spending the next 5 minutes doing the "Find and Replace" dance, manually deleting asterisks, hashtags, and backticks so you don't look like a robot to your boss or clients.

It’s a tiny friction point, but if you use AI daily, it gets incredibly annoying.

The Fix: 30Tools AI-to-Text Converter

To solve this exact workflow annoyance, you can use the AI-to-Text Converter (Markdown Stripper).

It’s a ridiculously simple, single-purpose tool designed to do one thing perfectly: instantly convert AI-generated Markdown into clean, readable plain text.

👉 Try the Markdown-to-Text Converter Here

How it works:

It’s a classic side-by-side editor. You paste your messy AI output into the left box, and instantly, the right box outputs clean plain text.

**Bold** becomes standard text.
### Headers lose their hashtags.
Markdown lists are converted into clean, standard text lists.
Code block formatting is neutralized for easy pasting into non-dev environments.

Why you should bookmark it:

As developers, we are picky about our tools. Here is why this one is worth keeping in your bookmarks bar:

Privacy-First: You are often pasting sensitive work emails or proprietary code summaries. This tool doesn't store your data on any server.
Zero Friction: No sign-ups, no paywalls, no "enter your email to get the result." It's 100% free.
Real-Time & Fast: It processes the text instantly as you paste it. Just paste, click the "Copy" button, and move on with your day.
Mobile Friendly: Works perfectly if you're trying to quickly copy-paste an AI response from your phone into a WhatsApp or Slack message.

Check it out

If you want to save yourself a few minutes of annoying formatting clean-up every day, give it a try next time you're copying from ChatGPT.

🔗 Link: 30tools.com/markdown-to-text

Have you guys found any other workflow tools that fix annoying AI quirks like this? Let me know in the comments! 👇

https://www.indexfast.co/

How To run Supabase locally

Sh Raj — Wed, 25 Mar 2026 03:17:35 +0000

To run Supabase locally, you don’t “download Supabase” like a normal app.
You run the Supabase local development stack using Docker + Supabase CLI.

Follow this exact step-by-step setup 👇

✅ Step 1 — Install Prerequisites

You must have:

1. Install Docker

Download from: https://www.docker.com/products/docker-desktop

Then start Docker Desktop.

Check:

docker --version

2. Install Supabase CLI

Using npm (recommended for devs):

npm install -g supabase

Check:

supabase --version

✅ Step 2 — Initialize Supabase Project Locally

Go to your project folder:

mkdir my-supabase-app
cd my-supabase-app

Now initialize:

supabase init

This creates:

supabase/
   config.toml

✅ Step 3 — Start Local Supabase

Now run:

supabase start

This will:

✅ Pull Docker images
✅ Start local Postgres
✅ Start Auth
✅ Start Storage
✅ Start Realtime
✅ Start Studio

First time = takes few minutes.

✅ Step 4 — Open Supabase Studio (Local Dashboard)

After start you will see something like:

Studio URL: http://localhost:54323
API URL: http://localhost:54321
DB URL: postgresql://postgres:postgres@localhost:54322/postgres

Open:

👉 http://localhost:54323

Now you have full Supabase dashboard locally 🎉

✅ Step 5 — Stop Supabase

When done:

supabase stop

⭐ Very Important (Common Errors)

❌ Docker not running

Fix → Start Docker Desktop

❌ Port already used

Fix → change ports in:

supabase/config.toml

❌ CLI not found

Fix → reinstall globally:

npm i -g supabase

🚀 Pro Dev Tip (Next.js Integration)

If you are using Next.js, local .env example:

NEXT_PUBLIC_SUPABASE_URL=http://localhost:54321
NEXT_PUBLIC_SUPABASE_ANON_KEY=your_local_key

You can get keys from:

supabase status

Tools for SEO: The Essential Stack to Rank Higher in 2026

Sh Raj — Tue, 03 Mar 2026 11:53:01 +0000

Search Engine Optimization is no longer just about adding keywords to a page. Modern SEO requires technical health, content quality, performance optimization, and data-driven iteration.

This guide covers the most powerful tools for SEO — grouped by category — so you can build a professional, scalable SEO workflow.

1. Search Analytics & Performance Tracking

Google Search Console

The most important free SEO tool.

What it does:

Shows which keywords you rank for
Tracks impressions, clicks, CTR
Identifies indexing issues
Submits sitemaps

If you're serious about SEO, this is non-negotiable.

Google Analytics

What it does:

Tracks user behavior
Measures bounce rate and session duration
Analyzes traffic sources
Shows conversion funnels

SEO isn’t just traffic — it’s quality traffic.

2. Keyword Research & Competitor Analysis

Ahrefs

One of the most powerful SEO platforms.

Best for:

Keyword research
Backlink analysis
Competitor gap analysis
Content opportunities

Semrush

An all-in-one SEO suite.

Features:

Keyword magic tool
Site audit
Rank tracking
Domain comparison

Excellent for growing authority systematically.

Ubersuggest

A beginner-friendly alternative for keyword ideas and basic audits.

3. Technical SEO & Site Audits

Screaming Frog SEO Spider

A powerful desktop crawler.

Finds:

Broken links
Duplicate content
Missing meta tags
Redirect chains
Crawl errors

Perfect for deep technical audits.

PageSpeed Insights

Analyzes performance and Core Web Vitals.

Speed directly impacts rankings and user experience.

4. Content Optimization Tools

Surfer SEO

Helps optimize articles based on top-ranking competitors.

Improves:

Content structure
Keyword density
Semantic coverage

AnswerThePublic

Generates real user questions around a topic.

Great for:

Blog ideas
FAQ sections
Long-tail keyword discovery

5. Backlink & Authority Tools

Backlinks remain a major ranking factor.

Ahrefs (Backlink Explorer)

Analyze competitor backlinks
Discover link opportunities
Track domain authority growth

BuzzSumo

Finds trending content that earns links and shares.

6. On-Page & Technical Helpers

Schema Markup Generator

Adds structured data to:

Improve rich results
Enhance SERP appearance
Boost CTR

GTmetrix

Analyzes:

Page speed
Loading waterfall
Optimization opportunities

7. Rank Tracking

SE Ranking

Tracks keyword rankings over time.

Vital for measuring progress.

How to Build an Effective SEO Workflow

A practical workflow:

Audit your site
→ Screaming Frog + PageSpeed Insights
Research keywords
→ Ahrefs / Semrush / AnswerThePublic
Create optimized content
→ Surfer SEO
Track performance
→ Search Console + Analytics
Build backlinks
→ Ahrefs + outreach
Measure rankings
→ SE Ranking

Free vs Paid Stack

Free Stack

Google Search Console
Google Analytics
PageSpeed Insights
AnswerThePublic (limited)

Paid Growth Stack

Ahrefs or Semrush
Surfer SEO
Screaming Frog
Rank tracking software

Final Thoughts

SEO is a long-term game. The right tools help you:

Identify opportunities
Fix technical errors
Create competitive content
Track measurable growth

When combined with consistent publishing and strong UX, these tools create a sustainable organic growth engine.

Biome: The Fast All-in-One Toolchain Replacing ESLint & Prettier

Sh Raj — Tue, 03 Mar 2026 11:49:51 +0000

Modern JavaScript projects often rely on multiple tools: a formatter, a linter, import organizers, and a pile of plugins. Configuration grows. CI slows down. Maintenance becomes annoying.

Biome changes that.

It is a high-performance, Rust-based toolchain that combines formatting, linting, and code quality tooling into a single fast binary — designed to simplify modern web development.

Why Biome Exists

Traditionally, JavaScript projects use:

ESLint for linting
Prettier for formatting
Various plugins for import sorting and additional rules

This stack works — but it can become slow and configuration-heavy.

Biome was created as the successor to Rome with a clear mission:

One tool. Extremely fast. Minimal configuration.

Core Features

1️⃣ Built-in Code Formatter

Biome formats:

JavaScript
TypeScript
JSX / TSX
JSON
CSS

It works similarly to Prettier but is significantly faster because it’s written in Rust.

No endless configuration files. No formatting debates.

2️⃣ Integrated Linter

Biome includes a powerful built-in linter.

It:

Detects bugs
Enforces best practices
Suggests improvements
Auto-fixes issues

Unlike ESLint, it does not depend on dozens of plugins. Most common rules are built-in and optimized.

3️⃣ Import Management

Biome automatically:

Removes unused imports
Sorts imports
Keeps files clean

No separate plugin required.

Performance: Why It’s So Fast

Biome is written in Rust, not JavaScript.

That means:

Faster parsing
Faster AST processing
Faster file scanning
Faster CI runs

Large monorepos especially benefit from this speed advantage.

Example Usage

Install:

npm install --save-dev @biomejs/biome

Initialize:

npx @biomejs/biome init

Check project:

npx @biomejs/biome check .

Fix issues automatically:

npx @biomejs/biome check --write .

That’s it. No 15 configuration files.

Biome vs Traditional Tooling

Feature	ESLint + Prettier	Biome
Setup Complexity	High	Very Low
Plugins Required	Many	Minimal
Speed	Moderate	Extremely Fast
Configuration	Large	Small
CI Performance	Slower	Faster

When Should You Use Biome?

Biome is ideal if:

You are starting a new project
You want a cleaner toolchain
You maintain multiple SaaS projects
You run CI frequently
You build with frameworks like Next.js

It works especially well in modern React/Next.js setups.

Who Should Be Careful?

If your project:

Relies on heavy ESLint plugin ecosystems
Uses highly customized lint rules
Has legacy config requirements

Migration might require planning.

The Bigger Vision

Biome is not just a formatter and linter. The long-term goal is to provide:

Unified JavaScript tooling
Faster developer workflows
Simpler configuration management
A modern alternative to fragmented tooling

It reflects a larger industry trend: consolidating tools into optimized Rust-based systems.

Final Thoughts

Biome represents a shift in how JavaScript tooling is built:

From:

Multiple slow, plugin-heavy tools

To:

One fast, unified toolchain

If you are building modern web applications and care about speed, simplicity, and maintainability — Biome is worth exploring.