Skip to content
AI Dev Cases
ScreenshotOne

ScreenshotOne — How an ex-engineer’s “boring” URL-to-image API compounded to ~$200K–$300K ARR in 3 years on build-in-public and SEO alone

A screenshot API run solo by Dmytro Krasun: hand it a URL, get back an image — a deliberately boring developer tool. With no outside funding and almost no ads, he grew it on build-in-public revenue posts and technical SEO. Year one was $141/mo and near-death; three years later it serves 400–650 paying businesses at ~$200K–$300K ARR.

Published: Aug 11, 20263 min readPrimary-source verified · 4
Monthly (est.)
$20k/mo
Time to grow
35 months
Launched
2022
ScreenshotOne — How an ex-engineer’s “boring” URL-to-image API compounded to ~$200K–$300K ARR in 3 years on build-in-public and SEO alone

Key takeaways

  • If you can’t go viral, pick a structurally sturdy boring problem (a screenshot API — everyone builds it once and tires of maintaining it — low churn)
  • Compounding is flattest early: design to survive year one’s $141/mo (runway, expectations), and keep shipping features and docs without quitting
  • Use build-in-public as a discipline device (public revenue = deadline + trust + backlinks in dev circles; deliberately toggle posting on/off)

The pain point, and how they found it

“Turn a URL into a pixel-perfect screenshot” looks trivial and turns into hell in practice: spinning up and babysitting headless browsers, killing lazy-load/ads/cookie banners, fonts and emoji, giant pages, scaling concurrency. Countless developers share one pain — “I built it myself and got tired of maintaining it.” ScreenshotOne turns that boring, everyone-regrets-building-it problem into a single API call. Unglamorous, but demand is structurally stable and churn is low.

Background & product

ScreenshotOne is a developer-facing screenshot API: pass a URL, get back an image (or PDF/HTML). It powers automated OG images, website thumbnails, monitoring/archiving, and sales-doc automation. Its users aren’t consumers but other developers and companies — it’s a “sell the picks and shovels” business.

It was built by Dmytro Krasun. After ~10 years as a server-side developer he went solo and launched on May 29, 2022 (the idea is logged in Jan 2022 as “Project 0002/1001,” the second entry in his self-set goal to build 1001 projects). Far from viral, he runs what he calls a “calm business” — bootstrapped and solo.

It was not smooth from the start. About a year after launch, in November 2022, MRR was just $141, and he wrote that he questioned his life choices. He kept shipping features and docs anyway, climbing $2.5K → $10K MRR. In April 2025 the official blog announced “$200K ARR, 400+ paying customers.” By August 2025 it was ~$21.6K MRR, with ~$300K ARR / 650 customers cited more recently (this upside is secondary).

Technically, the core value is absorbing the pain of running headless browsers at scale — reproducible rendering, killing ads/cookie banners, and so on. Pricing scales with usage: a free tier (100/mo), Basic $17 (2,000), Growth $79 (10,000), and a $259 (50,000) plan above that.

Pricing

Free tier 100/mo → Basic $17 (2,000) / Growth $79 (10,000) / $259 (50,000). Usage-based subscriptions that scale with volume (per the official pricing page, as of 2026).

ScreenshotOne growth channels and tech stack

How it was built

  1. If you can't go viral, pick a structurally solid boring problem — a screenshot API is something many developers build once, tire of maintaining and want to outsource, a need independent of trends and therefore low-churn
  2. Exploit the fact that an API embeds inside the customer's product and is hard to rip out once integrated
  3. Center the value on absorbing the pain of running headless browsers — scale, rendering reproducibility, stripping ad and cookie banners
  4. Compounding looks flat early, so design your living costs and expectations to survive $141/month in year one and keep stacking features and documentation
  5. Design usage-based subscriptions — a free tier at 100 shots a month, Basic at $17 for 2,000, Growth at $79 for 10,000 and $259 for 50,000 — prioritizing easy adoption and usage growth over price
  6. As a solo founder, optimize for sustainability over speed and keep the whole thing within what one person can run, with no VC and no hires

How it got users

  1. Use building in public as a discipline device — publish revenue and progress continuously on X and Threads so publishing itself becomes your deadline
  2. An individual who shows numbers earns trust, generating word of mouth and backlinks in the developer community, where prospective customers are themselves the audience
  3. Design when *not* to post as well — during a period when publishing stalled the work, he announced he would quit Twitter until reaching $5K+ MRR and focused on the product
  4. Harvest developers' search intent completely through SEO — 'take screenshot with Go', 'puppeteer screenshot API', 'website thumbnail API' and every phrase a developer types when they hit the problem
  5. Write implementation guides per language (Go, Python, Node), competitor comparisons and use-case explainers in volume, claiming long-tail high-intent keywords one at a time and funneling demand into the official docs
  6. Assume slow compounding over three years — $141/month in November 2022, then $2.5K, then $10K MRR, reaching $200K ARR across 400+ paying customers by April 2025
Early ad spend
$0 — no ad spend at all, standing on just two legs: building in public and developer-focused technical SEO

