Day 30: The final retrospective - from zero to MRR
Day 30 of 30. We made it.
Day 30 of 30. We made it.
Well, maybe “made it” is a bit of an overstatement, but thirty days ago, this was just a crazy idea with a lot of good intentions, but no data whatsoever. Today, it’s a business with three paying customers, 57 registered users, and a product that actually works. Plus, we have a lot of ideas on how to improve our product, marketing and infrastructure in the upcoming months so we can do even better.
Let’s look back at everything.
Interactive 30-day journey
Explore our complete 30-day journey in this interactive visualization:
+-----------------------------------+
| 30-DAY JOURNEY COMPLETE |
+-----------------------------------+
$135 MRR *
| / \
| / \
$90| * / 3 \ <- 3 Customers!
| / \ / customers \
| / 2 X \
$45| * customers \
| / \ \
|/ 1 \ \
$0| customer \
|=========================================
| Day 24 Day 27 Day 29
+---------------------------------------------> Time
+------------------------------------------+
| ================================ 100% |
| 30/30 days | 84 hours | 5,200 LOC |
+------------------------------------------+
The journey in numbers
| Metric | Start | End |
|---|---|---|
| Days | 0 | 30 |
| Hours spent | 0 | 84 |
| Lines of code | 0 | ~5,200 |
| Commits | 0 | 147 |
| Registered users | 0 | 57 |
| Paying customers | 0 | 3 |
| Monthly revenue | $0 | $135 |
| Screenshots captured | 0 | 6,100+ |
| Monthly hosting cost | $0 | ~$12 (we had to scale up) |
| Customer calls | 0 | 2 |
| Blog posts | 0 | 30 + 5 on allscreenshots.com |
What we built
Below is a small overview of all the things we’ve built in the last 30 days:
Core product:
- Screenshot API with sync endpoints
- Mobile, tablet, and desktop emulation
- Full-page capture
- Custom viewports
- Wait strategies (load, network idle, selector)
- Image resizing
- Response caching
- JPEG/PNG formats
Infrastructure:
- Running API on Hetzner VPS
- Postgres database
- Cloudflare R2 storage
- GitHub Actions CI/CD
- Docker containerization
Business:
- Landing page
- User authentication
- API key management
- Usage tracking
- Stripe billing
- Documentation
Operations:
- Uptime monitoring
- Status page
- Error tracking
- Structured logging
- Admin dashboard
What worked
As a small recap of the last 30 days, and our lessons learned so far:
1. Build in public. This dev log series drove traffic, built trust, and kept us accountable. Multiple customers mentioned finding us through the content. Above everything else, it was fun! It gave us inspiration in certain areas, and building the interactive elements was a lot of fun. Have you tried the (working!) terminal on the main page?
2. Start simple. We built the sync API first. We introduced three pricing tiers, all managed through a basic dashboard. We could have spent months on features no one needed, but we kept it simple. Our first release of our landing page didn’t even allow people to sign up. It was intentional, embarrassing, but kept us very motivated to deliver a signup as soon as we could.
3. Talk to customers. Every paying customer came from a conversation. As much as we’d like to believe that a good product sells itself, if nobody knows about the product, nobody will find it. Period. We had to learn what people needed so we could best provide a solution, and in certain cases explain how we solved it.
4. Ship fast, iterate faster. We deployed a lot. One some days, we deployed to production more than 10 times. Some features we shipped were small, some bigger, but we kept our setup as simple as we could so we can iterate fast. Whether it’s fixing bugs or delivering features, iterating fast is incredibly important, and our responsiveness built trust.
5. Cheap infrastructure. We spent ~$6/month (okay, $12 now) to run everything. Our low costs means we’re “profitable” from day one with minimal pressure.
6. Focus on reliability. Both customers who came in through sales calls mentioned reliability as a key factor. The deciding factor wasn’t the features, nor the price, it was the trust that it would work.
What didn’t work
1. Cold outreach (mostly). We sent 40+ emails, which resulted in 0 conversions. We had a few useful conversations, but no paying customers from cold outreach yet. If anyone has suggestions on how to improve, we’d like to hear from you!
2. Building before validating. We spent quite a bit of time on architecture before talking to a single potential customer. While it’s a bit harsh to say that this worked, we have to real data that this was the best way we spent our time. We could have potentially built something even simpler, and start serving customers from day 1.
3. Assuming we knew what mattered. As software developers, we were probably biased in that we thought technical features would sell. However, customers cared much more about reliability, responsiveness, and support.
4. Waiting to share. We could have launched our landing page a bit earlier, probably even before we started, so the page would be indexed earlier, and might have attracted some potential users. Also, launching earlier could have led to more user feedback.
What we’d do differently
It’s not like we’re done with this one. We’re just getting started, and we’re planning on building a rock solid product!
But, if we could have started all over, or we’re starting another project like this, then these are some of the things we might have done differently.
1. Customer conversations from day 1. Basically, don’t be shy. Before writing any code, talk to at least 10 people who might need your solution. Validate the demand, understand the pain points, and learn to speak your customer’s language.
2. Landing page on day 3. Get something up immediately, even if it’s just a static website with an email address. The goal is to start collecting the contact information of people who might be interested. Build in public from the start, it’s great.
3. Less architecture, more iteration. Our sync-first decision was probably the right way of doing things, but we may have over-designed other parts of the API without knowing if people really need it. YAGNI (You Ain’t Gonna Need It) applies.
4. More content, sooner. The dev log worked, that’s for sure. But we should have also written tutorials, comparisons, and use-case guides earlier. Stay tuned for more technical blogs coming soon!
5. Pricing experiments. We started at $45/month, but we could have tested with $19 or 69 to see what the effect of this the price would have been. General A/B testing is certainly on our list of things to try out earlier.
The money math
Revenue:
- 3 customers × $45/month = $135 MRR
- Annual run rate: $1,620
Costs:
- Hetzner VPS: $12/month
- Domain: ~$1/month (amortized)
- Cloudflare R2: $0 (free tier)
- Stripe fees: ~3% = $4.05/month
- Total: ~$17.05/month
Profit: ~$118/month
We’re profitable, sort of! Given the time and energy we’ve put into this project, our currently hourly rate is less than $1 per hour for sure. But we hope this is a start, and that this is the foundation with room to grow.
What’s next
As mentioned before, this isn’t the end; it’s the beginning. This is what our current roadmap looks like:
Month 2:
- JavaScript SDK (customer request)
- More content marketing
- Target: 10 customers, $250 MRR
Month 3:
- PDF export (customer request)
- Webhook support
- More integrations (Zapier, Make)
- Target: 25 customers, $500 MRR
Month 6:
- $1,000 MRR milestone
- Consider: second product? Expand features? Raise prices?
Will it work?
We really don’t know yet. Our current three customers is promising, but not proof. We know there’s opportunity in the market, but let’s see how we go. We’ll do our best, that’s for sure, and we’ll aim to improve and learn on the way.
At least, right now, we have something real:
- A working product
- Paying customers
- A system for finding more
That’s more than most projects, especially our previous projects, ever achieve.
Thank you
Last, but not least. We want to thank you for staying with us along the road. We really appreciate all the ideas, suggestions, corrections, encouragement, etc, which we heard from you all along the way. Please keep it coming, we appreciate every message! Feel free contact us at hello@allscreenshots.com to say hi!
If you’re thinking about building something: just start. 30 days is enough to go from nothing to something real. It won’t be perfect, we know, and it doesn’t have to be to collect some data. It also won’t be complete, and there will be bugs. We understand that, and so will your customers if you handle this well. But your project will exist, and that matters more than you think.
See you on the other side.
Book of the day
The Almanack of Naval Ravikant by Eric Jorgenson
Naval’s collected wisdom on wealth and happiness. One quote feels right for today:
“Play long-term games with long-term people.”
Building a SaaS is a long-term game. These 30 days were the start, not the finish. The relationships with early customers, the content we’ve created, the skills we’ve developed - they compound over time.
The book is free online at navalmanack.com. Worth reading for the mindset alone.
Day 30 stats
This concludes the 30-day dev log. The product continues at [website]. Follow along for future updates.