I Built a Screenshot API from Tbilisi — 50 Users, 9 Paying, Here's Everything I Learned

Let me start with the real numbers, because the internet is tired of vanity metrics.

50 total users. 9 paying customers. 2,900 API requests. 9.8% error rate. ~$9/month MRR from external users (one confirmed paying customer via Paddle). 900+ cold emails sent. 35 Twitter followers.

That's what six months of full-time solo development looks like for SnapAPI, a web capture and content extraction API that I built from Tbilisi, Georgia.

This isn't a story about hockey stick growth or the mythical overnight success. This is what actually building a SaaS alone looks like — the grind, the failures, the small wins, and the brutal lessons that nobody tells you on Twitter.

The Backstory: Why I Moved and Why I Built This

Four years ago, I was a Swift and iOS developer in Saint Petersburg, Russia. I was doing okay — not broke, not rich, just... fine. But fine doesn't scale, and I had a family: my wife (a talented hair colorist), our 10-year-old son, and dreams bigger than what seemed possible in Russia at the time.

In 2024, we moved to Tbilisi, Georgia. Lower cost of living, a thriving tech scene, and a place where we felt at home. But relocating internationally doesn't solve the income problem — it sharpens it. We needed more money, and my freelance rate had a ceiling.

That's when I decided to build a SaaS. Not because I thought I'd be a billionaire. Because building one recurring revenue stream in a timezone-independent business was the only way I could see to genuinely fund the next chapter — eventually getting us to North America.

Why a screenshot API? I'd been scraping websites for projects, and I noticed something: the market was fragmented. ScreenshotOne does screenshots. Firecrawl does scraping. Urlbox does PDFs. Apiflash does basic captures. Nobody was saying: "Here's ONE API that does everything — screenshots, scraping, content extraction, PDF generation, video recording, AI analysis."

I saw the gap. I built for it.

The Stack (Devs Skip to Here)

I needed something fast and reliable on a budget. Here's what I chose:

• 
  Runtime: Node.js + TypeScript (v20, planning upgrade to v22 next quarter)


• 
  Framework: Fastify — yes, really. It's 4x faster than Express, and when you're running on a $20/month VPS, that matters


• 
  Browser Automation: Playwright, not Puppeteer. Puppeteer broke on me; Playwright didn't


• 
  Database: PostgreSQL in Docker, 16MB footprint, 25 tables


• 
  Cache: Redis (Docker), maxmemory-policy set to noeviction because dropping cache mid-request is worse than being full


• 
  Job Queue: BullMQ for async processing — screenshots can take 3–5 seconds, users shouldn't wait


• 
  Process Manager: PM2 (two API instances + one worker, auto-restart on crash)


• 
  Proxy: nginx reverse proxy with rate limiting (50 requests/sec, burst=100)


• 
  Auth: JWT + HTTP-only refresh cookies


• 
  Payments: Paddle (webhooks verified, live environment)


• 
  Server: Single Hetzner VPS, Ubuntu 22.04 x64

The real win: I'm handling 10K+ requests per day with an average response time of 1.2 seconds on hardware that costs me $20/month. That's the entire backend — no serverless bill shock, no AWS nightmare. Just a box and some code that works.

The Numbers, Unfiltered

• 
  ~50 total users (down from ~60 after I cleaned up test accounts)


• 
  9 paying customers: 5 on Pro ($79/mo), 3 on Starter ($19/mo), 1 on Business ($299/mo)


• 
  2,900 total API requests since launch


• 
  Usage breakdown: 74.5% screenshots, 12.1% extraction, 10.2% video, 2.9% scraping


• 
  Error rate: 9.8% historically (this one keeps me up at night)


• 
  Cold outreach: 900+ emails sent, maybe 20 genuine responses, 0 conversions from that channel alone


• 
  Social presence: 35 Twitter followers (I tried daily posting for 3 weeks, got zero traction)


