The 30-day challenge 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 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.
Top comments (0)