Day 1: Why we're building a screenshot API

The 30-day project begins.

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 focussing on the technology, we will be building a SaaS from scratch and do so in the open. We will be sharing our lessons learned, taking input on the way, and we’re aiming to getting our first 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. This solution isn’t unique by itself, there are several similar solutions out there already, which is actually one of the reasons why we’re building it. This might sound counterintuitive, but it’s harder to build and validate something which is completely unique, plus we know there is a market. Starter Story had a great episode in which they built 3 SaaS applications with a similar approach: see what’s working, and make it better.

We’re not aiming to just copy existing applications. While our product might share a similar core, our solution will be slightly different and offer a unique proposition which we hope will get some traction later in the process. And while building this product, we’d like to take you on this journey with us. So let’s dive in!

The problem we kept running into

We value quality, and one of the ways to accomplish this is by rigorous testing and 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 the screenshot it. While this may seem laborious, it was a great early detection system 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, the screenshot made after the deployment clearly showed we messed up.

So, while we had a process in place, it was still a manual step, and it was still time-consuming. Plus, our setup was quite limited, since we only captured a few pages, and only the desktop version of those. So, we wanted to do better, and we had a few options in mind.

The options were:

1. 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.

2. 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, with the features you can expect from a great screenshot capture service.

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 capture screenshots of websites. Making screenshots is the core of our product. But there are some important details to keep in mind:

• 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
• Affordable to run - We’re bootstrapping this, so our infra costs need to stay minimal
• Developer-friendly - Good documentation, predictable behavior and 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 success stories about how “I built a SaaS”. However, a lot of these posts are lacking details, lessons learned, and sometimes evidence. We want to do better than that, or fail in more spectacular ways, and we want take you on our journey!

Recently, we read Traction: How Any Startup Can Achieve Explosive Customer Growth. While a lot of developers focus on building the product, a quite important aspect of selling anything, this book is a reminder that the marketing (Traction) side of things is just as important as the product itself, and by doing this, we hope to make you at least a little bit enthusiastic about what we’re building.

So, we hope that if this series works out well, we might all learn something, and hopefully find Allscreenshots interesting enough to try out.

The constraints we’re setting

To keep this realistic and replicable:

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 for a serverless solution? Do we even need a database? What are the trade-offs we’re consciously making? So, we hope you’ll join us for tomorrow, and follow us on Twitter/X at @allscreenshot.

Book of the day

Before we leave you, we’d like to recommend a book that we found incredibly helpful before starting this project. 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.

See you tomorrow.