How We Secured Our AI Startup on a Bootstrapped Budget

I've been a cybersecurity consultant for over 20 years. I've worked with banks, government agencies, universities, and tech companies, helping them protect data, investigate breaches, and set up security programs. Here's what I've learned: hackers don't care how big you are. If you've got data worth stealing, you're a target.

Bootstrapped startups don't have much room to spend on things that don't show up in the product. Every dollar gets questioned. So security often gets pushed down the list behind features and growth. But that doesn't mean hackers wait for you to catch up.

That's the thinking behind how we built Recroot.app, our AI platform for practicing workplace conversations.

We didn't have a security budget, so we used free tools and did the work ourselves. Here's what we did to keep customer data safe.

Embedding Privacy Before Development Starts

Getting privacy right came down to a few commitments:

• Customers have the right to know where we store their data and who we share it with
• Customers must consent to any storing or sharing of their data.
• Customers have the right to know if we use their data for AI processing and how
• Customers must be able to withdraw consent, delete their account, or permanently remove their data at any time.
• Customers need to know how long we store their data and how we dispose of it securely once it's no longer needed.

To meet these requirements, we adopted a minimum-collection approach. We only collect, store, and process as much information as customers need to use the full app without interruption.

Data isn't stored anywhere outside our secure cloud environment, and it isn't shared with third parties. We also limit AI processing to anonymised text, so personally identifiable information isn't unnecessarily exposed to AI models.

Identifying the Risks

One of the best practices I've shared with organisations I've consulted for over my 20-year cybersecurity career is: don't buy security products without first understanding your risks. I followed the same approach here.

We identified these risks for our app:

• Vulnerabilities in our own code
• People are trying to exploit our website or app
• Security risks from the open-source and third-party software we rely on
• Attempts to misuse our AI features
• Issues caused by human error or misjudgement
• Vulnerabilities from unpatched servers

Once we knew the risks, implementing the controls got a lot easier. Here's how we remediated each one without breaking the bank.

Vulnerabilities in our own code

The best time to fix a vulnerability is before it goes live, or in other words, before it ever reaches a customer.

We use Semgrep Community Edition in our development workflow to scan source code for common security vulnerabilities and insecure coding patterns. Semgrep runs before any code is merged into master, and every vulnerability it flags gets resolved before that merge happens. That's how we keep known vulnerability classes out of the app entirely.

People are trying to exploit our website or app

Clean code doesn't guarantee a clean app. Issues can slip in during merges or just get missed. So we regularly scan the running application using OWASP ZAP, which helps us catch:

• Cross-site scripting (XSS)
• Authentication weaknesses
• Missing security headers
• Security misconfigurations
• Common OWASP Top 10 issues

No scanner catches everything. It's one more layer of checking before new functionality goes live.

Our applications sit behind Cloudflare's free Web Application Firewall (WAF), which filters malicious traffic before it reaches our infrastructure, including automated bots, common exploits, suspicious traffic patterns, and basic denial-of-service attempts. It cuts down the noise before requests ever hit our servers.

Security risks from open-source and third-party software

Like most modern applications, ours depends on several open-source packages. The risk is that vulnerabilities get discovered in those packages after the fact, and we need to patch before anyone exploits them.

We use GitHub Dependabot to continuously monitor our dependencies and alert us when known vulnerabilities are published. Simple to turn on, and it's caught things we would have otherwise missed.

Vulnerabilities from unpatched servers

On the infrastructure side, we deliberately minimise the number of servers we manage ourselves. Our application runs on Amazon ECS, which makes it much easier to deploy updated container images whenever security patches are released. Rather than maintaining long-lived servers that can gradually fall behind on updates, we regularly rebuild and redeploy our containers with the latest patched base images as part of our deployment process.

Reducing the amount of infrastructure you have to manage also reduces the number of things you can forget to patch.

Issues caused by human error or misjudgement

Across the incidents I've responded to over the years, human misjudgment or misconfiguration has consistently been one of the leading causes. API keys, access tokens, cloud credentials, database passwords, and publicly exposed S3 buckets get accidentally exposed more often than people think.

The goal is catching them fast. We use Gitleaks to scan our repositories for accidentally committed credentials before they turn into a much bigger problem.

Attempts to misuse our AI features

Building an AI product means dealing with risks traditional applications never had to think about, such as prompt injection, model manipulation, unexpected outputs, and sensitive data exposure. AI systems can sometimes be talked into doing things they were never meant to do.

To manage that, we've added:

• Input validation and sanitisation
• Prompt injection testing
• Restricted access to sensitive functionality
• AI actions limited to approved workflows
• Monitoring of prompts and outputs for unexpected behaviour

Manual penetration testing (ethical hacking)

Automated tools catch known vulnerabilities well. They're much weaker at spotting flaws in business logic, or at recognising how an attacker might chain several small weaknesses together into something serious.

One area where we deliberately spend money is manual penetration testing. In simple terms, this means hiring ethical hackers to look for vulnerabilities that automated tools often miss. We run periodic manual pen tests covering:

• Authentication
• Authorisation
• API security
• Business logic
• AI-specific attack scenarios

Every test has turned up something we hadn't thought of which is the whole point of running them.

Cybersecurity isn't about buying the most expensive tools. It's about understanding your biggest risks and reducing them in practical ways. For now, our lean security stack does exactly that. As our startup grows, we'll continue investing in stronger capabilities to stay ahead of evolving threats.

About the Author​

Gokul Srinivasan is the founder of Recroot.app, an AI mobile app that helps professionals practise the workplace conversations most people never prepare for from challenging decisions to presenting ideas to senior stakeholders. He built it because he kept watching capable people get overlooked, and realised the gap was almost never technical.