Building a security audit tool for indie hackers - need your feedback
Hi guys,
I’ve been working on a side project lately: an automated security audit service for small SaaS projects (https://tlsguard.tech/).
I'm a solo dev, and I’ve seen how easy it is to focus on shipping features and completely ignore security until something breaks or an IDOR pops up. I wanted to build something that acts as a "second pair of eyes" to catch the obvious (and some not-so-obvious) stuff before it becomes a problem.
I’m currently refining my audit process and I’d love to hear from other devs:
What's the one thing in security that actually keeps you awake at night?
Have you ever had a security wake-up call that changed how you code?
If you’re open to a quick check of your app's security, let me know! Also, really appreciate any feedback on the landing page or the idea itself.
Security tools for indie devs only work if they stay low noise. False positives kill trust fast.
Curious how you’re balancing depth vs “don’t overwhelm me with 50 warnings”.
Really interesting idea. Security is one of those things founders know they should prioritize, but it often gets pushed until later. I'm curious who do you see as your ideal first users? Solo founders, small SaaS teams, or slightly larger startups? I think the onboarding experience will be key if you want people to run audits regularly. Looking forward to seeing how this evolves!
Hi! Thanks for the great question and the support. You’re absolutely right: security is one of those things that always loses the competition for time against new features until it's too late. Regarding your question, I’m currently focusing on solo founders and small SaaS teams, as I’ve been through this myself and know that they often lack the resources for a dedicated security specialist. You hit the nail on the head regarding onboarding - that is my top priority for refinement. Currently, I’m intentionally keeping the process personal, handling it via DMs and individual agreements, to better understand the specifics of each project and provide the most high-quality, actionable results rather than just a dry report. I’d love for you to take a look at the site and share your thoughts on whether you feel this approach is justified at this early stage!
Security for indie hackers is an underserved niche because most tools are built for enterprises. Are you positioning this as "simpler than big tools" or "cheaper than consulting"? Those require totally different GTM.
Thanks for your komment. Right now, I’m positioning this as 'more accessible and actionable than high-end consulting'. While enterprise tools often generate a lot of noise, and standard consulting is usually out of budget for indie hackers, I’m filling that gap by acting more like a 'security partner.' By handling the process personally via DMs and agreements, I can provide a tailored, manual assessment that fits a solo dev's specific workflow, rather than just running a generic script. Thanks for pointing out the GTM implications - it's definitely something I'm keeping in mind as I scale!
"Exactly — the manual part is the moat. Once you hit product-market fit with one vertical, scaling becomes the inverse problem (how to systematize without losing the personalization)."
For small SaaS founders, I think the hardest part is prioritization. A scan that returns 40 issues can make people feel worse, not safer.
The valuable output is probably: "these 3 issues create the most realistic path to user/data/business damage in your specific app."
I would test the landing page around that. Instead of selling a generic audit, show what a founder gets on Monday morning: ranked risks, why they matter, and the smallest fix. The fear is real, but the buyer needs relief, not a larger todo list.
That is an interesting take, thank you for the comment! I definitely see your point about the risk of overwhelming founders. However, I have found that for security audits, a comprehensive approach is usually what brings the most value. Clients I work with are generally looking for a full picture - including PoC(proof of concept) and detailed remediation steps - so they have a clear roadmap to secure their entire stack, not just a subset of issues. I prefer to provide the complete, deep-dive report so they can prioritize based on their specific needs.
Hey Mike – this is exactly the kind of tool I've been thinking about lately.
I'm building a medication tracker for family caregivers, and security is constantly in the back of my mind. Health data is sensitive, and one mistake – a misconfigured endpoint, an exposed log – could destroy trust before the app even gets off the ground.
To your questions:
What keeps me awake? API key leaks. I've got third‑party services sprinkled everywhere – notifications, analytics, file storage. One .env file accidentally committed, and suddenly I'm not just fixing code, I'm rotating secrets across a dozen services at 2am. That scenario genuinely haunts me.
Wake‑up call? Early on, I realized my "admin view" for family members was returning more data than it should – nothing catastrophic, but enough to make me rethink every endpoint. Now I mentally assume every API response is public by default and explicitly restrict from there. That shift in mindset changed everything.
On the landing page: The messaging is clear, and the "why indie hackers" angle resonates. One suggestion – I'd love to see a sample report or a "what we actually check" list right on the page. Even a screenshot of a before/after would build trust. Right now I'm nodding at the problem but not quite sure what the output looks like.
Also – and I say this with empathy because I've been there – the name tlsguard made me think this is only about TLS/SSL certs at first. If you're doing broader OWASP Top 10 / API security checks, you might want the copy to shout that earlier.
Thanks for the detailed feedback! I’m glad to hear the pain points resonate with you. I actually do cover OWASP Top 10 and API security in my audits, and I already provide sample reports on the site - though it sounds like they aren't as easy to find as they should be. I'll definitely keep your suggestions regarding the visibility of the audit scope and the reports in mind; while I may not implement these changes immediately, I'll certainly consider them as I continue to evolve the site in the future. Thanks for pointing out that the current layout isn't showcasing the depth of the check effectively enough!
This taps into a very real gap in indie SaaS workflows—security is usually treated as a post-launch concern rather than a continuous signal. The “second pair of eyes” framing works because it lowers the perceived expertise barrier while still addressing a high-stakes fear. The key challenge for tools like this is usually not detection, but prioritization—helping founders distinguish between theoretical vulnerabilities and actual exploit paths in their specific stack.
That is a spot-on observation. You're absolutely right - the real value isn't just in raw detection, but in translating those technical findings into actionable business risks. That is why I focus heavily on providing a full audit report with an Executive Summary and clear PoCs. It helps bridge the gap between 'theoretical vulnerabilities' and understanding which ones actually pose a tangible threat to their specific stack. Thanks for highlighting that distinction!
Glad it resonated.
Your reply made me think there's one strategic decision sitting underneath that approach which becomes much more significant as the product grows, but I don't think I can explain the reasoning properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?
One thing I’d add for small SaaS security audits: don’t stop at “backups exist.” Ask for the latest restore artifact.
For me that means: backup id/object, restore target, timestamp, restore command/log, and a couple of smoke checks showing the restored app/db was usable. A pg_dump cron or dashboard screenshot is useful, but it doesn’t prove the recovery path works.
It’s a good indie-hacker control because the first restore test usually catches boring-but-real problems: stale credentials, missing extensions, wrong Postgres client version, secrets not captured, or a dump that stopped including what you thought it did.
That is a brilliant point, and you're absolutely right - a backup that hasn't been tested is basically just a false sense of security. Currently, my audits are focused on black-box testing, which is why I haven't included that level of internal process validation yet. However, I’m planning to incorporate white-box testing into my audit process in the future, and 'restore verification' is definitely a great candidate for that phase. Thanks for the practical, actionable advice!
multi-tenant data isolation, every time. one missing "WHERE tenant_id = ?" and you're serving customer A's data to customer B — and it sails through every test because your fixtures are single-tenant, so nothing catches it until you have real concurrent tenants, which is exactly when it's most expensive. if TLSGuard can flag queries missing tenant scoping, that'd be a killer feature for this crowd.
Good point. Multi-tenant leaks are expensive to catch late. Black-box limits us here - we can test cross-tenant IDOR manually (user A tries to access user B's data via ID manipulation), but we can't flag missing WHERE clauses without seeing queries.
What we can catch:
What we miss:
Would you pay extra for deeper multi-tenant testing, or should it
be part of the base audit? Curious what price makes sense.
make it its own tier, not base — and don't flinch on price. it needs 2+ provisioned tenants and more setup than a single-target scan, so the cost is real; and it's where the company-ending leaks live, so anyone actually running multi-tenant knows they need it and will pay for the insurance. bundling it into base just trains people to expect the expensive part for free. name it explicitly ("Multi-Tenant Isolation Audit") so the people who need it self-select. and keep being upfront about the black-box limit — you catch IDOR/enumeration/shared-resource leaks, not query-level scoping — because that honesty is what makes the paid tier trustworthy, and it's your natural upsell path into a code-access tier later.
Thank you for the advice. You are absolutely right - including multi-tenant isolation testing in the basic package is not sustainable and creates unrealistic expectations for the client. As I continue to develop my services, I will either adjust the scope and pricing of the 'Basic' package or offer the multi-tenant architecture audit as a separate, specialized service. For now, I will remain transparent about the limitations of a black-box approach, as I believe this is the best way to build trust with my clients. I appreciate your guidance on how to position these services!
Hi Mike, I ran the TLSGuard page through PagePulse because your "security audit for small SaaS" angle is strong, but trust has to land very fast here.
A few things stood out:
My main read: for this category, the page should quickly answer "what do you check, what do I get back, and why should I trust this with my app?" before going deep into features.
Hope useful — ping me once you've made changes and I'll re-run it
Mike, the thing that keeps me up at night with automation systems is API key exposure combined with runaway agent loops. A single leaked key on a misconfigured agent can burn through real costs before you notice. The black-box approach you described makes sense for keeping audits affordable, but do you also look at common SaaS risk areas like exposed .env files, open S3 buckets, or misconfigured CORS policies? Those are the ones that slip through most often for indie devs shipping fast.
You're right, those are the risks that usually slip through the cracks when you're moving fast. I’ve structured my audit process to address exactly those areas. The service combines automated scanning for infrastructure misconfigurations-like exposed config files, S3 buckets, and CORS issues-with a manual review of logic and potential API key exposures. It’s designed to catch those 'low-hanging' vulnerabilities that often go unnoticed during standard development. You can find more details on how this audit covers these points on my website.
The dependency supply chain is what keeps me up at night - especially when you're shipping fast and pulling in a new package without really knowing its maintainer's track record. I've had the uncomfortable experience of discovering a dependency had gone unmaintained only after it showed up in a security report.
Your "second pair of eyes" approach to catch IDOR and auth issues is really valuable though. Those are exactly the things that slip through because we normalize our own code patterns.
Do you focus your audits on specific vulnerability categories, or do you do a broader check across architecture, dependencies, and code patterns?
Yes, we focus only on specific vulnerabilities with black-box access. I think that if we conducted a full project architecture review, it would significantly increase the price of our services