30 Days Building an AI DevOps Tool in Public: Numbers, Mistakes, Learnings
Exactly 30 days ago I published ARIA — an AI senior DevOps engineer SaaS I'd been building for months.
Here's everything: the real numbers, the mistakes, and what actually worked.
The Numbers
| Metric | Day 1 | Day 30 |
|---|---|---|
| Signups | 0 | 89 |
| DAU | 0 | 22 |
| Free → Pro conversion | 0% | 4.5% |
| MRR | $0 | $84 |
| LinkedIn followers | 312 | 741 |
| Content pieces published | 0 | 21 |
| Organic SEO impressions | 0 | 4,200 |
Not viral numbers. But real, growing numbers.
What Worked
1. Publishing daily content from day one
I didn't wait until I had 100 users to start creating content. I started writing technical articles about the exact errors ARIA solves — nginx 502s, CrashLoopBackOff, Docker OOM — before I had significant traffic.
Three of those articles are now ranking on page 1-2 for their target keywords. That SEO traffic is starting to compound.
2. The building-in-public posts
Every post where I shared real numbers — even embarrassingly small ones — outperformed every "here's a DevOps tip" post. Developers respond to honesty.
"$20 MRR, 31 users, learning every day" got more engagement than "here's how to fix nginx."
3. The 4-week memory feature
The one feature users consistently mention in DMs: they don't have to re-explain their infrastructure every session. ChatGPT can't do this. It's the thing that makes ARIA feel like an actual colleague rather than a search engine.
What Didn't Work
1. The repo scanner friction
I built a full GitHub repo security scanner that grades A-F. It's technically one of the most impressive features. Almost nobody used it in month 1.
Why: you had to connect your GitHub account before seeing any value. The friction killed it.
Fix in progress: anonymous scan of any public repo URL.
2. Posting too much without reading comments
In week 2 I was publishing so much content that I wasn't responding to comments quickly enough. Comments that didn't get a reply in the first hour tanked the post's reach.
Lesson: it's better to publish 3 posts you can actively engage with than 7 you ignore.
3. The pricing page
The original pricing page was too wordy. After I simplified it to just three plans with bullet points, the conversion from pricing page → signup increased noticeably.
The Three Mistakes That Cost Me
Launched without a proper onboarding flow. Users signed up, tried the tool, but didn't know what to do first. I lost signups to confusion.
Focused on features before trust. I spent weeks on the repo scanner before having strong social proof. Should have been the other way around.
Underestimated how long SEO takes. I expected traffic from articles within days. It's weeks.
What Month 2 Looks Like
- Target: 200 signups, $200 MRR
- Ship: Slack integration, VS Code extension alpha
- Fix: Onboarding flow
- Content: Double down on what's ranking
If you're building in public and want to talk shop — find me on LinkedIn or Twitter @yashkumar_dev.
ARIA is at step2dev.com — free tier, no credit card.
I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.
Top comments (1)
This is a good example of something most engineers underestimate distribution and product thinking matter as much as the engineering itself.
The repo scanner point is especially interesting. Technically complex features don’t always translate to user value if there’s friction before the first meaningful interaction.
Also aligns with what we see in platform engineering — adoption depends less on how powerful a system is, and more on how quickly teams can get value from it without additional cognitive load.
The “memory” feature makes sense from that lens. Reducing repeated context setup is a real productivity gain, which is probably why users noticed it more than other features.
Curious how you're thinking about onboarding next especially for first-time users with no context.