DEV Community: Serhii Kalyna

Building in public, week 11: 143 pages indexed, a TinyPNG alternative in Rust

Serhii Kalyna — Sun, 31 May 2026 11:15:26 +0000

Week 11 of building Convertify a free image converter (Rust + Axum + libvips, Next.js SSG frontend) in public. Solo, no funding, 52-week run.

Here's the honest headline: **indexing jumped from 100 to 143 pages, I shipped image compression in Rust, and my clicks are still stuck.

What I shipped

1. Internal linking between blog and converter (the debt I kept dodging)

I launched a blog in week 10 (3 posts, full schema, the works) and immediately got 18 views/week on one post. Great except that traffic had nowhere to go. The blog talked about HEIC; it never pointed at the page that actually converts HEIC.

So week 11 I built a RelatedArticle component and wired it both ways:

Blog -> converter: inline contextual links in the body + a CTA block at the end.
Converter -> blog: a "Learn more" card driven by a related_blog_slug column on each page.

The component went through a small evolution. First version showed one article. Then I made it multi-article it pulls 2–3 related posts, matches them by topic via slug, caps at 3, and (the part that bit me) guards against the literal string "NULL" sneaking in from a missing DB value. Nothing fancy, but it closes the loop: informational traffic can finally flow to the transactional pages.

2. Image compression a free TinyPNG alternative, in Rust.

This was the fun one. TinyPNG does ~3M visits/month. That demand is enormous and I was leaving it on the table. libvips already gives me everything I need, so the backend was fast to stand up:

JPEG -> mozjpeg. libvips can hand JPEG encoding to mozjpeg, which does trellis quantization and smarter Huffman tables. Same visual quality, meaningfully smaller files than baseline libjpeg.
PNG -> imagequant. This is the same lossy-PNG approach pngquant (and TinyPNG) use: quantize a 24-bit PNG down to an optimized palette. Huge size drops on PNGs with limited color, transparency preserved.

The UX is a quality slider (1-100%) and a before/after size readout, so you actually see the reduction. I shipped three landing pages /compress-jpg, /compress-png, /compress-webp positioned as the free alternative.

The interesting signal: Compress JPG Free pulled 24 views in its first week, landing straight in my top pages. Different user intent than conversion (people converting a format vs people shrinking a file), and it showed up immediately. That alone made the cluster worth it.

3. Blog post #4

"Why HEIC Files Won't Open" published, 8 FAQs, FAQ schema embedded in the BlogPosting. Continuing the content momentum and feeding the new internal-linking machine.

Also did a cannibalization audit across blog + landing pages. Came back clean: intent is cleanly split (blog = informational, landing = transactional), so they're not fighting each other in search.

The numbers

Google Search Console (3 months):

Indexed: 100 -> 143 (+43, second-biggest jump ever)
Not indexed: 65 -> 39
Avg position: 40 -> 39.5

Google Analytics (7 days): 31 active users (+29%), 24 new (+33%), 52 sessions (+11%).

Traffic sources had a surprise: l.threads.com sent 13 sessions in a week Threads quietly became a real referrer. chatgpt.com has been a steady trickle for over a month now too (LLMs citing the blog posts).

Housekeeping wins

Cleared a stack of small debts that were quietly rotting: fixed the 404 source (broken internal links), cleared the redirect errors flagged in GSC, and consolidated my project docs into a single source-of-truth file instead of three drifting documents.

Next week (12)

Two new tools that are low-effort / high-ROI: resize + crop and background removal.
A compression-focused blog post to feed the new cluster.
The real work: on-page pushes on my top-impression pages to finally break something into the top 20.

If you've shipped a programmatic-SEO site and watched impressions climb while clicks flatlined I'd genuinely like to hear how (or whether) you broke out of it. That's the wall I'm at.

Convertify is built with Rust + libvips + Next.js. Following along week by week.

Building Image Compression in Rust with libvips Real Benchmarks, Real Tradeoffs

Serhii Kalyna — Fri, 29 May 2026 13:00:32 +0000

I've been building Convertify a free image converter for 11 weeks now. Last week I added compression support (JPG, PNG, WebP) using Rust + libvips. Here's what I learned, with actual numbers.

The Stack

Backend: Rust + Axum
Image processing: libvips 8.15.1 via the libvips crate
JPEG encoder: libjpeg (bundled with libvips)
PNG quantization: imagequant (same algorithm as pngquant / TinyPNG)
PNG parser: libspng (faster than libpng)

One thing worth knowing upfront: libvips does not include mozjpeg by default. You get standard libjpeg. I'll come back to why this matters.

How the API Works

The compression endpoint is the same /api/upload used for conversion — just pass format_to=jpg (or png, webp) with a quality parameter (1–100):

curl -X POST https://convertifyapp.net/api/upload \
  -F "files=@photo.jpg" \
  -F "format_to=jpg" \
  -F "quality=80"

On the Rust side, quality flows into libvips save options via build_output_path, which appends [Q=N] to the output filename — libvips picks it up automatically:

fn build_output_path(base: &str, format: &str, quality: Option<u32>) -> String {
    match (format, quality) {
        ("jpg" | "jpeg" | "webp", Some(q)) => format!("{}[Q={}]", base, q),
        ("png", Some(q)) => format!("{}[Q={}]", base, q),
        _ => base.to_string(),
    }
}

Clean. No separate code path for compression vs conversion.

The Benchmarks

Test image: 1920×1080 synthetic photo, 1.5 MB original JPG (Q=95 source).

JPG → JPG (re-compression)

Quality	Output size	Saved
Q=90	1,172 KB	22.7%
Q=80	890 KB	41.3%
Q=70	737 KB	51.4%
Q=60	627 KB	58.6%
Q=50	542 KB	64.2%

PNG → PNG (imagequant lossy)

Test image: 1024×768, 678 KB original PNG.

Quality	Output size	Saved
Q=90	486 KB	29.8%
Q=80	441 KB	36.2%
Q=70	396 KB	42.7%
Q=60	377 KB	45.5%
Q=50	348 KB	49.7%

JPG → WebP (format switch as compression)

