Forem: Erik

Day 8: Designing the API Contract First

Erik — Thu, 08 Jan 2026 13:11:44 +0000

Day 8 of 30. Our week 2 begins. Today we define the interface before building the implementation.

One of the most challenging things to change when developing an application like ours, is our API contract. Any change to the API might have a chance of affecting one or more clients, so once developers integrate with your API, changing the API is painful, so our API requires a bit of thinking.

So, let's design something we won't regret (too much...).

API design principles we're following

There are different technologies and different approaches for designing remote APIs. One of the most common approaches would be a REST API over HTTP, but even when using REST, there are different maturity levels of defining APIs.

While we value a REST API, in our case, our focus in more making an API which makes integration easier, and when it makes sense, we'll use a REST approach, but when it doesn't make sense, we're taking a conscious approach to delivering an API which still makes a lot of sense.

We use the following criteria for our API:

1. Be predictable. Follow REST conventions as much as we can. We use standard HTTP methods and status codes, and we don't want to surprise developers.

2. Be consistent. If one endpoint returns created_at, all endpoints have to return created_at with the same naming, same formats, everywhere.

3. Be explicit. We shouldn't introduce magic. If a parameter affects behavior, we will require it explicitly rather than inferring from a context.

4. Be versioned. While maintaining multiple versions of our API is not our goal, we will start with /api/v1/.

While we hope to never need v2, and we don't really want to cater for all "what if" scenarios, the API is quite important, and having the option to add a v2 in the future could prove useful.

5. Return useful errors. One of the most frustrating things is getting errors without a clear explanation on how to resolve the error. We had our fair share in that, so we don't just want to say "Bad Request.". Instead, we'll say what's wrong and how to fix it,
with a link to our documentation portal where needed.

The actual API

We'll spare you the full spec, but here's the gist:

POST /api/v1/screenshots - submit a URL, get back a job ID
GET /api/v1/screenshots/{id} - check if it's done, get the image URL
GET /api/v1/screenshots - list your recent screenshots
GET /api/v1/usage - see how many screenshots you've used this month

Four endpoints. That's it. We can always add more, but we can never take them away.

Implementation notes

A few decisions that affect how we'll build this:

IDs are prefixed. scr_ for screenshots makes debugging easier. You immediately know what kind of ID you're looking at.

Timestamps are ISO 8601 UTC. Always to prevent ambiguity.

Pagination uses offset, not cursors. Pagination like this is simpler to implement, and while cursor-based pagination might be better at scale, but this scale is beyond our usecase.

Image URLs are signed and temporary. Image URLs expire after 24 hours. This lets us clean up storage and prevents hotlinking.

What we built today

Wrote the full API specification (this document, basically)
Created request/response DTOs in Kotlin
Set up validation annotations
Stubbed out the controller endpoints (returning mock data)
Tested with curl to verify the contract

No actual screenshot integration yet - that comes tomorrow. But the interface is locked.

When we wire up the real implementation, we will be less tempted to "just quickly change" the API shape.

Tomorrow: building the screenshot queue

Tomorrow, day 9, we will build the real thing. Job queue in Postgres, worker processing, status updates. The contract we defined today becomes real.

Book of the day

REST API Design Rulebook by Mark Massé

Short, practical, opinionated. This book gives you concrete rules for designing REST APIs that don't suck.

Some highlights: use nouns not verbs in URLs, use HTTP methods correctly, be consistent with naming conventions, design for extensibility without breaking changes.

We don't agree with everything (the book is a bit dogmatic about HATEOAS), but as a quick reference for "what's the right way to do X in a REST API," it's invaluable.

If you're designing an API and want to avoid common mistakes, read this first. It's only 100 pages.

Current stats:

Hours spent: 17 (14 + 3 today)
Lines of code: ~650
Monthly hosting cost: $5.50
Revenue: $0
Paying customers: 0
API endpoints defined: 4
API endpoints implemented: 0 (stubs only)

Day 7: Build in Public Week 1: What Worked, What Didn't

Erik — Thu, 08 Jan 2026 13:09:11 +0000

Day 7 of 30. End of week one. Time to be honest about where we are.

We've been heads-down for a week. "Shipping" every day, or at least thinking every day, and writing about our learning.
But are we actually on track? Let's review.

What we set out to do

The goal: build a screenshot API SaaS and get our first paying customer in 30 days. Specifically, by day 15 we wanted to have something people would fine useful.

That's 8 days from now.

What we actually accomplished

Day	Goal	Status
1	Define the project, set constraints	✓ Done
2	Choose tech stack, set up repo	✓ Done
3	Design architecture	✓ Done
4	Set up CI/CD pipeline	✓ Done
5	Configure hosting & storage	✓ Done
6	Get Playwright capturing screenshots	✓ Done
7	Week 1 retro	✓ (this post)

On paper, we're on track, and every planned task got done, more or less. We're sure we can make improvements on each step, but for now, we have a solid basis.

What's actually working

The screenshot engine works. We can hit an endpoint, pass a URL, and get back a PNG. It takes 2-3 seconds for most sites. That's the core product, and it functions.

CI/CD is smooth. Push to main, wait a few minutes, it's deployed. There are no manual steps, and the setup is simple. This has already saved us time and mental overhead.

Costs are controlled. We're under $10 per month, not counting our own hours. We can run this project for months without the stress of running out of money.

Daily writing is sustainable. We were worried the dev log might feel like a chore, but doesn't. Writing clarifies thinking, and knowing we'll publish keeps us accountable. Also, we love the amount of feedback we get! The things where we're wrong (sorry!), where we can improve, where we're on the right track, or where we're missing something. We love all the feedback we get, keep it coming!

What's not working (yet)

We don't have an API yet. We have a screenshot function. But there's no authentication, no rate limiting, no job queue, no user accounts. Someone can't actually use this as a service yet.

No landing page. Besides our blog, we have currently zero web presence. If someone wanted to sign up today, they couldn't. (though, if you want, you can sign up for early access and we'll give you an API key to try out our service!)

Scope is not well-defined yet. We have a lot of potential features in our backlog which we're keen on delivering, but we have to make sure we're keeping track of our mission, and not getting sidetracked by features that are not important to our goal.

Honest assessment: are we on track?

For a paying customer by day 15, we want:

[ ] User registration and login
[ ] API key generation
[ ] The actual REST API with auth
[ ] Usage tracking
[ ] A landing page explaining what this is
[ ] Stripe integration for payments
[ ] Documentation

That's a lot for 8 days, but not impossible, and if we keep our focus on our deliverables, there's a chance we can deliver all of them, albeit in a limited version, perhaps.

What we're changing for week 2

Tighter scope. Our V1 deliverable is: sign up, get the API key, capture screenshots in a sync way, see your usage, and allow payments. Out of scope at this moment are items like PDF export, scheduled captures, and a lot more.

Landing page this week. Even if it's perhaps not entirely to our liking, we're keen on having a URL we can share.

Talk to more people. Post in communities, reach out to developers we know, ask what functionality they would find useful.

The numbers

Let's be transparent about time and money:

Time spent: 14 hours across 7 days. Average of 2 hours/day. That's less than we expected - life gets in the way.

Money spent: $4.50 (one month of Hetzner VPS).

Lines of code: ~450. Most of it is the Playwright integration and Docker config.

Revenue: $0

Customers: 0