The repeatable playbook

  1. 1If you can’t go viral, pick a structurally sturdy boring problem (a screenshot API — everyone builds it once and tires of maintaining it — low churn)
  2. 2Compounding is flattest early: design to survive year one’s $141/mo (runway, expectations), and keep shipping features and docs without quitting
  3. 3Use build-in-public as a discipline device (public revenue = deadline + trust + backlinks in dev circles; deliberately toggle posting on/off)
  4. 4Harvest developers’ search intent with SEO (mass-produce per-language guides, comparisons, use-cases → funnel into official docs; zero ad spend)
  5. 5Usage-based subscriptions (free tier → $17–$259) that favor adoption and expansion over ARPU, so a small paying base still compounds ARR
  6. 6Solo means optimizing for sustainability (a calm business) over speed: no VC, no hires, designed to run by one person

The hard parts

Notes for transparency. (1) About a year after launch (Nov 2022) MRR was just $141 and he admits he questioned his life choices — the “flat year one” was the precondition, not the exception. (2) Revenue varies by date: the official primary is “$200K ARR, 400+ customers” (Apr 2025); ~$21.6K MRR by Aug 2025; ~$300K ARR / 650 customers more recently (this upside is secondary). Because some write-ups cite $30K+ MRR, we conservatively record $20K/mo (mrr). (3) Beyond a Go backend, tech details and customer breakdowns aren’t reliably public, so we leave them out to avoid fabrication.

Deep dive

【Deep dive】Most of the 40+ cases in this database are consumer apps that ignite on TikTok/Instagram. ScreenshotOne is the opposite — a “boring API sold to other developers” that compounded over three years on just two legs: build-in-public and SEO. It’s arguably the most reproducible archetype here for a working engineer. Let’s break down this “win by being boring.”

1) Pick a boring problem that is structurally sturdy, not viral. A screenshot API is neither new nor sexy, and it has competitors. But Dmytro chose a structural need: “every developer builds this once, gets tired of maintaining it, and wants to outsource it.” That matters — demand doesn’t ride a trend, so churn is low and, once embedded, an API is hard to rip out (it’s buried inside the customer’s product). You can’t go viral, but you also can’t flame out. That contrasts with the fragility of many consumer apps here: when virality stops, they stall.

2) Year one is flat compounding — “not giving up” is the real skill. Thirteen months in, November 2022, MRR was just $141, and he admits he questioned his life choices. Fittingly, his podcast episode is literally titled “The Art of Not Giving Up.” Compounding looks flattest at the start — backlinks, domain authority, and build-in-public trust don’t show up in the numbers early. That’s where most indie hackers quit. He didn’t; he kept shipping features and docs. Surviving year one was the precondition for the later curve to $10K → $20K+.

3) Growth leg one: use build-in-public as a discipline device. Dmytro posts revenue and progress continuously on X and Threads. Build-in-public pays off three ways: (1) publishing is a deadline you set for yourself — discipline; (2) a person who shows real numbers earns trust, generating word-of-mouth and backlinks in developer circles; (3) prospective customers (other developers) are literally your audience. Tellingly, he once posted “I quit Twitter till I reach $5K+ MRR” — when broadcasting was stalling the work, he cut off posting to focus on the product. Build-in-public isn’t attention-seeking; it’s an on/off tool he designs deliberately.

4) Growth leg two: harvest developers’ search intent with SEO. The other leg is technical SEO. Developers always search when they hit a problem — “take screenshot with Go,” “puppeteer screenshot API,” “website thumbnail API.” Dmytro wrote a large body of per-language guides (Go/Python/Node…), competitor comparisons, and use-case posts, capturing these long-tail, high-intent keywords one by one, funneling demand from his bylined technical articles into the official docs. This drives CAC toward zero with no ad spend — boring, but it compounds. It’s the same family as stagetimer’s (#82) doc-driven SEO, but where that targets one feature in the events industry, this goes after the exact search terms developers type while writing code.

5) Solo, calm business: optimize for sustainability first. Dmytro took no VC, hired no one, and runs it alone — coding at midnight while raising a newborn (Medium, “Midnight Code”). Because “keep it calm and durable” is an explicit goal rather than hyper-growth, pricing favors easy adoption and headroom over ARPU: a free tier scaling into usage-based subscriptions ($17–$259/mo). A B2B API bills more as each customer uses it more, so even a small base (400–650 companies) supports $200K–$300K ARR. It’s slow compounding over three years — the inverse of an 18-month consumer rocket.

Takeaways for indie builders. The lessons are clean. (a) If you can’t chase virality, pick a structurally sturdy boring problem. (b) Compounding is flattest early, so design for surviving the $141 of year one (runway, expectations) up front. (c) Drive CAC to zero on two legs — build-in-public (discipline + trust + backlinks) and SEO (harvest search intent). (d) If you’re solo, optimize for sustainability over speed. More than the flashy English-language exits, this is a template most engineers can start copying today.

Cross-case “growth playbook” report (coming soon)

We're building a paid report that aggregates every case in this database: which acquisition tactics worked, in which categories, and how well — insights you can't see from a single story. Get notified first when it launches.

Related cases