Quality	Output size	Saved vs original JPG
Q=90	1,120 KB	26.1%
Q=80	872 KB	42.5%
Q=70	760 KB	49.9%

The Surprising Part

WebP at Q=80 saves almost the same as JPG at Q=80 — 42.5% vs 41.3%. Not the dramatic 2× improvement you'd expect from the marketing.

Why? On already-complex photographic content (lots of high-frequency detail), the gap between WebP and JPEG narrows significantly. WebP's advantage is most visible on graphics, flat colors, and images with transparency.

The other surprise: if the source JPG is already compressed at Q=70–75 (common for web photos), re-compressing to the same format gives you almost nothing. You're fighting the JPEG DCT artifacts that are already baked in. This is where converting to WebP actually helps different codec, fresh encode.

Why Not mozjpeg?

mozjpeg typically gives 10–15% better compression than libjpeg at the same quality level. To use it with libvips you need to compile libvips from source with --with-mozjpeg. On Ubuntu:

# Not trivial requires building mozjpeg first
git clone https://github.com/mozilla/mozjpeg.git
cd mozjpeg && cmake -G"Unix Makefiles" && make install

# Then rebuild libvips pointing at mozjpeg
./configure --with-jpeg-includes=/opt/mozjpeg/include \
            --with-jpeg-libraries=/opt/mozjpeg/lib

For a production VPS running PM2 + Caddy with system libvips, the operational complexity wasn't worth it. libjpeg at Q=80 already delivers 40%+ savings which covers 90% of use cases.

PNG: imagequant is the real hero

The selected quantisation package: imagequant line in vips --vips-config is significant. This is the same engine behind pngquant and TinyPNG's PNG compression. It works by reducing the color palette to 256 colors (lossy) while preserving perceptual quality.

The Q parameter maps to imagequant's quality range. Q=80 gives ~36% savings with barely visible quality loss on photographic PNGs. For logos and flat graphics the savings are even better since there are fewer unique colors to begin with.

The Sweet Spot

After running these benchmarks, the defaults I settled on for the UI:

JPG: Q=82 (hits the knee of the quality/size curve, ~40% savings)
PNG: Q=80 (36% savings, imagequant artifacts not visible at normal viewing)
WebP: Q=80 (consistent with JPG behavior)

These are close to what Squoosh and Lighthouse recommend. The difference is users can move the slider themselves the before/after size display makes the tradeoff tangible.

What's Next

The compression cluster is live at convertifyapp.net/compress/jpg. Next up: RAW format support (CR2/NEF) for photographers, and eventually mozjpeg as an opt-in for maximum compression.

If you're building something similar libvips in Rust is genuinely great. The libvips crate is well-maintained, the C library is fast (faster than ImageMagick by a wide margin), and imagequant bundled for PNG is a nice bonus.

Building in public week 11 of 52. Follow along if you're into indie dev + Rust + SEO experiments.

Building Convertify in Public Week 10: PDF Cluster + Blog Launch

Serhii Kalyna — Sun, 24 May 2026 18:17:16 +0000

Week 10 of building Convertify (convertifyapp.net)
in public.

What I shipped

PDF cluster 4 new pages:

/heic-to-pdf (33,100 searches/mo, KD 36)
/pdf-to-png (74,000 searches/mo, KD 42)
/pdf-to-jpg (90,500 searches/mo, KD 86)
/png-to-pdf (3,600 searches/mo, KD 43)

Backend (poppler) was already there from the
images-to-pdf feature — pure content work.

Blog 0 to 3 posts in one week:

"What Are HEIC Files?" KD 20, lowest KD across all 1,192 keywords in my strategy
"How to Convert PDF to JPG 5 Methods"
"AVIF vs WebP vs HEIC 2026"

Full SEO infrastructure from day one: BlogPosting
schema, BreadcrumbList, OG images, canonical,
sitemap updated.

Numbers

Metric	T9	T10
Indexed pages	75	100 (+25) 🔥
Impressions (3mo)	509	520
Avg position	40.1	40

Unexpected: chatgpt.com sent 13 sessions this
month. Blog posts are getting picked up by AI.

First blog post got 18 views in week 1 small
but it's a start.

What I missed