People who know this exists: Maybe 10 (friends we've mentioned it to)

What would success look like?

By day 15 (end of week 2):

Landing page live
API functional with auth
Stripe integration working
Posted in 3+ communities
At least 5 beta signups
Ideally: 1 paying customer (even at $5)

By day 30:

Stable product
Clear documentation
10+ users (free or paid)
At least $50 in revenue
A decision: continue or sunset

Lessons from week 1

Infrastructure first was right. Having CI/CD and hosting sorted means we can now move fast on features without deployment friction.

Writing takes time but pays off. These posts take 30-45 minutes each. That's time not coding. But they force clarity and create a record we'll value later.

The boring stuff matters. We spent zero time on "exciting" features like AI enhancement or visual diffs. We spent all our time on Docker, databases, and deployment. That's correct prioritization.

Solo building is hard. No one to bounce ideas off, no one to catch mistakes, no one to share the load. We're managing, but it's harder than working with a team.

Tomorrow: the actual API

Week 2 starts now. Day 8 we're building the REST API contract - the endpoints, request/response formats, error handling. The interface that developers will actually use.

Let's go!

Book of the day

*
The Lean Startup
by Eric Ries*

The classic. We've read it before, but week 1's retrospective reminded us of its core message: build, measure, learn, ideally as
fast as possible.

We've been building, but we haven't been measuring enough. We haven't introduced analytics yet, we have no landing page to gauge interest and we have room to improve in our marketing of our product.

Ries would tell us to get something in front of potential customers immediately, even if it's embarrassing. A landing page with an email signup. A tweet asking if anyone needs this. Anything to start the feedback loop.

Week 2 is about closing that loop.

Current stats:

Hours spent: 14 total
Lines of code: ~450
Monthly hosting cost: $5.50
Revenue: $0
Paying customers: 0
Days until target first customer: 8
Confidence level: 60%

I Built a CLI to Capture Website Screenshots From The Terminal

Erik — Tue, 06 Jan 2026 14:45:07 +0000

The Problem That Kept Bugging Me

As developers, we spend a lot of time in the terminal. Git, Docker, SSH, package managers - it's where we're most productive. But the moment I needed to see or screenshot a website, I'd have to break that flow entirely.

The routine was often the same:

Need to check a site
Open browser
Navigate to URL
Open DevTools to resize viewport (if testing responsiveness)
Find a screenshot tool or use the browser's built-in one
Save the file
Drag it into Slack/docs/issue tracker

For something I did multiple times a day, such as checking deploys, documenting bugs, archiving pages for clients, this friction was frustrating. I wanted curl for screenshots.

So I Built It

allscreenshots is a CLI tool that captures website screenshots and displays them directly in your terminal! If your terminal supports Sixel, iTerm2, or Kitty image protocols, you'll see the screenshot inline. No context switch required!

Also, if it doesn't support those image protocols, there's a blocky fallback option, which is better than you may think.

allscreenshots https://your-site.com

That's it. The screenshot is rendered right where you're working.

Why Rust?

When deciding what language to pick, I had a few options. Go and Rust were my initial choices.

I chose Rust for a few reasons:

Fast startup time - CLI tools should feel instant. No waiting for a runtime to spin up.
Single binary distribution - brew install and you're done. There are no dependencies to manage.
Cross-platform - Works on macOS, Linux, and Windows without separate codebases*. (*in theory, only macOS is tested at this stage!)
Reliability - Memory safety without a garbage collector means fewer surprises in production.

The actual rendering happens via a cloud API, so you don't need a local browser installation or deal with headless Chrome configuration. The Rust CLI handles authentication, image processing, and terminal rendering.

Features Built for Developer Workflows

The CLI comes packaged with a large amount of features

Device Emulation

Are you testing responsive designs? Then you can emulate specific devices without opening DevTools:

allscreenshots https://mysite.com --device "iPhone 14"
allscreenshots https://mysite.com --device "iPad Pro"
allscreenshots https://mysite.com --width 1920 --height 1080

Full-Page Captures

Capture the entire scrollable page, not just the viewport:

allscreenshots https://mysite.com --full-page -o full.png

Batch Processing

Have a list of URLs to capture? Feed them from a file:

allscreenshots batch urls.txt -o ./screenshots/

Perfect for visual regression testing, documentation, or archiving.

Watch Mode

Continuously capture screenshots during development:

allscreenshots https://localhost:3000 --watch --interval 5

Clean Screenshots

Cookie banners and ads can ruin screenshots. You can Bblock them automatically:

allscreenshots https://example.com --block-ads --block-cookies

Multiple Output Formats

Export to whatever you need:

allscreenshots https://example.com -o page.png   # PNG
allscreenshots https://example.com -o page.jpg   # JPEG
allscreenshots https://example.com -o page.webp  # WebP
allscreenshots https://example.com -o page.pdf   # PDF

(More formats are on the way!)

Real-World Use Cases

CI/CD Visual Testing
Capture screenshots after each deploy and compare them automatically. Catch visual regressions before users do.

Documentation
Generating docs that include UI screenshots? Script it instead of manually capturing and cropping.

Bug Reports
Quickly attach a screenshot to an issue without leaving your terminal workflow.

Archiving
Need to preserve how a page looked at a specific point in time? Batch capture and store.

Client Reporting
Capture multiple pages across device sizes for client deliverables.

Getting Started

Installation

# macOS
brew tap allscreenshots/allscreenshots && brew install allscreenshots

# Or download binaries from GitHub releases

Quick Start

# Capture and display inline
allscreenshots https://github.com

# Save to file
allscreenshots https://github.com -o github.png

# Full page, iPhone viewport, no cookie banners
allscreenshots https://example.com --full-page --device "iPhone 14" --block-cookies -o mobile.png

What's Next?

I'm actively developing this and would love feedback from the community:

What features would make this more useful for your workflow?
Any edge cases or sites that don't render correctly?
Integration ideas (GitHub Actions, VS Code, etc.)?

Drop a comment below or open an issue on GitHub. Thanks for reading!

Debugging Chromium Crashes When Taking Full-Page Screenshots with Playwright

Erik — Tue, 06 Jan 2026 13:49:35 +0000

We recently ran into a frustrating issue with our screenshot API: Chromium was crashing with a segmentation fault when capturing full-page screenshots of large websites. Here's how we diagnosed and fixed it.

The Problem

Our API uses Playwright with headless Chromium to capture screenshots. For most sites, everything worked fine. But for very tall pages, we'd get this crash:

[pid=422][err] Received signal 11 SEGV_MAPERR 000000000000

Followed by a stack trace and ultimately a RENDER_FAILED error returned to the user. The SEGV_MAPERR with address 000000000000 is a null pointer dereference—Chromium was running out of memory during the screenshot compositing process.

Our Setup

We're running a Spring Boot + Kotlin application with Playwright inside Docker on a Linux VPS. The container was already configured with generous shared memory:

$ docker exec allscreenshots-api df -h /dev/shm
Filesystem      Size  Used Avail Use% Mounted on
shm             2.0G     0  2.0G   0% /dev/shm

So that wasn't the issue. We also checked if the container had a memory limit:

$ docker exec allscreenshots-api cat /sys/fs/cgroup/memory.max
max

No container limit either—it could use all available host memory.

Finding the Root Cause

The real problem became obvious when we checked the host's actual memory:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       1.3Gi       178Mi        26Mi       628Mi       629Mi
Swap:             0B          0B          0B

Only ~630MB available and no swap space. Our 2GB VPS was running Postgres, Caddy, and our application, leaving very little headroom.

To understand why this matters, consider what happens when Chromium takes a full-page screenshot. For a page that's 1920×50,000 pixels at 32-bit color:

1920 × 50,000 × 4 bytes = ~384MB for the raw bitmap alone

Add Chromium's compositing overhead, and you can easily spike to 1GB+ for a single large screenshot. With only 630MB available and no swap, the kernel's OOM killer terminates the process.

The Fix

We added 2GB of swap space:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make it permanent across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

After enabling swap:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       1.3Gi       183Mi        26Mi       631Mi       638Mi
Swap:          2.0Gi          0B       2.0Gi

The large screenshot that was crashing now completes successfully.

Other Things We Considered

Before identifying the root cause, we investigated several other potential fixes:

Increasing Docker's shared memory — Docker defaults to only 64MB for /dev/shm, which is often too small for Chromium. You can increase it in your docker-compose.yml:

services:
  your-app:
    shm_size: '1gb'

This wasn't our issue since we already had 2GB, but it's a common culprit.

Chrome flags for memory reduction — Playwright already adds many memory-saving flags, but you can add more:

chromium.launch(BrowserType.LaunchOptions().apply {
    setArgs(listOf(
        "--disable-dev-shm-usage",
        "--disable-gpu",
        "--disable-software-rasterizer",
        "--single-process",
        "--memory-pressure-off"
    ))
})

Reducing screenshot quality — Using JPEG instead of PNG with reduced quality uses less memory during encoding:

page.screenshot(Page.ScreenshotOptions().apply {
    setType(ScreenshotType.JPEG)
    setQuality(80)
})

Capping maximum height — If you can live with a height limit, this prevents the problem entirely:

val maxHeight = 16384
val actualHeight = (page.evaluate("document.documentElement.scrollHeight") as Number).toInt()

if (actualHeight > maxHeight) {
    logger.warn("Page height $actualHeight exceeds max, capping to $maxHeight")
    // Return error or take partial screenshot
}

For a screenshot API where full-page capture is a core feature, this wasn't an option for us.

Lessons Learned

Always configure swap on VPS instances running Chromium — Even if you think you have enough RAM, screenshot operations can spike memory usage unpredictably. Swap provides a safety net.
Check actual available memory, not just limits — Container memory limits and shared memory size don't matter if the host itself is constrained.
2GB is tight for a Playwright-based service — If you're running a screenshot API alongside a database and web server, 4GB gives you much more breathing room.
The SEGV_MAPERR 000000000000 error is usually OOM — When you see Chromium crash with a null pointer dereference during screenshot operations, think memory first.

Monitoring Going Forward

We're now keeping an eye on swap usage to know when it's time to upgrade:

free -h | grep Swap

If swap is constantly in use, that's a signal the VPS needs more RAM.

Have you run into similar issues with Playwright or Puppeteer? We'd love to hear about your experience in the comments.

Day 6: The Core Engine - Getting Playwright Running

Erik — Tue, 06 Jan 2026 13:46:35 +0000

Day 6 of 30. Today we capture our first screenshot. Finally, actual product work.

We've spent the last five days on setup, planning, and infrastructure. While this is absolutely important work, it might feel a bit like time we could
have spent this time better building the product, which, in our opinion, is a trap, since it helps to knows what you're building.

But, at the same time, all of this planning doesn't deliver our product... So, let's get at it, and today we are writing the code that actually does the thing we're building: take a URL, render it in a browser and capture a screenshot! It won't be the full product, but it's a start.

Sounds simple right? Perhaps, but when something sounds too simple, it often a case that we don't understand the problem we're solving well enough yet.
Let's dive in to increase our understanding of the problem we're solving!

Why Playwright over Puppeteer?

There are several screenshotting solutions, such as Playwright, Puppeteer, Selenium + Webdriver, Chrome Devtools Protocol (CDP), and tools like PhantomJS, SlimerJS, and CasperJS. Let's dive in.

All of the aforementioned tools are headless browser automation tools. Some of them, like PhantomJS, SlimerJS, and CasperJS, are unfortunately no longer maintained, which makes the choice more limited, but perhaps a little easier.

Based on the capabilities of the tools, we picked Playwright. We looked at the following criteria to make a well-informed decision:

Better auto-waiting. Playwright automatically waits for elements to be ready before interacting. Puppeteer requires more manual wait logic. For screenshots, we especially need the "wait until the page looks done", and Playwright handles this well.

Multi-browser from the start. Playwright supports Chromium, Firefox, and WebKit out of the box while Puppeteer is Chrome-focused. While we're starting with Chromium only, having the option to support more browsers in the future is a nice feature.

Cleaner device emulation. Playwright has built-in device profiles for phones and tablets. playwright.devices['iPhone 13'] gives us the right viewport, user agent, and pixel density. This results in a lower amount of required config and less room for mistakes.

Active development. Microsoft backs Playwright, and it's evolving faster than Puppeteer. It's not that Puppeteer is abandoned, but Playwright feels like the future.

Setting up Playwright in Kotlin

Here's where things get interesting. Playwright has official bindings for JavaScript, Python, Java, and C#. We're using Kotlin on the JVM, so the Java bindings work well.

First, we need to add the dependency:

// build.gradle.kts
dependencies {
    implementation("com.microsoft.playwright:playwright:1.50.0")
}

Then install the browsers (this runs once during Docker build):

./gradlew playwright --install

Our first screenshot service

Here's the core class that captures screenshots:

@Service
class ScreenshotService {

    private val playwright = Playwright.create()
    private val browser = playwright.chromium().launch(
        LaunchOptions().setHeadless(true)
    )

    fun capture(request: ScreenshotRequest): ByteArray {
        val contextOptions = Browser.NewContextOptions()

        // Apply device emulation if requested
        when (request.device) {
            "mobile" -> {
                val device = playwright.devices()["iPhone 13"]
                contextOptions
                    .setViewportSize(device.viewport.width, device.viewport.height)
                    .setUserAgent(device.userAgent)
                    .setDeviceScaleFactor(device.deviceScaleFactor)
            }
            "tablet" -> {
                val device = playwright.devices()["iPad Pro 11"]
                contextOptions
                    .setViewportSize(device.viewport.width, device.viewport.height)
                    .setUserAgent(device.userAgent)
                    .setDeviceScaleFactor(device.deviceScaleFactor)
            }
            else -> {
                contextOptions.setViewportSize(1920, 1080)
            }
        }

        val context = browser.newContext(contextOptions)
        val page = context.newPage()

        try {
            page.navigate(request.url, Page.NavigateOptions()
                .setTimeout(30000.0)
                .setWaitUntil(WaitUntilState.NETWORKIDLE)
            )

            return page.screenshot(Page.ScreenshotOptions()
                .setFullPage(request.fullPage)
                .setType(ScreenshotType.PNG)
            )
        } finally {
            context.close()
        }
    }
}

This is the naive version. It works, but we'll need to improve it. More on that below.

The first screenshot

After getting everything wired up, we hit our local endpoint:

curl -X POST http://localhost:8080/api/v1/screenshots \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com"}'

Fourteen seconds later: a screenshot. It worked!

But 14 seconds is way too slow. Time to figure out why. (Didn't we say it sounds simple?)

What's making it slow?

We added some timing logs:

Browser context creation: 245ms
Page creation: 12ms
Navigation: 11,847ms
Screenshot capture: 1,203ms
Context cleanup: 89ms

It's pretty clear: navigation is the killer. WaitUntilState.NETWORKIDLE waits until there are no network requests for 500ms. On a site with analytics, chat widgets, and lazy-loaded images, that takes a very long time indeed.

Making it faster

1. Smarter wait strategies

Instead of waiting for network idle, we can wait for specific conditions:

// Wait for DOM to be ready, not all resources
page.navigate(request.url, Page.NavigateOptions()
    .setTimeout(30000.0)
    .setWaitUntil(WaitUntilState.DOMCONTENTLOADED)
)

// Then wait a bit for JavaScript rendering
page.waitForTimeout(1000.0)

A simple change like this brought us from 14 seconds to 3-4 seconds on the same URL. That's about 3x faster!

2. Block unnecessary resources

To speed things even more, let's see if we can block some resources. We don't need analytics, ads, or tracking pixels for a proper rendering of screenshots, so eliminating those calls could speed things up:

page.route("**/*") { route ->
    val resourceType = route.request().resourceType()
    if (resourceType in listOf("image", "stylesheet", "font", "media")) {
        // Allow these - they affect appearance
        route.resume()
    } else if (route.request().url().contains("analytics") ||
               route.request().url().contains("tracking") ||
               route.request().url().contains("ads")) {
        route.abort()
    } else {
        route.resume()
    }
}

Wait - we can't block images and stylesheets if we want accurate screenshots. Let's refine:

page.route("**/*") { route ->
    val url = route.request().url()
    val blockedPatterns = listOf(
        "google-analytics.com",
        "googletagmanager.com",
        "facebook.net",
        "hotjar.com",
        "intercom.io",
        "segment.com"
    )

    if (blockedPatterns.any { url.contains(it) }) {
        route.abort()
    } else {
        route.resume()
    }
}

This shaved off another 500ms on average. We need to extend the list of blocked patterns, make it configurable, have multi-language versions of it, and much more, but for a proof of concept, this will do for now.

3. Browser reuse

There are more areas where we can optimise things. For example, creating a new browser for each request is wasteful.
We're now reusing the browser instance and only creating new contexts:

@Service
class ScreenshotService {
    private val playwright = Playwright.create()
    private val browser = playwright.chromium().launch(
        LaunchOptions()
            .setHeadless(true)
            .setArgs(listOf(
                "--disable-gpu",
                "--disable-dev-shm-usage",
                "--no-sandbox"
            ))
    )

    // Browser stays warm, contexts are per-request
    fun capture(request: ScreenshotRequest): ByteArray {
        val context = browser.newContext(/* options */)
        try {
            // ... capture logic
        } finally {
            context.close()  // Clean up context, keep browser
        }
    }
}

The browser startup is ~500ms. Context creation is ~50ms. This is a big difference when handling multiple requests.

Results after optimization

With the same URL, the same machine, we got the following results:

Before: 14 seconds
After: 2.1 seconds

That's a 6x improvement. The end result isn't blazing fast yet, but it's acceptable, and we'll work on improving this even further.
The loading of complex sites still take 3-5 seconds, but simple sites are under 2 seconds. This is no issue at all for async calls, and could be acceptable in some situations for sync calls.

Edge cases we discovered

Sites that block headless browsers. Some sites detect and block automated browsers. They see no mouse movements, no scroll events, and they see headless Chrome signatures. We'll need to handle these situations gracefully.

Infinite scroll pages. A "Full page" screenshot on an infinite scroll page is quite undefined behavior, which means we'll need to cap the maximum page height.

Cookie consent popups. A lot of sites show a GDPR popup which makes them end up in our screenshots, so this is yet another situation we need to handle.

Sites that require login. Our API won't help here (yet).

Really slow sites. Some sites take 30+ seconds to load. Our timeout handles this, but we need good error messages.

Didn't we mention that we thought making a screenshot would be easy? We haven't even covered mobile devices, dark mode, animations, pagination, or any of the other edge cases we've discovered. Stay tuned for how we tackle these!

What we accomplished today

Got Playwright working in Kotlin/Spring Boot
Captured our first programmatic screenshot
Reduced capture time from 14s to ~2s
Identified major edge cases to handle
Learned a lot about how the web actually behaves

This is the core of our product. Everything else is wrapping paper around this engine.

Tomorrow: week 1 retrospective

Day 7 marks the end of week one. We'll step back and assess: what did we get done, what didn't work, and are we on track for a paying customer by day 15?

Book of the day

Web Scraping with Python by Ryan Mitchell

Okay, we're not using Python, and this book is about scraping, not screenshots. But sometimes it's good to look beyond your own stack, and the principles between the two overlap significantly.

Mitchell covers how websites work under the hood, how to handle JavaScript-rendered content, dealing with anti-bot measures, and the ethics of automated web access. Chapter 10 on JavaScript execution is particularly relevant - it explains why "waiting for the page to load" is so complicated in the modern web.

Even if you're not doing web scraping, understanding how browsers render pages helps you build better web tools. This book is a practical, readable introduction to that world, and a must read in our book (ha!) if you want to dive in into the world of web automation.

Current stats:

Hours spent: 14 (previous 10 + 4 today)
Lines of code: ~450
Monthly hosting cost: $5.50
Revenue: $0
Paying customers: 0
First screenshot captured: ✓
Capture time: ~2-3 seconds
Edge cases identified: 5

Day 5: Choosing Our Hosting - How We'll Run This for Under $20/month

Erik — Mon, 05 Jan 2026 07:55:00 +0000

Day 5 of 30. Today we're talking money - specifically, how to spend as little of it as possible.

Hosting costs can have a significant impact on a bootstrapped project. We've seen projects spend $1000+/month on
infrastructure for apps with zero users, especially when running on bigger cloud providers like AWS or Azure. We're
optimizing for cheap until our needs justifies otherwise.

Our target for allscreenshots is to spend less than $20 USD/month for our hosting costs and CI/CD infrastructure. In this post we're diving into how we intend to get there.

The options we considered

Vercel / Netlify / Railway

Options like these are the current developer choice, especially for NextJS platforms. The platforms provide a great Developer Experience (DX), generous free tiers and overall, painless deployment.

Why we didn't choose them:

While this might be viable options for some, we had a free reasons not to go for them:

Free tiers have limits which exceed our needs, which could get expensive fast
Serverless doesn't play well with headless browsers (cold starts kill us)
We'd still need separate compute for Playwright workers
Costs become unpredictable at scale

For a static site or simple API, these are great. For a screenshot service running headless Chrome, they're not the
right fit.

AWS / GCP / Azure

The enterprise options. Almost infinitely scalable, but at cost of money and complexity.

Why we didn't choose them:

Overkill for our scale
Pricing is confusing and easy to mess up
Free tiers expire or have gotchas
We'd spend more time on infrastructure which we rather spend on improving the product

While in the future we might need a bigger scale, we don't see the need today. However, since we're running on Docker
images, migrating to a cloud provider could be relatively straightforward in the future.

DigitalOcean / Linode / Vultr

These VPS providers provide a solid middle ground. They have simple and predictable pricing, good docs, and offer good
capacity at reasonable costs.

Benefits:

$5-10/month droplets are capable enough
Managed databases available
Good reputation in the indie hacker community

Vultr is our favorite and goto hosting provider, and we've used Vultr successfully in other projects.
However, we found something cheaper which we are willing to give a try.

Hetzner

A German hosting company that's popular in Europe but less known in the US.

Why we chose them:

CX22 VPS: 2 vCPUs, 4GB RAM, 40GB SSD - $4.50/month
Same specs on DigitalOcean: $24/month
Data centers in EU (good for GDPR) and US
Reliable, been around since 1997
No surprise pricing - what you see is what you pay

The value is above seems like a very good deal, and we'll do some proper benchmarks just to make sure Hetzner is up to the job.

Our infrastructure breakdown

Here's exactly what we're running and what it costs:

Service	Provider	Cost
VPS (2 vCPU, 4GB RAM)	Hetzner CX22	$4.50/month
Object Storage (screenshots)	Cloudflare R2	$0 (free tier)
Domain	NameCheap	~$10/year
Email (transactional)	Resend	$0 (free tier)
SSL	Let's Encrypt	$0
CI/CD	GitHub Actions	$0
Container Registry	GitHub Packages	$0

Total: ~$5.50/month (plus ~$0.80/month domain cost)

Well under our $20 budget, leaving room for growth.

Why Cloudflare R2 for storage?

Screenshots need to live somewhere, and an S3 compatible storage is the standard. We have several options:

AWS S3: This is the standard, and quite affordable for storage, but egress fees add up when serving images.
Backblaze B2: Cheap storage, free egress through Cloudflare, but no experience with this.
Cloudflare R2: S3-compatible, zero egress fees, generous free tier.

R2 gives us 10GB storage and 10 million reads/month free. That's a lot of screenshots before we pay anything. And when
we do pay, it's $0.015/GB/month for storage with no egress fees.

For a service that's literally serving images, zero egress fees is huge.

The hidden costs we're avoiding

Managed databases - We're running Postgres in Docker on the same VPS. Yes, we're responsible for backups (automated
with a cron job to R2, plus the machine itself it backed up). But managed Postgres starts at $15+/month, with unpredictable costs at scale.

Managed Redis - We're not using Redis yet. Postgres handles our job queue, and caching will be done on the application layer. This is one less service to pay for and manage, which keeps things simple.

Log aggregation - We're using Docker's built-in logging for now. More fancy observability, like Datadog, New Relic or ELK can wait.

Monitoring - A free uptime checker (we're using UptimeRobot) and basic health endpoints.

CDN - Cloudflare's free tier in front of everything. Free SSL, free caching, free DDoS protection.

When we'll upgrade

We're not being cheap for the sake of it, plus, we see this more as being frugal with our budget.
We're trying to make a conscious choice about how we spend our budget, and we allow for growth.

These are example scenarios, and will most likely change over time, but a possible future plan could look like the following:

At 100 paying users: Move Postgres to a managed service, and backups and maintenance become worth paying for.

At 100,000 daily screenshots: Consider a second worker VPS or upgrade to a beefier single machine.

At $500/month revenue: Revisit all infrastructure decisions. We'll have data on what actually needs scaling.

Until then, we're using a slightly scrappy approach. If you have comments or suggestions, we'd love to hear from you!

The risks of cheap hosting

Let's be honest about the trade-offs:

Single point of failure. One VPS means one machine to fail. We're accepting this risk. Hetzner has good uptime, and
we can restore from backups to a new VPS in under an hour.

Limited resources. 4GB RAM is enough for Postgres + Spring Boot + a couple Playwright instances. But we can't run
ten parallel browser sessions. We'll optimize carefully and queue jobs, and most likely we'll spin up more machines when we require more capacity.

No geographic redundancy. All our infra is in one Hetzner data center. If that data center has issues, we're down.
Again, acceptable at this stage, but it's something we'll look into when we need to.

Manual scaling. Adding capacity means provisioning new VPS instances manually since there is no auto-scaling. This is fine fine for now to keep
our costs under control, but might change in the near future.

What we did today

Finalized hosting decisions
Set up Cloudflare R2 bucket for screenshot storage
Configured Cloudflare DNS and SSL
Created backup script for Postgres → R2
Set up UptimeRobot monitoring
Updated docker-compose with R2 credentials

Total spent so far: $4.50 for the Hetzner VPS (first month). Everything else is on a free tier.

Tomorrow: the core engine

On Day 6 we're finally writing the fun code. Getting Playwright running, capturing our first programmatic screenshot, and
learning what breaks when you try to render the web.

Book of the day

The Frugal Architect by Werner Vogels

Werner Vogels is Amazon's CTO, and this collection of essays explores cost-conscious system design. The irony of AWS's
CTO writing about frugality isn't lost on us, but the principles are solid.

His core laws include "make cost a non-functional requirement," "unobserved systems lead to unknown costs," and
"cost-aware architectures implement cost controls."

The key insight for us: cost efficiency isn't something you bolt on later. It's a design constraint from day one.
Choosing Hetzner over AWS, R2 over S3, and Postgres-as-queue over Redis aren't just about saving money - they're about
building a sustainable business where unit economics work even at small scale.

The essays are free to read online, but we'd recommend bookmarking them for reference.

Current stats:

Hours spent: 10 (previous 8 + 2 today)
Lines of code: ~250
Monthly hosting cost: $5.50
Revenue: $0
Paying customers: 0
Storage configured: ✓
Monitoring active: ✓
Backups automated: ✓

If you want to see the service in action, checkout allscreenshots for a free trial.

Day 4: Setting Up CI/CD

Erik — Sun, 04 Jan 2026 11:37:39 +0000

Day 4 of 30. Today we're automating deployment before we have much to deploy.

One of the most important lessons we've learned is that CI/CD is not optional. We want to deploy quickly, reliably and as often as possible.
Setting this up for allscreenshots.com before we have anything to deploy might seem backwards since we don't have a working product yet. Why spend time on deployment pipelines?

One of the reasons for this is because we've learned the hard way: the longer you wait with setting an automated deployment pipeline, the harder it gets.
You'll end up with more dependencies, more complexity (for example, the provisioning of a database, failover, auth, etc), more edge cases. Deploying manually, similar to testing manually, is not an option for us, so we're setting this up early.

By the end of today, every push to our main branch will automatically build, test, and deploy our app to a real server.

The goal: boring, reliable deploys

We want deployments to be a non-event. The idea is to push code, wait a few moments, and it's live. There are no manual steps and no manual verifications.

Here's what we're setting up:

GitHub Actions runs on every push
Build the React frontend and bundle it into the Spring Boot app
Run tests (even though we barely have any yet)
Build a single Docker image for our combined service
Push image to GitHub Container Registry
Deploy to our VPS via SSH and some scripts

One deployable unit

We're keeping things simple: one Docker image that contains everything. The React frontend gets built and bundled into the Spring Boot JAR as static resources. Spring Boot serves them directly - no separate web server, no nginx, no complexity.

Why this approach?

Simpler deployment. One container to build, push, and run. No orchestrating multiple services.

Simpler networking. No CORS issues, no reverse proxy configuration. The API and frontend share the same origin.

Simpler development. Run one thing locally, get everything. No "frontend is on port 3000, backend is on port 8080" confusion.

Good enough for our scale. If we ever need to scale frontend and backend separately, we can split later. Right now, that's premature optimization.

The GitHub Actions workflow

Here's our .github/workflows/deploy.yml:

name: Build and Deploy

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 21
        uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'temurin'

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install frontend dependencies
        working-directory: ./frontend
        run: npm ci

      - name: Run frontend tests
        working-directory: ./frontend
        run: npm test -- --passWithNoTests

      - name: Run API tests
        run: ./gradlew test

  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest

  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    steps:
      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /opt/screenshot-api
            docker compose pull
            docker compose up -d
            docker system prune -f

Nothing fancy. It runs tests, builds one Docker image with everything bundled, pushes it to GitHub's free container registry, then SSHs into our server to pull and restart.

The Dockerfile

One Dockerfile that builds everything:

# Stage 1: Build the frontend
FROM node:20-alpine AS frontend-build
WORKDIR /frontend
COPY frontend/package*.json ./
RUN npm ci
COPY frontend/ ./
RUN npm run build

# Stage 2: Build the backend (with frontend bundled in)
FROM eclipse-temurin:21-jdk-alpine AS backend-build
WORKDIR /app

# Copy Gradle files first for better caching
COPY gradlew build.gradle.kts settings.gradle.kts ./
COPY gradle gradle
RUN ./gradlew dependencies --no-daemon

# Copy frontend build output to Spring Boot static resources
COPY --from=frontend-build /frontend/dist src/main/resources/static

# Copy source and build
COPY src src
RUN ./gradlew bootJar --no-daemon

# Stage 3: Runtime image
FROM eclipse-temurin:21-jre-alpine
WORKDIR /app

# Playwright dependencies will be added later
RUN apk add --no-cache chromium

COPY --from=backend-build /app/build/libs/*.jar app.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Three stages:

Frontend build - npm install, npm build, outputs to dist/
Backend build - Copies frontend output into src/main/resources/static, then builds the Spring Boot JAR
Runtime - Minimal JRE image with just the JAR

The final image is around 250MB. If needed, we can optimise this later using multi-stage builds and jlink and jdeps.

Spring Boot serving static files

Spring Boot automatically serves anything in src/main/resources/static at the root path, no configuration needed is needed for this.

The only thing to make this work is that we need to handle the client-side routing. When someone navigates to /dashboard directly, Spring Boot needs to serve index.html instead of returning a 404 response:

@Controller
class SpaController {
    @GetMapping("/{path:[^\\.]*}")
    fun redirect(): String {
        return "forward:/index.html"
    }
}

This forwards any path without a dot (i.e., not a file request) to index.html, letting React Router handle it.

Docker Compose on the server

On our VPS, we have a simple docker-compose.yml:

version: '3.8'

services:
  app:
    image: ghcr.io/yourusername/screenshot-api:latest
    restart: unless-stopped
    ports:
      - "80:8080"
    environment:
      - DATABASE_URL=postgresql://postgres:${DB_PASSWORD}@db:5432/screenshots
      - STORAGE_ENDPOINT=${STORAGE_ENDPOINT}
      - STORAGE_KEY=${STORAGE_KEY}
      - STORAGE_SECRET=${STORAGE_SECRET}
    depends_on:
      - db

  db:
    image: postgres:18-alpine
    restart: unless-stopped
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=screenshots
      - POSTGRES_PASSWORD=${DB_PASSWORD}

volumes:
  postgres_data:

We have two containers: our application and our Postgres database. The environment variables live in a .env file on the server that we created manually once. Secrets stay out of git.

The VPS setup (one-time)

We're using a Hetzner CX22 - 2 vCPUs, 4GB RAM, 40GB disk, at around $4.50/month, which is more than enough for now.

Our initial server setup took about 30 minutes:

# Update system
apt update && apt upgrade -y

# Install Docker
curl -fsSL https://get.docker.com | sh

# Create app directory
mkdir -p /opt/screenshot-api
cd /opt/screenshot-api

# Create .env file with secrets
nano .env

# Create docker-compose.yml
nano docker-compose.yml

# Login to GitHub Container Registry
echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin

The server just needs Docker and our compose file, everything else comes from the container image.

Why this approach?

GitHub Actions is free for public repos and has generous limits for private ones. This saves us from running something like Jenkins or paying for CircleCI.

GitHub Container Registry is free for public images and cheap for private, this allows us to skip an extra dependency on something like Docker Hub.

Docker Compose is simple. We could use Kubernetes, but for a single VPS with two containers, that's a massive overkill. Compose does exactly what we need for now.

Single image is simpler. One build, one push, one pull, one restart. There is no coordinating of multiple containers, no version mismatches between frontend and backend, and we're staying away from microservices or distributed services as long as we can to reduce complexity.

SSH deployment is good enough. Fancy zero-downtime deployments can come later. For now, a few seconds of downtime during deploys is fine, and it's easy to improve this in the near future

What we didn't do

No Kubernetes. Kubernetes is a quite complex thing to manage, and we have no need for it yet.

No Terraform. Our infrastructure is one VPS. We can recreate it manually under 30 minutes if needed.

No separate staging environment. We'll test locally and in CI. Our staging environment, which is definitely a good idea, can come later when the need is there.

No blue-green deployments. This is overkill for now. Docker Compose restarts are fast enough, we can restart in about 10 seconds.

No separate frontend/backend containers. One deployable unit keeps things simple. We can split this later if needed.

Testing the pipeline

We pushed a dummy commit to verify everything works:

GitHub Actions triggered ✓
Tests passed ✓
Docker image built (frontend + backend combined) ✓
Image pushed to registry ✓
SSH deployment succeeded ✓
App running on VPS ✓

It took about 4 minutes end-to-end. This is fast enough for our needs, and we can optimize this later if it bothers us enough.

What we accomplished today

Wrote GitHub Actions workflow for CI/CD
Created single Dockerfile that bundles frontend into backend
Set up Docker Compose on VPS
Configured secrets in GitHub
Verified the full pipeline works

From now on, shipping is just git push. That's a good feeling.

Tomorrow: choosing our hosting

Day 5 we'll dig deeper into the hosting decision. Why Hetzner? What are the alternatives? How do we think about cost vs. convenience at this stage?

Book of the day

The Phoenix Project by Gene Kim, Kevin Behr & George Spafford

This novel (yes, a novel about IT operations) transformed how we think about deployment and DevOps. It follows an IT manager at a struggling company and shows how applying manufacturing principles to software delivery can fix broken organizations.

The core insight we got was: work in progress is the enemy. Long-lived branches, manual deployments, and "we'll automate it later" attitudes create bottlenecks that slow everything down.

Setting up CI/CD on day 4 of a project might seem premature, but our experience and the lessons from this book convinced us that the pain of manual deployment compounds over time, while the investment in automation pays dividends immediately.

We can really recommend this book. It's a quick, engaging read, and while it is written for the DevOps world, it reads like a novel.

Current stats:

Hours spent: 8 (1 + 2 + 2 + 3 today)
Lines of code: ~200 (yml files count, right?)
Revenue: $0
Paying customers: 0
CI/CD pipeline: ✓
Auto-deployment: ✓
VPS running: ✓

Day 3: Architecture Sketch on a Napkin

Erik — Sat, 03 Jan 2026 16:39:18 +0000

Day 3 of 30. Today we're drawing boxes and arrows before writing our code.

As a software developer, it's very tempting to just start coding. But while tempting, we've been burned before,
by diving in without a clear picture of how the pieces connect. A few hours of sketching and brainstorming now
could potentially save us days (or more!) of rework later, so that's exactly what we'll do in this session.

For those who are just jumping in: we're building allscreenshots, our SaaS for screenshot automation.

Just a small note: this isn't a "formal" architecture document. It's just the napkin sketch, the document we'll use
for discussions and some our decision-making, but with the full understanding that our end solution will most likely
deviate from this in the future, but it's the mental model we'll hold in our heads while building our target state.

Two API modes: sync and async

Before we've even started, we've already introduced some version of feature creep: we're offering two ways to capture screenshots.
We thought long and hard about this, like can we get away with just 1 version for simplicity reasons, but given our
domain, and our core focus on making screenshots, we've decided that we need to offer both (but our implementation phase
will focus on 1 to start with).

So, after thinking through the use cases, we're offering two ways to capture screenshots:

Synchronous (v1 focus): A request comes in, we capture the screenshot, and we return it directly.
This is simple (from the consumer perspective), immediate and great for most use cases.

Asynchronous (v2): A request comes in, we queue a job, and return a job id immediately.
The client polls or receives a webhook call when done. This solution would be better for high-volume batch processing and for cases
where direct feedback isn't an immediate requirement.

Our goal is to build the sync API first. The reason for this is that it's simpler, it covers 80% of use our currently identified use cases,
and gets us to market faster, which allows us to get immediate feedback. The async API will come later, but will reuse a lot of the building
blocks we introduced while building the sync API.

The sync happy path

Here's what happens when someone requests a screenshot synchronously:

Simple flow:

Client sends URL
We validate (API key, quota, URL format)
We capture the screenshot
We upload to storage
We return the image URL

Total time: 2-5 seconds depending on the target site.

The async happy path (future)

For batch processing or very slow sites, async makes more sense:

The async flow decouples accepting work from doing work:

Client sends request with async: true
We create a job and return immediately (50ms)
Background worker processes the job
Client polls for result (or receives webhook)

We're not building this yet, but the architecture supports it.

Why sync first?

Simpler implementation. No job queue, no polling logic, no webhook infrastructure. Less code, fewer bugs.

Faster time to market. We can ship a working product sooner.

Good enough for most cases. If your screenshot takes 3 seconds, waiting 3 seconds is fine. You don't need async complexity.

Easier to explain. "Send URL, get screenshot" is simpler than "send URL, get job ID, poll for result."

We'll add async when:

Customers ask for batch processing
We need to handle very slow sites (30+ seconds)
We want to offer webhooks

The components

Here's what we're actually building:

┌────────────────────────────────────────────────────────┐
│                        VPS                             │
│                                                        │
│   ┌────────────────────────────────────────────────┐   │
│   │              Spring Boot API                   │   │
│   │                                                │   │
│   │  ┌──────────┐  ┌──────────┐  ┌──────────────┐  │   │
│   │  │  REST    │  │  Auth &  │  │  Screenshot  │  │   │
│   │  │ Endpoints│─▶│  Quota   │─▶│   Service    │  │   │
│   │  └──────────┘  └──────────┘  └──────────────┘  │   │
│   │                                     │          │   │
│   │                              ┌──────▼───────┐  │   │
│   │                              │   Browser    │  │   │
│   │                              │    Pool      │  │   │
│   │                              └──────────────┘  │   │
│   └────────────────────────────────────────────────┘   │
│          │                                             │
│   ┌──────▼───────┐                                     │
│   │   Postgres   │                                     │
│   │  (users,     │                                     │
│   │   keys,      │                                     │
│   │   usage)     │                                     │
│   └──────────────┘                                     │
│                                                        │
└────────────────────────────────────────────────────────┘
           │
           ▼
    ┌─────────────┐     ┌─────────────┐
    │   React     │     │  Cloudflare │
    │   Frontend  │     │     R2      │
    │             │     │  (images)   │
    └─────────────┘     └─────────────┘

Spring Boot API - The main application. For sync mode, everything happens in the request thread or in coroutines.

Browser Pool - Reusable browser instances. Creating a browser is slow (~500ms), so we keep a few warm.

Postgres - Users, API keys, usage tracking. Most likely not used for job queuing in sync mode.

R2 Storage - Screenshots uploaded here. Depending on the configuration, we return signed URLs that expire after a period of time.

React Frontend - Landing page and dashboard. Static files.

Sync API design

Create Screenshot (sync)

The current design is just a proposal. There's a high chance we'll make this a GET API instead of post, so it's easier
to call the API from an image tag, but in terms of functionality, the offered features will be similar.

POST /api/v1/screenshots

Request:

{
  "url": "https://example.com",
  "device": "desktop",
  "full_page": false,
  "format": "png"
}

Response (200 OK):

{
  "id": "scr_abc123def456",
  "url": "https://example.com",
  "image_url": "https://storage.../scr_abc123.png?signature=...",
  "created_at": "2024-01-15T10:30:00Z",
  "metadata": {
    "width": 1920,
    "height": 1080,
    "file_size": 245678,
    "format": "png",
    "capture_time_ms": 2340
  }
}

or:

<binary data>

The response includes the image URL immediately, or will include some meta-data. No polling is required to capture the screenshot.

Timeout handling

Sync requests have a configurable timeout. If the page doesn't load by then we'll return an error to stop the client from waiting.

{
  "error": {
    "code": "timeout",
    "message": "Page did not load within 30 seconds"
  }
}

For sites that regularly take longer, or multiple pages need to be captured, async mode will be the answer.

Async API design (future)

Create Screenshot (async)

POST /api/v1/screenshots

Request:

{
  "url": "https://example.com",
  "async": true,
  "webhook_url": "https://yoursite.com/webhook"
}

Response (202 Accepted):

{
  "id": "scr_abc123def456",
  "status": "pending",
  "created_at": "2026-01-15T10:30:00Z"
}

Poll for status

GET /api/v1/screenshots/scr_abc123def456

Response when pending:

{
  "id": "scr_abc123def456",
  "status": "pending"
}

Response when complete:

{
  "id": "scr_abc123def456",
  "status": "completed",
  "image_url": "https://storage.../scr_abc123.png",
  "metadata": { ... }
}

Webhook callback

If webhook_url provided, we POST to it when done:

{
  "event": "screenshot.completed",
  "data": {
    "id": "scr_abc123def456",
    "status": "completed",
    "image_url": "https://..."
  }
}

What we're deliberately not building yet

There are a lot of things we're not building yet as part of this iteration, and the list is too long to include here,
but some notable items which are not built yet, but which will be built later, are things like:

Multiple browser types - Chromium only. We'll implement Firefox/WebKit and other browsers later.

Screenshot caching - We want to offer some form of configurable caching, but at this moment, we'll always make a screenshot.

Horizontal scaling - At this moment, we'll run a simple VPS. We can scale both horizontally and vertically when we need to, and will
do so depending on our needs.

What we did today

Mostly thinking and sketching:

Drew the architecture diagrams
Designed both sync and async APIs
Decided to build sync first
Identified what we're not building, yet

We haven't pushed any code today, on purpose. Our focus is on getting the foundation right, and having clarity on where we're going, which is
worth our time as well.

Tomorrow: CI/CD on day one

Tomorrow, we're getting our hands dirty, and we'll finally(?) be writing some code, plus we're setting up the deployment pipeline,
where every successful build will end up straight in production, which will allow us to iterate fast.

Book of the day

Designing Data-Intensive Applications by Martin Kleppmann

This is the book we wish we'd read earlier in our careers. It fundamentally changed how we think about systems.

Kleppmann covers databases, distributed systems, batch processing, stream processing - all the building blocks of modern applications. But more importantly, he explains why things work the way they do.

The chapter on message queues vs. request/response patterns directly informed our sync-first decision. Sync is simpler and sufficient for our use case,
and async adds complexity that we don't need just yet.

Designing Data-Intensive Applications is not a quick read. But if you're building anything that handles large amounts of data, then this
book is an essential read.

Current stats:

Hours spent: 5 (1 + 2 + 2 today)
Lines of code: ~50 (still mostly boilerplate)
Revenue: $0
Paying customers: 0
Architecture documented: ✓
API design (sync): ✓
API design (async): ✓ (documented for later)

Day 2: Tech Stack Decision - Why Kotlin/Spring Boot + React + Postgres

Erik — Sat, 03 Jan 2026 16:30:54 +0000

Day 2 of 30. Zero lines of code yesterday, but today we're laying the foundation.

Picking a tech stack for allscreenshots is an important decision. It's easy to spend days researching, comparing benchmarks, reading opinions and all of that.
However, we're not doing that for this project. We're going to pick something we know well and that we can move fast in. Here's what we chose and why,
something we decided in about an hour, but with the idea that new insights may lead to new solutions.

The backend: Kotlin with Spring Boot

Kotlin on the backend. With a team who is mostly specialised in Java, Kotlin is our next step up. Combined with Spring Boot, and in the future perhaps other frameworks, it's a solid foundation for our app.

Our main reasons for picking Kotlin on the backend:

We're fast in it. We have years of great experience with Spring Boot which matters more than anything else. The "best" framework is the one where you can ship features without constantly checking documentation. Also, LLM models are really good for the boring parts of the code, like generating the boilerplate, which makes us move just a bit faster.

It's boring in a good way. Spring Boot has solved most problems we'll encounter. Authentication, scheduling, database access, API validation, testing: all of these functionalities are included. There are well-documented way to do all of it, and most problems have been solved before.

The JVM is actually great for this workload. We'll be running headless browsers, managing job queues and handling concurrent API requests.
The JVM handles concurrency extremely well, and Kotlin's coroutines give us async capabilities when we need them.

Deployment is simple now. The old complaint about Spring Boot was heavy containers and slow startups. With modern containerization and decent VPS hosting, our app will boot in a few seconds, and will be able to handle a decent load.

We've done this before. We've built a few apps with Spring Boot and Kotlin, and we know what we're doing. We can leverage some of the best practices we've learned over the years, and use some of the software solutions, and CI/CD approach from our previous projects.

The trade-off? There might be a higher memory footprint than applications written in Go for example.
We'll need a solution with at least 1GB RAM, but more is better, and we'll dive a bit deeper in our decision-making process regarding hosting
("Why We Didn't Pick a Cloud Provider", or something like that) in a future post.

The frontend: React

For similar reasons as why we picked our backend technology, we picked React because:

We know it well, and we've built earlier projects in React before.
The ecosystem is mature, with a lot of plugins and tools.
For an application of any size bigger than 100 lines, a typed language is a must, and React's support for TypeScript is great.

Technically, for a dashboard with a few pages, anything modern works - React, Vue, Svelte, whatever. Pick what you're productive in. For us, that's React.
We're having an ongoing discussion if we should pick React or NextJS, but we're a little undecided at the moment, so we're sticking to what we know, so we're leaning towards React for now.

We're keeping the frontend minimal. A landing page, a screenshot demo page, a login flow, some admin panels, a dashboard showing API usage and managing keys, and for our advanced users an audit log and several enterprise features. Our initial design covers around 10 pages in total. We don't have a need for complex state management, and focus on the functionality for now.

Of course, we'll use Vite for the build tooling because it's fast and simple. Also, we use Tailwind for styling because it allows us to create a presentable
design in a short amount of time without spending a large amount of time on dealing with CSS.

The database: Postgres

This one was easy, and we had zero hesitation in choosing Postgres. Postgres is the right default for almost everything.

Rock solid reliability
Great tooling and hosting options
We already know it can handle non-relational data if we need it
JSON columns for flexible data when we don't want to add migrations
Excellent performance for our scale

We considered going "serverless" with something like a hosted version of Postgres like PlanetScale or Neon. But a managed Postgres on our VPS or a cheap managed instance keeps things simple and predictable and avoids things like cold starts, connection pooling complexity, and potential other surprises.

The stuff we're not using

Worth mentioning what we deliberately skipped:

Kubernetes - Great when you have a big team, but at the moment, it's overkill for us. A single VPS or two will handle our load for a long time.
Microservices - While we appreciate the concept of microservices, we're aiming to keep things simple, so we're going for a modular Monolith, until there's really a compelling reason to switch to a different architecture.
GraphQL - REST is simpler for this use case, and we have a well-defined API, so at the moment, we think GraphQL would be overkill
NoSQL - No see no benefit over Postgres for our data model, plus if we need to, Postgres is a pretty good NoSQL database.
Serverless functions - Headless browsers and serverless are not a great combination. We're aiming for performance, and things like cold starts isn't great for our latency requirements, plus a lot of serverless functions have a maximum duration, which isn't great for our use case.

What we set up today

Created the GitHub repository (monorepo: /api, /web, /infra)
Initialized the Spring Boot project with Kotlin, added basic dependencies
Initialized the React project with Vite and Tailwind
Set up a basic GitHub Actions workflow: build and test on every push
Wrote a placeholder README documenting our stack choices

No running app yet. But the skeleton is there, our CI is green (for now...), and tomorrow we can start writing actual features.

Tomorrow: architecture sketch

Day 3 we'll draw out how the pieces fit together. How does a screenshot request flow through the system? Where do the images go? What happens when things fail?

Book of the day

As before, we have a small book recommendation. As we mentioned before, we use Postgres for everything, and we often say "just use Postgres", and you'll be fine. Well, it seems Joel and Aaron agree with us, and they wrote a book about it with the great title "Just Use Postgres".

Just Use Postgres by Joel Clermont & Aaron Saray

This book landed at the perfect time. The core argument: Postgres can do far more than most developers realize, and reaching for additional tools often adds complexity without real benefit.

Queues? Postgres can do it. Full-text search? Postgres handles it. JSON documents? Postgres has you covered. Cron jobs? Yep. These days, Postgres even handles
Vector Database pretty well, so in the age of AI, Postgres just became even better.

Please note: we're not saying never use specialized tools. A product like Redis or Elasticsearch are great tools! But for a bootstrapped SaaS trying to keep costs and complexity low, Postgres as the foundation makes a lot of sense to us. This book reinforced that instinct and showed us features we didn't know existed.

If you're defaulting to "Postgres for data, Redis for queues, Elasticsearch for search" without questioning it and want to benefit from some simplification, this book is worth a read.

Current stats:

Hours spent: 3 (1 yesterday + 2 today)
Lines of code: ~50 (boilerplate)
Revenue: $0
Paying customers: 0
Repository created: ✓
CI pipeline: ✓

Day 1: Why We're Building a Screenshot API

Erik — Thu, 01 Jan 2026 11:55:41 +0000

The 30-day challenge begins.

Hi! We're two developers, Erik and Illia, spread out in different continents but sharing a combined passion of delivering amazing solutions. Today we're starting a completely new project, and we'd like to do things a bit differently this time. So, instead of building in the dark and focusing on the technology, we will be building a SaaS from scratch and do so in the open, sharing our lessons learned, taking input on the way, and we're aiming to getting our first paying customer in 30 days. We'll document everything: the wins, the frustrations, parts of the actual code, and the real costs.

The product we're developing is a screenshot API. It's not like there aren't solutions out there already, which is one of the reasons why we're building it. This might sound counterintuitive, but it's harder to build something completely unique, plus we already know there is a market. There is a Starter Story about someone who was very successful doing exactly this. Of course our product will be slightly different than existing solutions, and we'd like to take you on this journey with us.

The problem we kept running into

We value quality. One of the ways to accomplish this is by rigorous testing. In our experience, some tests are easier to write than others. For example, deterministic unit tests are easier to write than integration tests, and integration tests are easier to write than end-to-end tests. The most time-consuming tests are end-to-end tests, and they're also the most flaky, especially when they deal with UI and styling.

As part of one of our previous projects, every time we did a new deployment of our app, we would automatically make a screenshot using a small script, send it to a Telegram channel, and manually inspect it. While this may seem laborious, it was a lifesaver for some of our deployments, which technically succeeded, but which introduced visual regression, for example when a new version of a library changed the layout of a page, or we introduced a more strict CSP policy.

So, while we had a process in place, it was still a manual step, and it was still time-consuming, and our setup was limited. So, we wanted to do better. We had a few options in mind.

The options were:

Build it ourselves - Spin up Puppeteer, manage headless Chrome, deal with memory leaks, handle timeouts, figure out why some pages render blank. It usually works until it doesn't, and then we're debugging browser automation instead of building our actual product.
Use an existing service - There are good ones out there. But they're often expensive for small projects, or they lock you into pricing tiers that don't match how you want to use them, or they miss some of the features we were looking for. We'll dive more into these later.

We wanted something in the middle: a reliable, fast, affordable API that just works. So we're building it.

What we're actually making

The product we're building will be focused around automation, and at the core it will be an API which can be used to generate screenshots of websites. That's the core. But the details matter:

Multiple devices - Mobile, tablet, desktop viewports with proper emulation and real devices
Fast - Our aim is to make screenshots with a minimal overhead
Flexible - Full page captures, specific elements, custom wait conditions
Cheap to run - We're bootstrapping this, so our infra costs need to stay minimal
Developer-friendly - Good docs, predictable behavior, clear error messages

Why document this publicly?

There are a few reasons to document this publicly. One of the reasons is to keep ourselves accountable. Another reason is to
get super early feedback. We'd love to hear from you, what we're right, and especially the things we're doing wrong!
There are a lot of "I built a SaaS" (and now I'm earning $ 100k per month) posts. A lot of these posts are lacking details,
lessons learned, and sometimes evidence. We want to do better than that, and take you on our journey!

And, of course, this is partly marketing. Recently, we read Traction: How Any Startup Can Achieve Explosive Customer Growth.
While a lot of developers focus on building the product, this book is a reminder that the marketing (Traction) side of things
is just as important as the product side.

So, we hop that if this series, and our product, resonates with developers, some of you might become customers.

The constraints we're setting

To keep this realistic and replicable:

30 days - Some days might be more hectic than others, but we're aiming to deliver as much as we can.
Minimal budget - Targeting under $20/month for hosting and infrastructure. While we love AWS and other cloud providers, the costs are too high for us to justify it at this moment. So, no expensive services until our revenue justifies it.
Tech we know - While the technology is really not that important at this stage (use PHP and jQuery if that's what you're familiar with), we Kotlin with Spring Boot for the backend. We use React for the frontend, Postgres for the database. Maybe none of this is the trendiest stack, but we picked this because we are very familiar with it, so we can move fast in it.
Ship ugly - The landing page will be very basic. Our dashboards, if any, will be minimal, and some (most?) of our features will be incomplete. That is intentional. While we aim to move fast and not break things, we might make a mistake here and there, so please bear with us. We're optimizing for learning, not to deliver the most polished solution at this stage.

What's happening tomorrow

Tomorrow, we'll dig a bit more into our tech stack decision. Why Kotlin and Spring Boot, and why not tech X? Why Postgres when we could go serverless? Do we even need a database? What are the trade-offs we're consciously making? So, we hope you'll join us for tomorrow. To stay up to date with our ramblings,
please subscribe to our newsletter, or follow us on Twitter. Sorry, X.

Book of the day

Before we leave you, we'd like to recommend a book that we've read alongside building this application. The book is:

Traction: How Any Startup Can Achieve Explosive Customer Growth by Gabriel Weinberg

We've finished reading this just before we started building. Weinberg's core idea is that most startups don't fail because of their product; they fail because of distribution. Building something great isn't enough; you need channels to reach customers, and in the Traction book, Gabriel outlines 19 traction channels and a framework for testing them.

We'll be experimenting with a few during this 30-day sprint: content marketing (this blog series), community engagement (Indie Hackers, Dev.to), some direct outreach, and much more!

So, if you're building something and haven't read this book, we'd recommend it, we think it's worth your time.

Current stats:

Hours spent: 1 (planning and writing this)
Lines of code: 0
Revenue: $0
Paying customers: 0

See you tomorrow.

Forem: Erik

Day 8: Designing the API Contract First

API design principles we're following

The actual API

Implementation notes

What we built today

Tomorrow: building the screenshot queue

Book of the day

Day 7: Build in Public Week 1: What Worked, What Didn't

What we set out to do

What we actually accomplished

What's actually working

What's not working (yet)

Honest assessment: are we on track?

What we're changing for week 2

The numbers

What would success look like?

Lessons from week 1

Tomorrow: the actual API

Book of the day

I Built a CLI to Capture Website Screenshots From The Terminal

The Problem That Kept Bugging Me

So I Built It

Why Rust?

Features Built for Developer Workflows

Device Emulation

Full-Page Captures

Batch Processing

Watch Mode

Clean Screenshots

Multiple Output Formats

Real-World Use Cases

Getting Started

Installation

Quick Start

Links

What's Next?

Debugging Chromium Crashes When Taking Full-Page Screenshots with Playwright

The Problem

Our Setup

Finding the Root Cause

The Fix

Other Things We Considered

Lessons Learned

Monitoring Going Forward

Day 6: The Core Engine - Getting Playwright Running

Why Playwright over Puppeteer?

Setting up Playwright in Kotlin

Our first screenshot service

The first screenshot

What's making it slow?

Making it faster

1. Smarter wait strategies

2. Block unnecessary resources

3. Browser reuse

Results after optimization

Edge cases we discovered

What we accomplished today

Tomorrow: week 1 retrospective

Book of the day

Day 5: Choosing Our Hosting - How We'll Run This for Under $20/month

The options we considered

Vercel / Netlify / Railway

AWS / GCP / Azure

DigitalOcean / Linode / Vultr

Hetzner

Our infrastructure breakdown

Why Cloudflare R2 for storage?

The hidden costs we're avoiding

When we'll upgrade

The risks of cheap hosting

What we did today

Tomorrow: the core engine

Book of the day

Day 4: Setting Up CI/CD

The goal: boring, reliable deploys

One deployable unit

The GitHub Actions workflow

The Dockerfile

Spring Boot serving static files