• 
  SDKs published: 8 total (JS, Python, Go, PHP, Swift, Kotlin + 2 more, all open source)


• 
  MCP server: snapapi-mcp on npm (v3.2.0), works with Claude Code, Cursor, VS Code, Windsurf, Zed

The paying customers are good humans. They reply to support emails. They give feedback. One is using SnapAPI to automate invoice generation for their clients. Another uses it for QA automation. They're not huge revenue, but they're real.

What Actually Worked

The MCP server was the surprising winner. I didn't plan it. But I realized: Claude, Cursor, Windsurf — they're AI IDEs now. Developers want Claude to take screenshots of websites. I published snapapi-mcp on npm, and suddenly people were discovering SnapAPI through Claude Code instead of Google.

The all-in-one approach mattered. Customers told me: "We were using three different APIs for our automation. You being one API with one auth key, one billing page, one integration — that's worth something." People hate API fatigue.

The free tier worked (200 requests/month, no credit card). It got people in the door. Some of my paying customers started free and upgraded when they hit the limit.

Direct outreach worked, but only when targeted. Not the 900 cold emails to random companies. The conversations I had with 5–10 people who I'd actually researched, who clearly needed web automation, who got a personalized message — those worked.

What Completely Failed

Cold email at scale. 900+ emails, maybe 20 responses, zero conversions. The "email 1000 people and hope" playbook is dead.

Twitter growth. I tweeted daily for weeks. Nothing. 35 followers = the internet isn't listening.

SEO vanity. I published 77+ landing pages and 76+ blog posts. I'm still waiting for Google to rank them. My competitor ScreenshotOne built $22K MRR primarily through SEO — but they did it two years earlier.

Building features nobody asked for. I spent weeks on video recording because it seemed cool. One customer used it. I should have talked to users instead of guessing.

The Hardest Lessons

Your first paying customer matters infinitely more than your 1000th free user. Free users don't tell you what works. They churn silently.

Error rate is a silent killer. 9.8% means 1 in 10 requests fail. Customers start wondering if the API is reliable.

Browser memory leaks are the #1 infrastructure challenge. Playwright opens browser contexts, and sometimes they leak memory. 150–350MB per request if you're not careful.

Pricing too low is worse than pricing too high. We're 10–50x cheaper than competitors ($0.16 per 1K vs market $3–8 per 1K). This feels good but it's actually terrible. Low prices attract price-sensitive customers and leave money on the table.

What's Actually Next

• 
  Fix the error rate to <2%. That's the immediate blocker.


• 
  Product Hunt launch. When the error rate is fixed, a proper launch will help visibility.


• 
  Enterprise tier ($299–999/month). Zero engineering, just marketing.


• 
  Get into comparison articles. "Best Screenshot APIs" has huge search volume. I'm not there yet.

The Real Talk

If you're building a SaaS, especially from somewhere unexpected, here's what matters:

1. Your first paying customer is worth 100x more than your first 100 free users.


2. Error rate is a proxy for whether your business is trustworthy.


3. 
   You can't cold email your way to growth. Pick a distribution channel and own it.


4. Building the all-in-one solution matters more than you'd think.


5. Solo development is possible, but infrastructure reliability is harder than code.


6. 
   The location doesn't matter. Tbilisi, Saint Petersburg, Silicon Valley — it's all the same from a customer's perspective.

If You Need a Screenshot API

I built SnapAPI to solve a real problem: developers need reliable website capture, extraction, and automation without juggling five different APIs.

200 free requests per month. No credit card. Check it out at snapapi.pics.

And if you're building something yourself, in some unexpected corner of the world, with a product you believe in and customers who need it — keep going. The internet doesn't care where you code from. It only cares whether you solve a real problem.

Aleksei is a solo founder building SnapAPI from Tbilisi, Georgia. Follow on Twitter @slwl_dev or check the code at github.com/Sleywill.