Shipped my first solo SaaS: SSL/domain expiry monitoring for devs — would love feedback
Hey IH — excited (and a little nervous) to share my first solo SaaS: Watchdog.
The idea came from a close call. I nearly had an SSL certificate lapse on
a site I was responsible for — nothing catastrophic happened, but it was
the kind of moment where you realize you have zero visibility into this
until it's already a problem. No warning, no heads up, just a client
calling asking why the site looks broken.
I looked around for something simple to solve this and came up empty —
everything was either way overbuilt for what a solo dev or small agency
actually needs, or bundled into a bigger, pricier monitoring suite I
didn't want to buy just for this one thing.
So I built the small version: add a domain, it gets checked daily (real
TLS handshake for the cert, RDAP for domain registration expiry, plus a
basic uptime check), and you get emailed at 30/14/7/1 days out before
anything expires. Slack and Discord alerts too, if that's where your team
actually looks.
Free for up to 2 domains, $7/mo for unlimited.
This was my first time shipping something fully end-to-end solo — auth,
database, background jobs, email delivery, deployment, the works. Learned
more than I expected along the way. A few honest lessons from building
this:
- Cloud platforms often block outbound SMTP ports by default, which cost
me a few real hours of confusion before I switched to a provider's HTTP
API instead.
- SQLite-on-a-volume sounds simple until you actually need it to survive
a redeploy reliably — moved to Postgres and haven't looked back.
- Promise.race in JS is great for timeouts, but the "losing" promise can
still crash your whole process later if you don't catch it too.
Where I'm at: just launched, zero users besides me. Would genuinely love:
- Feedback on the product itself and the onboarding flow
- Whether $7/mo feels like the right price point
- Anyone willing to be an early tester
Happy to answer anything about the build, the stack (Next.js + Postgres,
deployed on Railway), or the decision-making along the way.
Congrats on shipping your first solo SaaS! Monitoring SSL and domain expiry is a real pain point for devs — great to see you tackling it
You’re right — invisible problems are often the most painful when they finally surface. I’ve seen the same with SMBs using Finsight AI: cashflow issues feel invisible until they suddenly hit hard. Tackling those hidden risks head‑on is exactly what makes tools like yours valuable.— Francisca @ Finsight AI
Thanks! Yeah, it's one of those problems that's invisible until it isn't — which is exactly what makes it worth solving properly rather than just hoping you remember to check.
The “small version” approach makes a lot of sense here. SSL/domain expiry is one of those problems you don’t think about until something breaks, and then it suddenly becomes urgent. I also like that you kept the scope focused instead of turning it into a full monitoring suite. Curious how you’re thinking about getting this in front of the solo devs/agencies who have experienced this problem but don’t actively search for a solution.
Honestly still figuring this part out — it's the hardest part of this whole thing. My working theory is that "actively searching" isn't really how this gets found, since nobody searches for a solution to a problem they don't know they have yet.
So, the plan is less "rank for SSL monitoring tool" and more: show up where devs/agencies already are (freelancer and agency communities, dev-focused Slack/Discord groups) and lean into content that ranks for the moment right after something breaks — "why did my client's site show a security warning" type searches — since that's when someone actually goes looking.
Would love to hear if you've seen this work well for other niche dev tools — feels like a classic "the problem is invisible until it costs you" distribution challenge.
That “invisible until it costs you” part is interesting. I think a lot of developer tools have the same distribution problem — the user may genuinely need the solution, but only recognize the need after something goes wrong.
It makes me wonder whether content around the failure moment is actually more effective than trying to convince people they have the problem beforehand.
Have you considered building your content/distribution around real incidents or post-mortems rather than the monitoring product itself?
The close-call story makes the product make sense immediately. The interesting question for me is whether people buy this because they actively want monitoring, or because they want to stop carrying the risk of remembering these dates themselves. Curious which framing has resonated more with the early testers.
Really good question, and full honesty — I don't have real early testers to compare yet, this literally just launched. So take this as a hypothesis, not data.
My guess is it leans toward the second framing: nobody wakes up wanting a monitoring dashboard, but plenty of people are tired of being the one person who has to remember a date or the whole thing breaks. The product itself is "checks" — but the actual thing being sold is not having to hold that risk in your own head anymore.
If that's right, the messaging probably shouldn't lead with "monitoring" at all. Something to test once I actually have users to learn from — I'll report back.
I think this is worth continuing by email. What’s the best email to reach you on?
Definitely — would love to keep this going. You can reach me at shashikanth2dg@gmail.com.
Really appreciate you digging into this with me.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Hi Aryan,
I did not receive, could you please check and confirm.
Hi Shashikanth — it’s already been sent. I just double-checked the sent message on my side. Could you check your spam/promotions folder as well?
Got the email which you have sent. Replied to the same email.