Internal linking blog <-> converter pages (P0 for next week without this, blog traffic doesn't convert)
Showoff Saturday post deleted again

Next week

Internal linking blog <-> converter pages
Blog post #3

Week 1–10 recap: 0 -> 100 indexed pages,
0 -> 520 impressions, 0 -> 3 blog posts.

Convertify

Why I Finally Added a Blog to My Converter Tool

Serhii Kalyna — Wed, 20 May 2026 14:32:11 +0000

Two months in, 75 pages indexed, zero blog posts. That was the plan — ship converter pages, get them indexed, figure out the informational content later.

Then one keyword changed my mind.

The number that changed things

I've been tracking keywords for Convertify across image conversion queries. Most sit between KD 35 and 86 competitive, slow to move, need real backlinks to crack.

While reviewing the list this week I noticed "what are heic files" 3,600 searches per month, KD 20.

For context:

heic to jpg -> KD 67
convert png to pdf -> KD 43
avif vs webp -> KD 35
what are heic files -> KD 20

The SERP is surprisingly weak for a query with this volume. Most results are generic explainers rather than tools solving the problem directly. No converter tool has a proper dedicated page ranking for it.

That felt like the right moment to start.

The logic behind it

The user searching "what are heic files" is usually an iPhone owner who just tried to send a photo somewhere and got confused. They're a couple of clicks away from needing a converter.

The path I'm betting on:

Land on /blog/what-are-heic-files
Understand that HEIC isn't universally supported
Follow an internal link to /heic-to-jpg or /heic-to-pdf
Convert

Informational content converts when the internal linking is tight. A blog post with no clear path to the tool is just a vanity page. The goal here isn't content for content's sake — it's closing the loop between someone learning about a format and actually solving their problem.

What I built this week

The main work was a PDF cluster three new converter pages plus the blog infrastructure.

HEIC -> PDF turned out to be more interesting than expected. PDF has no HEVCDecode filter the spec only defines DCTDecode (JPEG), FlateDecode, and JPXDecode. That means HEIC always requires a transcode to JPEG before embedding. JPG -> PDF by contrast is literally lossless bytes go in untouched. I wrote the full explanation in the page content because this is exactly the kind of depth that thin competitor pages skip.

PDF -> PNG uses pdftocairo for rendering. pdftocairo runs about 3–4x faster than ImageMagick at 300 DPI and produces noticeably better anti-aliasing on text. libvips has a pdfload wrapper that also calls poppler under the hood, so the pipeline stays consistent.

For the blog itself I went with PostgreSQL instead of MDX files. Every new MDX post requires a deploy for a solo developer writing irregularly, that friction compounds quickly. The blog_posts table uses the same JSONB content structure I already use for landing pages, so the renderer was already built. Adding the blog was mostly schema and new routes.

Where things stand

Indexed URLs: 75 -> 82 (target after new pages)
Impressions last 3 months: 509
Blog posts live: 0 -> 2 (target by end of week)

The cross-links I added in week 9 across 64 converter pages should start appearing in GSC by Thursday. Right now I'm prioritizing site structure and internal linking before investing time into backlink outreach. Structural fixes take a few crawl cycles to surface each one is slow feedback, but it compounds.

Why this feels different

The interesting part about SEO at this stage isn't traffic yet it's feedback loops.

You ship a structural change, wait through a few crawl cycles, and slowly learn which assumptions were right. Most changes take weeks to show up. You're essentially running experiments with a 3-week delay on results.

The KD 20 HEIC query is the first time the feedback loop feels short enough to actually compound. If a new domain can rank for KD 20 in a reasonable timeframe, that's a signal worth building on.

Next check is Thursday's GSC analysis.

Convertify is a free image converter built with Rust + libvips and Next.js SSG.
Week 1–10 archive: https://dev.to/serhii_kalyna_730b636889c

Building in public, week 9: cross-links, positions going up, and 246 new dev.to followers in 7 days

Serhii Kalyna — Sun, 17 May 2026 05:55:34 +0000

tl;dr: Week 9 was infrastructure week. Closed the biggest SEO gap internal cross-links on 100% of pages. Average position improved for the first time in a month.

The numbers

Metric	Week 8	Week 9
Indexed URLs	72	75
Impressions (3 months)	463	509
Avg. position	43.8	40.1
Cross-links coverage	40/64	64/64
dev.to followers	156	402

GA last 7 days: 36 active users (+56.5%), 61 sessions (+38.6%). Traffic sources: Google organic is now the consistent #1.

What I actually did

Cross-links: 40 -> 64/64 ✅

This was the main P0 for the week. Convertify has 64 landing pages (62 format-pair conversions + home + images-to-pdf). In week 8, only 40 had contextual cross-links inline <a href> inside the body text pointing to related conversions.

I added 2-3 cross-links per page across the remaining 24 pages, batched over Monday–Wednesday. The links are semantic, not just alphabetical a page about AVIF->JPG links to AVIF->PNG and JPG->AVIF, not to BMP->TIFF.

The effect on positions isn't instant. Internal links take 1-2 crawl cycles to register. But average position went from 43.8 to 40.1 the first improvement in a month. Expecting more in T10–T11 as Googlebot re-crawls.

Semrush on-page fixes

Four pages got H1/title/meta updates based on Semrush priority scores:

avif-to-webp priority 3.35 (highest), added missing semantic terms
avif-to-png priority 0.78, H1 and title now contain "avif to png" exactly
heif-to-jpg priority 0.48, body + H1 + title now include "heif image converter"
avif-to-jpg priority 0.19, title updated to match "online convert avif to jpg"

Also simplified readability on 4 pages (Semrush flagged them as "difficult to read") shorter sentences, fewer compound clauses.

Content gaps closed

4 pages brought from 5 to 6+ sections, 2 pages got FAQ expanded from 6 to 8 questions. Home page schema_faq synced (was 4 questions in JSON-LD, 7 in the DB now 7 everywhere).

Also added a comparison table to /images-to-pdf the only page that was missing one.

Google confirmed 35 canonical fixes

Got an email from Google Search Console team confirming that the canonical issues I fixed in T8 (35 pages were flagged as "Alternate page with proper canonical tag") have been resolved. The "Variant page with canonical tag" count dropped to 0.

SaaSworthy listing

Added Convertify to SaaSworthy full listing (Basic Details + Media + Pricing + FAQs). Free tier was actually free, no "Talk to Us" required.

Created an account, verified the domain via meta tag, published 3 pins:

HEIC->JPG: "Convert HEIC to JPG Free Online No Signup"
AVIF->PNG: "Convert AVIF to PNG Free Preserve Transparency"
PNG->WebP: "Convert PNG to WebP Free 30% Smaller Files"

Not expecting traffic from this. Image search visibility is the goal AVIF and WebP pages might surface in Pinterest search for people looking for format examples.

What I deliberately didn't do

Researched whether adding "Last updated: May 2026" to pages would help CTR. Found two case studies showing it hurt CTR by 13-22% on tool pages. Probably because it signals the tool is old and was manually touched, not that it's actively maintained. Skipped it.

The unexpected thing: dev.to followers +246 in one week

I publish weekly "Building in public" posts on dev.to + a technical article each week. Week 9 posts:

"Building in public, week 8: impressions exploded 71% and I think I know why"
"AVIF encoding speed".

The AVIF article is the one that seems to have triggered the follower spike. It's pure technical content benchmarks comparing AVIF encoding speed at different quality settings across formats. No promotion, no "check out my tool." Just data.

My theory: dev.to surfaces content in the weekly digest or the tag feeds, and technical posts about specific formats get picked up by people in the web performance / image optimization community. The followers are probably devs who bookmarked the article and followed for future posts.

What's not working

Clicks aren't moving. The pages are showing up in Google avif-to-png has 85 impressions, avif-to-jpg has 66, png-to-webp has 59. But average position is still ~40. Need to be in top 20 for these before clicks appear. The on-page and cross-link work is aimed at exactly this.

Plan for week 10

Keyword targeting on top pages: avif-to-png, avif-to-jpg, png-to-webp are the three pages with the most impressions. These need to move from position ~40 to position ~20. That means: content depth, more FAQ, better semantic coverage, maybe longer-form sections.

The honest take

Cross-links: was at 62.5% coverage, now 100%
Content: 0 pages below minimum threshold
Schema: all mismatches resolved

The position improvement (43.8 -> 40.1) is the first concrete signal that the on-page work is landing. 509 impressions.
Real clicks need top-20 positions. That's the only thing that matters in T10.

Convertify is a free image converter built with Rust + libvips and Next.js SSG. convertifyapp.net

Week 1–9 archive: dev.to/serhiizahornyi

AVIF encoding speed — the numbers nobody talks about

Serhii Kalyna — Thu, 14 May 2026 16:16:27 +0000

Everyone talks about how small AVIF files are.

Almost nobody talks about what it costs to generate them in production.

I run a free image converter built on Rust + libvips. After processing thousands of conversions, here are the numbers that changed how I think about format choice.

The compression story you already know

AVIF beats WebP on file size. For photos and gradients:

AVIF saves ~50% vs JPEG (median across 600 photos)
WebP saves ~31% vs JPEG
At the same DSSIM score, AVIF produces files ~50% smaller than WebP

Real and impressive. But that's only half the equation.

The encoding cost nobody talks about

Here's what actually happens when you encode with libaom (the default AVIF encoder):

Format	Encoding time (1080p)	Peak CPU	Peak RAM
WebP	~90ms	~20%	~200MB
AVIF (libaom, default settings)	1–4 seconds	~400% (4 cores)	~2.5GB
AVIF (maximum quality)	up to 48 seconds	-	-

In my tests, AVIF encoding with libaom was up to 47× slower than WebP at comparable quality settings. Peak memory usage during a single 4000px AVIF conversion reached ~2.5GB in Sharp/libvips using libaom. WebP used ~200MB for the same image.

The memory usage surprised me most. For a service handling concurrent batch uploads, that's not a benchmark number - it's a capacity planning problem.

AVIF optimizes bandwidth. WebP optimizes compute.

The `effort` parameter an oversimplification

If you use Sharp, you've probably assumed: higher effort = smaller files.

In practice, it's not that simple.

quality is the primary driver of file size. effort controls how much time the encoder spends searching for better compression decisions. Depending on the image, higher effort can slightly reduce or even increase output size. The effect is unpredictable and usually marginal.

This is documented behavior in Sharp's issue tracker (#3418): at fixed quality, increasing effort sometimes produces larger files.

Practical starting point for AVIF in Sharp:

sharp(input).avif({ quality: 72, effort: 5 }).toBuffer()

effort: 5-6 hits a reasonable balance. Going to effort: 9 adds seconds of encoding for marginal and unpredictable gains.

When to use which format

Scenario	Best format
User uploads processed on-the-fly	WebP
Static assets, pre-generated at build	AVIF
Real-time transforms	WebP
Maximum compression for photos	AVIF
Low-memory servers	WebP
Screenshots, UI, flat graphics	WebP
Photography, gradients, textures	AVIF

The rule I follow: AVIF for static, WebP for dynamic.

A 4-second encoding time is fine in a CI pipeline. It's not fine when a user is waiting for their converted file.

What this looks like in a converter pipeline

In my converter pipeline, the challenge with AVIF isn't throughput it's memory spikes under concurrent load. If multiple users upload large images simultaneously, AVIF jobs can spike memory hard across all cores.

Current approach:

Concurrency limits on AVIF jobs
Default effort: 4 for interactive conversions fast enough for real-time use
SVT-AV1 encoder is worth watching: roughly 2× faster than libaom, 5× faster than rav1e at comparable quality

Browser support

Effectively solved:

WebP: ~95.6% global support (Safari 14+, all modern browsers)
AVIF: ~94.3% global support (Safari 16.4+, Chrome 85+, Firefox 93+)

The standard fallback pattern still makes sense:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

The actual takeaway

"Better compression" and "better for your use case" aren't the same thing.

AVIF is technically superior for compression. But if you're encoding on-the-fly, the encoding overhead is a real operational cost not a benchmark footnote.

WebP is fast, lightweight, and produces files dramatically smaller than JPEG. It's not a consolation prize.

The best setup: pre-generate AVIF for static assets, encode WebP dynamically, serve both via <picture> or CDN content negotiation.

Building Convertify a free image converter powered by Rust + libvips. Week 9 of building in public.

Sources: Sharp GitHub issues #2597, #3418 · libheif AVIF Encoder Benchmark · SpeedVitals WebP vs AVIF · W3Techs image format statistics (May 2026) · Can I Use

Building in public, week 8: impressions exploded 71% and I think I know why

Serhii Kalyna — Sun, 10 May 2026 12:21:24 +0000

So this week something actually happened.

I've been building Convertify - a free image converter (Rust + libvips backend, Next.js frontend) - for about 2 months now. Writing content, fixing schema, submitting to directories, watching Google mostly ignore me.

This week the numbers moved.

The numbers

Google Search Console, 3-month view:

Impressions: 271 -> 463 (+71%)
Indexed pages: 59 -> 72 (+13)
External links: 40 -> 65 (+25)
Average position: 40.8 -> 43.8 (worse, but I'll explain)

That impressions jump is the biggest I've ever had.

What I think caused it

I don't think it was one thing.

Week 7 I updated 19 pages - added content sections, cross-links, fixed a schema bug where 189 FAQ entries were missing from JSON-LD.

Week 8 I did Semrush-driven fixes - put target keywords in H1s and titles, simplified sentences for readability, added semantic terms that competitors use but I wasn't. Also brought 16 pages up to 8+ FAQ each.

My theory is Google re-crawled the batch of updated pages and suddenly saw: "oh wait, these pages actually have real content now, not just a converter widget and two paragraphs."

The position thing

Average position went from 40.8 to 43.8 which looks bad. But 13 new pages got indexed this week, and they all start at positions 50-80. That drags the average down even though the older pages are actually climbing.

One page - jpg-to-webp - is at position 5.8 with 39 impressions. Position 5.8! That's basically page one. Zero clicks though. Working on the title/description to fix CTR.

What I built this week

Shipped batch image-to-PDF. You drop up to 10 images, pick page size (A4/Letter) and orientation, get one combined PDF. Built the PDF from raw bytes in Rust — no PDF library, just manually constructing xref tables and DCTDecode streams. Was it overkill? Probably. Was it fun? Absolutely.

Also refactored the entire Rust backend - split a 1200-line main.rs into proper modules (db, errors, image, notification, path, pdf). Should've done this weeks ago.

Backlinks update

Got on StackShare (DR ~89) and submitted to Capterra (DR ~91, pending review). Capterra was interesting - one submission potentially gets you on Capterra + Software Advice + GetApp, all three owned by Gartner.

Tried a few other directories from my backlink plan. Turns out FeedMyApp is dead (domain expired in 2022), Go2Web20 is dead, VentureBeat Profiles doesn't exist as a free thing anymore, and BetaList wants $39 minimum. So that saved me some future time at least.

Organic search is now #1 traffic source

This is the thing I'm most excited about. search.google.com has been the top traffic source for two weeks straight now. It's small numbers but the trend is clear.

The new /images-to-pdf page immediately became the #2 most viewed page on the site. Google picked it up fast.

What's next (week 9)

Biggest gap right now: 24 out of 64 pages have no cross-links in their body text. Plan is to add 2-3 natural cross-links per page across all 24 this week.

Also rewriting titles and meta descriptions for pages that are ranking but not getting clicks.

If you want to try it: convertifyapp.net. 40+ format pairs, batch conversion, image-to-PDF. Free, no signup.

Previous weeks: week 7 | week 6

From 0 to 72 indexed pages in 2 months: what Google actually does with new sites

Serhii Kalyna — Fri, 08 May 2026 19:57:15 +0000

I've been building Convertify — a free image converter in Rust + Next.js — for about 2 months. Here's where I am in GSC right now:

72 indexed pages
Average position: 40.8
Impressions: ~90/day
Clicks: basically 1

Not glamorous. But I spent time researching what's actually happening under the hood, and it changed how I think about the whole thing.

The "Google Sandbox" thing

Everyone talks about it. New site, no traffic, must be the sandbox right?

John Mueller said it directly in 2019: "There is no sandbox." Google doesn't penalize new sites — it just hasn't collected enough trust signals yet. There's a difference.

What actually happens is closer to this timeline:

Week 1: pages get crawled and indexed
Weeks 2–6: Google tests your pages on low-volume queries
Month 2–3: first stable positions for long-tail keywords
Month 4–6: rankings start to stabilize
Month 6–12: meaningful traffic growth

I'm at month 2. Right on schedule for "still basically nothing."

What actually moved the needle for me

A few things that made a real difference early:

Static site generation. I migrated from a Vite React SPA to Next.js SSG specifically because Google wasn't indexing my pages. Dynamic JS rendering was killing crawlability. After the migration: 186 static pages, all indexable. Impressions jumped within 2 weeks.

Internal linking. Added RelatedConversions component — every page links to 10-14 related conversion pages. Before this, new pages were getting zero impressions. After: slow but steady crawl pickup.

FAQ schema. Every landing page has FAQPage JSON-LD with 8-10 real questions. Not for rich snippets (those don't show for this type) — for entity clarity and content depth signals.

Content depth over breadth. Instead of 5 shallow pages, I focused on making each conversion page actually useful — real technical comparisons, format history, use cases. Some pages now have 10+ sections.

What didn't work (yet)

Backlinks. I spent time on directory submissions, Reddit posts, forum comments. Honest assessment: the directories that matter have 2-4 month queues. The "best image converter" articles are written by competitors. Forum comments get removed.

The only backlink strategy that feels real right now is writing content that people actually want to link to. Which is why I'm writing this.

CTR is also rough — 1 click total at position 40. That's expected. You can't get clicks from page 4. The only fix is ranking higher, which takes time.

What I'm watching now

GSC shows a spike in impressions at end of April — new pages entering the index. Then a drop. Mueller warned about this: "a site may get a spike, then return to normal — that's when you need patience."

I'm in the patience phase.

Month 4-6 is supposedly when things stabilize. I'll report back.

The honest summary

If you launched a site recently and have basically no traffic — you're probably fine. Google isn't punishing you. It's just waiting to see if you're serious.

The things that seem to matter most in the first 3 months: static rendering, internal linking, content depth, and schema markup. Not backlinks. Not social media. Just making the site technically solid and giving Google something worth indexing.

We'll see if that holds at month 6.

Building Convertify in public — free image converter, Rust + libvips backend, Next.js SSG. Week 8 of the build.

Building in public, week 7: 19 pages, 189 missing FAQ entries, and organic search finally showing up

Serhii Kalyna — Sun, 03 May 2026 17:28:38 +0000

TL;DR: I shipped image → PDF conversion but spent most of the week on SEO content instead of the planned batch UI and landing page. The numbers say that was the right call. Organic search became the #1 traffic source for the first time.

Convertify is a free image converter I'm building solo: Rust + Axum + libvips on the backend, Next.js 16.2 SSG on the frontend, PostgreSQL for landing page content. Every week I publish what worked, what didn't, and the real situation behind it.

Here's week 7.

What actually happened vs. the plan

The plan was clear: ship image → PDF with full batch UI (page size options, orientation picker) plus a dedicated /images-to-pdf landing page, and catch up on community engagement.

What actually happened: image → PDF conversion works — you can convert JPG, PNG, WebP to PDF right now. But the batch UI (combining multiple images into one PDF with layout controls) and the dedicated landing page didn't get built. Instead I went deep on content.

What I did instead of the planned batch work: mass content expansion. Created 9 new landing pages, updated 5 existing ones to full content, improved 5 more that were lagging behind, and found a critical bug in my structured data that had been silently hurting SEO for weeks.

The reason was simple. I opened the database, looked at the gaps, and realized that getting 19 pages from thin/empty to complete would compound for months. The batch UI and /images-to-pdf page would polish one feature. Content would give me 19 new entry points into Google. I picked the compounding bet.

The schema_faq bug — 189 missing questions

This was the real find of the week.

I have faq fields on every landing page (the visible FAQ accordion) and schema_faq fields (the JSON-LD FAQPage markup that Google reads for rich results). They're supposed to match. They didn't.

When I checked: 55 out of 62 pages had fewer questions in schema_faq than in faq. That's 189 questions Google couldn't see in structured data — almost a third of my entire FAQ content was invisible to rich results.

The cause was boring: schema_faq was written manually when I first created each page, and never updated when I added more FAQ entries later. Classic data sync bug.

The fix had two parts. First, a SQL migration that synced all 56 pages. Second, a frontend fix in FAQ.tsx — I removed the landing?.schema_faq ?? fallback so the component now always generates schema from faqItems directly. The desync can't happen again.

This is one of those bugs that costs you nothing visibly but bleeds SEO silently. You don't notice it until you audit.

Content expansion: three clusters

TIFF cluster — 5 new pages. JPG→TIFF, PNG→TIFF, PDF→TIFF, HEIF→TIFF, AVIF→TIFF. These target print/archival workflows — people who need lossless containers for prepress, medical imaging, GIS. Low volume keywords but almost zero competition.

GIF cluster — 4 new pages. WebP→GIF, AVIF→GIF, HEIF→GIF, HEIC→GIF. The use case is mostly "I have a modern format and need an animated GIF for legacy platforms." Slack, older email clients, forums that only accept GIF — it's still a thing in 2026.

HEIF pairs — 5 existing pages rewritten. HEIF→JPG, HEIF→PNG, HEIF→WebP, HEIF→AVIF, HEIF→HEIC. These existed but had minimal content. Now each has 7+ sections explaining the difference between HEIF (the container) and HEIC (HEIF + HEVC codec), with comparison tables and full FAQ.

Partial pages filled — 5 more. PNG→HEIC, HEIC→WebP, GIF→JPG, GIF→BMP, GIF→HEIC all got expanded to full content.

Every page also got cross-links embedded in the content body — teal-styled <a> tags pointing to related conversions. The ContentSections.tsx component now supports dangerouslySetInnerHTML for these, plus paragraph splitting on \n\n so content doesn't render as walls of text.

Frontend work: RelatedConversions upgrade

The internal linking component got a proper overhaul. Before, it was semi-random. Now it uses a VALID_SLUGS set (no more 404 links), reverse-route boosting (if you're on A→B, the B→A page ranks high), family overlap scoring, and a HEIC/HEIF sibling bonus. Max 14 links per page, all validated against actual database slugs.

Small thing, but internal linking is one of those levers where the improvement compounds across every page simultaneously.

The numbers

Google Search Console is moving in the right direction. Indexed pages went from 52 to 59. Impressions had the biggest single-week jump since launch. Average position dropped below 41 for the first time — slow grind but it's grinding the right way. GSC also unfroze after the data lag from week 6, so the dashboard is fresh again.

Clicks are still minimal. The math is straightforward: at position ~40, CTR is basically zero. I need to crack top 20 on at least a few queries before clicks become meaningful. That's not a content problem — that's a time-and-authority problem.

Google Analytics showed the signal I've been waiting for: search.google.com became the #1 traffic source this week — beating Reddit, Threads, and everything else. First time organic search has been on top. Active users grew by 40% week over week, and new users by nearly 70%.

Semrush Site Audit came back clean: 98% health score, zero errors. No broken links, no redirect chains, no orphan pages. The remaining warnings are minor — some pages flagged for low text-to-HTML ratio (expected with Next.js SSG where the JS bundle is heavy relative to static content), and two pages with low word count that I'll bulk up in the next round. The site also passed all Core Web Vitals checks, and the crawl depth stays within 3 clicks for nearly everything. For a solo project with 60+ landing pages, I'm pretty happy with that baseline.

What I'm noticing

1. Content × schema = compound effect. Every page I fix works 24/7 for months. That's fundamentally different from a Reddit post that peaks in 48 hours. The schema_faq fix alone means Google now sees 189 more questions across the site. That's not a one-time bump — it's a permanent improvement to how the site appears in search.

2. Organic traffic is real now. It's still small. But seven weeks ago it was literally zero. The trend line matters more than the absolute number. And when you see Google outpace your referral channels for the first time — that's a signal.

3. Community engagement suffered again. Two weeks in a row with minimal Reddit/dev.to activity. Karma flatlined, HN karma still stuck. This is becoming a pattern I need to break in week 8.

Honest moment

I planned to ship a polished feature with batch UI and a landing page. I shipped the core conversion and then pivoted to content instead. It feels less exciting to write about — "I updated 19 database rows" doesn't have the same energy as "I built a multi-image PDF composer."

But looking at the analytics, this was probably the highest-ROI week so far. Every page I created or fixed is now a permanent surface area for organic discovery. The schema bug fix alone was worth the entire week.

Sometimes the boring work is the important work.

Week 8 plan

Primary: finish the image → PDF experience — batch upload (multiple images into one PDF), page size/orientation options, and the /images-to-pdf landing page. The conversion works, now it needs the polish.

Secondary: re-engage community channels. Daily Reddit/dev.to comments, one new article, one Reddit post. Two weeks of silence is too long.

Not doing: new SEO clusters, big redesigns, or chasing new platforms.

Convertify is a free, ad-free image converter. convertifyapp.net — weekly updates every Sunday.

Building in public, week 6: PDF support is live — but I had to sacrifice content for it

Serhii Kalyna — Sun, 26 Apr 2026 17:53:18 +0000

TL;DR: I shipped PDF → image conversion this week. The cost? Three days redesigning the converter UI, and falling behind on community content. Solo dev tradeoffs are real.

Convertify is a free image converter I'm building solo: Rust + Axum + libvips on the backend, Next.js SSG on the frontend, PostgreSQL for landing page content. Every week I publish what worked, what didn't, and the numbers behind it.

Here's week 6.

What shipped: PDF support (Wednesday)

The big one. Convertify now converts PDFs to images — JPG, PNG, WebP, and so on. Multi-page PDFs are bundled into a ZIP with one image per page.

What's not shipped yet: the reverse direction (image → PDF). That's the headline feature for week 7.

How I integrated PDF in libvips

libvips itself doesn't speak PDF natively — you need a backend. I'm using a libvips extension that wraps the heavy lifting (I'll dig into the exact crate / build flag in a follow-up post once I'm sure I'm describing it correctly — there are a few moving parts and I don't want to misinform).

The flow is straightforward:

Upload PDF → temp file
Page count via the PDF backend
Loop through pages, render each to a raster at the requested format/quality
If single page → return the image directly
If multi-page → stream a ZIP containing all rendered pages

The ZIP path was the part I spent the most time on. Stream-zipping in Rust without buffering everything in memory took some plumbing — but it pays off the first time someone uploads a 50-page PDF and the server doesn't OOM.

Landing pages

PDF launched with the full set of landing pages already drafted: /pdf-to-jpg, /pdf-to-png, /pdf-to-webp, etc. They're in the same SSG pipeline as the rest of the site (Postgres → static build → Caddy).

The interesting signal: the PDF to PNG page is already the #2 most-visited page on the site after the homepage, three days after launch. No marketing, no posts about it yet. Just organic discovery.

That's the kind of thing that makes you want to ship faster.

What didn't ship: content + image→PDF

Thursday, Friday, and Saturday I spent redesigning the converter UI itself — the format picker, the upload area, the buttons component system (migrating off MUI to a custom CSS-modules-based system to drop bundle size).

That redesign was overdue. But it cost me three days of community content work I'd planned: replies on Reddit, comments on dev.to articles in my space, follow-ups in subreddits I've been growing in. All pushed to week 7.

This is the solo dev squeeze. You can ship features, or you can grow distribution. Doing both well in the same week is hard. I picked features this week. Next week the math has to flip.

Stack Overflow update

Quick note for anyone following the SO experiment from earlier weeks: I got a moderator warning. Not a ban — but a clear signal about the rules. The takeaway: you can use SO for self-promotion in narrow, well-defined cases (genuinely answering a question where your tool is one of several legitimate solutions, with full disclosure), but the bar is high and the risk/reward isn't great for backlinks specifically.

For now I'm not pursuing SO further as a backlink channel. Reddit, dev.to, Hashnode, and Indie Hackers continue to be the better mix.

Numbers, week 6

Indexed pages in GSC: 52 (up from 40+ last week)
Average position: 40+
Clicks from search: still climbing toward meaningful numbers — early indexing, niche keywords, give it time
Top traffic sources this week: SourceForge, Reddit, Threads (referral traffic is starting to compound from earlier posts)
Top countries: Ukraine, US, China, Germany

The GSC dashboard has been stuck on April 21 for five days, which is annoying — Google's lag is usually 2-3 days, not 5. I'll re-check next week before drawing conclusions.

What I'm noticing

A few things worth writing down so I remember them:

1. Niche landing pages get found. The PDF→PNG page didn't need a single backlink to start pulling traffic. SSG + clean URLs + targeted titles are doing the work. This validates the programmatic SEO bet — keep adding pages.

2. Referral traffic compounds slowly. Reddit comments I made weeks ago are still bringing people in. Threads posts from earlier in the buildinpublic series are now a source. None of this happens fast — but it does add up.

3. Redesigning is never "small". Three days for a converter UI redesign sounds like overkill until you realize that bad UX kills retention faster than missing features. The new format picker handles 15 → 40+ formats gracefully (it'll matter once I add more). The new buttons system dropped a lot of bundle weight.

Honest moment

I'm not going to pretend this week was full of breakthrough energy. I was heads-down and on autopilot for most of it. PDF integration was hard, the redesign ate the rest of the week, and I shipped instead of celebrating.

Sometimes building in public means publishing a week that was just work. No story arc, no aha moment. Just: kept moving, shipped the thing, paid the cost, here's what's next.

Week 7 plan

One goal: ship image → PDF and catch up on content.

That's it. No new initiatives, no shiny experiments. Close the PDF loop in both directions, and re-engage the community channels I dropped this week.

If you're a solo dev reading this — what's your current ratio of build vs grow? I'd love to compare notes.

*Convertify is a free, ad-free image converter built solo. If you've got files to convert, give it a try convertifyapp.net — and if you want to follow the build, I post weekly.

Adding PDF support to a Rust image converter — what I learned about libvips and PDF rendering

Serhii Kalyna — Wed, 22 Apr 2026 15:40:54 +0000

Been building Convertify — a free image converter in Rust + Axum + libvips. This week I added PDF to JPG/PNG support. Thought I'd write up what actually happened because it was more interesting than expected.

The naive approach

My existing image pipeline is straightforward — VipsImage::new_from_file(path), some processing, image_write_to_file(out_path). Images just work. I assumed PDFs would be similar.

First attempt:

let image = VipsImage::new_from_file(&format!("{}[dpi={}]", file_path, dpi))?;

This actually works. libvips accepts PDF paths with a dpi parameter and returns a VipsImage. For a single-page PDF it's almost trivially simple.

Multi-page gets interesting

The problem is multi-page PDFs. You need to render each page separately and either return them as individual files or bundle them into a ZIP. My load_pdf function probes the file first to get the page count:

let probe = VipsImage::new_from_file(&file_path)?;
let quantity_pages = probe.get_n_pages();

Then for each page:

let image = VipsImage::new_from_file(&format!(
    "{}[dpi={},page={}]",
    file_path, dpi, num_page
))?;

The page parameter is zero-indexed. Simple enough. The output goes into individual files which then get zipped:

let mut zip = ZipWriter::new(file);
for page_file in &name_pages {
    zip.start_file(page_file, options)?;
    let data = std::fs::read(format!("./tmp/{page_file}"))?;
    zip.write_all(&data)?;
    std::fs::remove_file(format!("./tmp/{page_file}"))?;
    registry.lock().await.remove(page_file); // cleanup registry too
}
zip.finish()?;

The rendering engine question

libvips doesn't have its own PDF renderer — it delegates to either poppler or pdfium depending on how it was compiled. On most Linux distros you get poppler via the libvips-dev package. On a clean Ubuntu 24 EC2 instance this just worked, but I hit a subtle issue: some PDFs rendered correctly in Acrobat but had slightly different text positioning in my output. Turns out poppler's Splash rasterizer and pdfium's Skia backend produce noticeably different results on complex layouts.

If you're doing this in production and care about rendering quality, check what backend your libvips was compiled against:

vips --version
# also check what PDF loader is available:
vips -l | grep pdf

If pdfiumload is available alongside pdfload, you can use pdfium explicitly. The quality difference on text-heavy PDFs is visible — Skia's analytical coverage rasterizer produces cleaner edges than Splash.

DPI clamping

I added a DPI clamp on the server side — users can request any DPI but I limit it to 72–300:

let dpi = match params.get("dpi") {
    Some(value) => match value.parse::<i32>() {
        Ok(num) => num.clamp(72, 300),
        Err(_) => 150,
    },
    None => 150,
};

The reason: a 600 DPI A4 page produces a ~139 MB raw RGBA buffer. libvips streams this in tiles so it doesn't OOM, but it's still slow and the output file is huge. 300 DPI is the sweet spot for print-quality output — 2480×3508 pixels for A4, ~900 KB as JPG.
The cleanup bug I fixed this week
Completely unrelated to PDF but worth mentioning — noticed in the logs that cleanup_files was reporting it deleted hundreds of files when ./tmp was actually empty.
The bug: I was counting files to delete as to_delete.len() before actually attempting deletion. Page files from multi-page PDFs get removed immediately after zip creation, but their registry entries stuck around. So the cleaner found stale registry entries with no corresponding files on disk and counted them as successfully deleted.
Fix — count only files actually removed from disk, handle NotFound separately:

match tokio::fs::remove_file(&path).await {
    Ok(_) => {
        old_files_deleted += 1;
        reg.remove(&file_name);
    }
    Err(e) if e.kind() == std::io::ErrorKind::NotFound => {
        reg.remove(&file_name); // stale registry entry, skip count
    }
    Err(e) => {
        eprint!("Failed to delete {file_name}: {e}");
    }
}

What's next

PDF frontend is now live — DPI selection (72/150/300) and multi-page ZIP download are both shipped. You can try it at convertifyapp.net/pdf-to-png and convertifyapp.net/pdf-to-jpg.

Still considering whether to expose pdfium explicitly as a build option for better rendering quality, or just document the poppler default behavior. For now poppler works fine for the majority of PDFs people actually upload.

Building in public — week 5

Serhii Kalyna — Sat, 18 Apr 2026 13:37:36 +0000

Another week, mixed bag.

The main blocker is still HN karma. Sitting at 4, need 10+ for Show HN. Been leaving technical comments every day — libvips internals, AVIF encoder tradeoffs, Rust FFI stuff — but it just doesn't move. Not sure if it's timing, thread selection, or just how HN works for new accounts. Either way, Show HN moves to week 6.

What did happen: added Convertify to Wellfound and SourceForge this week. Small wins but both are DR80+ so it adds up over time. Also published a piece on TIFF in 2026 — researched the format properly and honestly it's kind of fascinating how dead it is on the web but still everywhere in print and professional workflows.

Also started PDF conversion. Using libvips pdfload instead of calling poppler directly — whole backend is already libvips so adding a separate dependency felt wrong. The tricky part is the probe load to get page count before processing, still working out the multi-page output strategy.

GSC is moving in the right direction — 52 pages indexed now, was 33 two weeks ago. Impressions are there, clicks still basically zero because everything sits around position 40. Need to crack top 20 on at least a few queries for that to change.

Week 5 vs week 4

Metric	Week 4	Week 5
Indexed pages	33	52
Reddit karma	60	75+
SO rep	21	87
Impressions	updating Sunday	—

DEV Community: Serhii Kalyna

Building in public, week 11: 143 pages indexed, a TinyPNG alternative in Rust

What I shipped

1. Internal linking between blog and converter (the debt I kept dodging)

2. Image compression a free TinyPNG alternative, in Rust.

3. Blog post #4

The numbers

Housekeeping wins

Next week (12)

Building Image Compression in Rust with libvips Real Benchmarks, Real Tradeoffs

The Stack

How the API Works

The Benchmarks

JPG → JPG (re-compression)

PNG → PNG (imagequant lossy)

JPG → WebP (format switch as compression)

The Surprising Part

Why Not mozjpeg?

PNG: imagequant is the real hero

The Sweet Spot

What's Next

Building Convertify in Public Week 10: PDF Cluster + Blog Launch

What I shipped

Numbers

What I missed

Next week

Why I Finally Added a Blog to My Converter Tool

The number that changed things

The logic behind it

What I built this week

Where things stand

Why this feels different

Building in public, week 9: cross-links, positions going up, and 246 new dev.to followers in 7 days

The numbers

What I actually did

Cross-links: 40 -> 64/64 ✅

Semrush on-page fixes

Content gaps closed

Google confirmed 35 canonical fixes

SaaSworthy listing

Pinterest

What I deliberately didn't do

The unexpected thing: dev.to followers +246 in one week

What's not working

Plan for week 10

The honest take

AVIF encoding speed — the numbers nobody talks about

The compression story you already know

The encoding cost nobody talks about

The effort parameter an oversimplification

When to use which format

What this looks like in a converter pipeline

Browser support

The actual takeaway

Building in public, week 8: impressions exploded 71% and I think I know why

The numbers

What I think caused it

The position thing

What I built this week

Backlinks update

Organic search is now #1 traffic source

What's next (week 9)

From 0 to 72 indexed pages in 2 months: what Google actually does with new sites

Building in public, week 7: 19 pages, 189 missing FAQ entries, and organic search finally showing up

What actually happened vs. the plan

The schema_faq bug — 189 missing questions

Content expansion: three clusters

Frontend work: RelatedConversions upgrade

The numbers

What I'm noticing

Honest moment

Week 8 plan

Building in public, week 6: PDF support is live — but I had to sacrifice content for it

What shipped: PDF support (Wednesday)

How I integrated PDF in libvips

Landing pages

What didn't ship: content + image→PDF

Stack Overflow update

Numbers, week 6

What I'm noticing

The `effort` parameter an oversimplification