From Pen Tester to Founder: A Conversation with Rakshitha

Rakshitha Rao is the co-founder of Seezo, an application security platform built by security experts for security teams. Before starting the company with co-founder Sandesh, she spent years at Synopsys building their application security practice across APAC, a journey that took her from pen tester to customer success leader to founder. What ties these roles together isn't technical prowess alone, but an obsessive focus on customer problems. 

That obsession is now at the heart of Seezo's philosophy: security tools should adapt to how organizations actually work, not force them into rigid methodologies. This conversation explores how this perspective emerged, why it matters, and how it turned Rakshitha into an empathetic founder.

You started your career as a pen tester. How did that happen?

When I graduated from college, I had two offer letters. One was for a developer role at a product company that would later get acquired and the other was for pen testing at a services company. I wanted to think longer-term, about what actually aligned with my interests. So I chose pen testing. This was a chance to do something different. Something that was more applied in some way, I guess.

What is pen testing, exactly?

Pen testing—penetration testing—is when you're hired to try to break into a company's systems. You're looking for vulnerabilities in their applications before the bad guys find them. I enjoyed that for the first six months. I found some cool vulnerabilities but I wanted a chance to own something end-to-end and get closer to the customers.

So what changed?

Now when I think about it, I guess it was one of those inflection points. 

When one of our program managers went on leave for a month, I took the opportunity to step in and handle all the communication for her main client account, an area where I'd already been contributing significantly. It was a chance to take full ownership and really stretch my capabilities.

While managing that relationship, I noticed we were running different assessments for this customer simultaneously without any consolidated status updates going their way. I kept thinking if I were the customer, I'd want a single place to track everything. So I took the initiative to create a simple tracker sheet, mapped all assessments onto it, and began sending the customer a weekly Friday update.

The client loved it. They said it was exactly what they needed but didn't know how to ask for it. A real shift happened in that client relationship. When renewal time came, they specifically requested me as their account manager. 

That moment taught me something that still drives everything I do: customer delight doesn't come from just technical brilliance. It comes from obsessing over every single touchpoint. A Friday tracker sheet is not complicated. But it shows that you're thinking like the customer. It shows you care about making their life easier. That's what gets you real loyalty.

That's a significant pivot—from finding vulnerabilities to managing relationships.

There's a general perception that tech is the interesting part, and anything customer-facing is somehow the boring part. Customers are where the revenue comes from. Customers are where the feedback comes from. It's the most important surface area in the business.

And honestly, there's a high to it that's hard to explain. When a proof-of-concept converts. When a customer says yes. When a Quarterly Business Review (QBR) goes well and they tell you things are working. I still feel that. Every time. It doesn't get old.

At the end of the day, the question I keep coming back to: “Is the customer actually getting value? Is the person on the other side winning?” That's the thing worth caring about.

What did your technical background give you that other program managers didn't have?

Because I came from a pen testing background, I understood things that a normal program manager didn't. If an assessor told me something would take three days, I would question it. I'd say, "Why do you think it takes three days? It's just this, shouldn't it take less time?" Or if they quoted too little time, I'd push back: "But this also involves X, so shouldn't you need more?"

I focused on understanding both sides before making a call. I could negotiate better, push back on things. That became my advantage.

How did you move from program management into the business side?

I realized that even a program manager only gets information once the negotiations are done, once the contract is signed. I wanted to go earlier in the process. So I started helping with scoping engagements: understanding the level of effort, how much we're charging, what margins we're making.

That is when I first started working closely with Sandesh. He was running a lot of accounts at the time and drowning in work. People would constantly come to him asking for more challenging technical work. But nobody ever came and said, "I want to help you on the business side." So when I showed interest in helping Sandesh with the business side, he was genuinely relieved.

I started shadowing him, how he does presales, how he calculates margins, how he runs QBRs. Then I took on small accounts. I recall one customer. It was a small account and we thought they'd buy one pen test a year, nothing more. But I went in, understood their real problems, and then identified additional areas where we could help. That account grew from basically nothing to significant revenue. It exceeded expectations internally.

Over time, the customer started looping me into conversations about his team's internal challenges; things you don't typically bring up with a vendor.  That's when it clicked: I had become a genuine partner, not just a service provider.

What were you looking for in the next phase of your career?

Post-COVID,  life had fundamentally changed. I started seeing a lot of startups working on interesting problems and wanted to be part of that.

CloudSEK gave me hands-on experience managing and balancing global accounts. Then PingSafe, where I built a customer success team from scratch. But honestly, the most important thing happening during all this was that Sandesh and I kept talking. We'd always wanted to build something together, but the timing had to be right.

That timing came in January 2024. 

How do you balance being a founder with life actually happening?

People have this misconception that founders have to be "on" all the time—grinding constantly, no breaks, no life outside the company. I don't believe that at all. And I think if you genuinely have the right team, you don't have to live that way.

The reality is, life doesn't pause because you're a founder. Things happen: family, health, relationships. And there are moments where you simply can't show up at full capacity. That's just being human.

What makes the difference is what you've built around you. If you have the right team, the right co-founder, people who understand the mission and can hold things together. You don't have to be the single point of failure. That's actually good company design.

I also think there's something worth saying about sustainability. Longevity matters. Showing up consistently over years is more valuable than sprinting until you break. Burnout should be the exception, not the norm.

What is it like building a company with an ex-boss turned co-founder?

We're both custodians of something different. Sandesh is the custodian of the technical vision. He writes thoughtfully about app security, he has a newsletter, he's the voice on the technical side. I'm the custodian of the customer. Every decision we make: product design, feature prioritization, even how we support people goes through my filter: what does the customer actually need?

That's not a hierarchical thing. It's complementary. He understands when I need to step back, and I understand when he does. We don't step on each other's territory because we're both clear about what we're protecting.

You're building a team now. What do you look for when you hire?

Every person should find our problem statement interesting. That's the main thing I care about. It's very different from requiring deep AppSec knowledge. Someone can learn the domain in a few months. But if they don't find the problem we're solving genuinely interesting, if they don't care about making security workflows easier and more adaptable, then it doesn't work long-term.

We have team members at very different stages in their careers, an early-career engineer and a highly experienced sales hire working together on the same team. Very different backgrounds, very different experience levels. But both of them care about the problem. They understand that we're not building some generic security tool that forces customers into our way of working. We're solving a real inefficiency in how companies approach app security. Both of them get that, and that's what holds the team together.

What does this mean for how Seezo treats its customers?

Everything I learned about customer success, every lesson from Synopsys, CloudSEK, PingSafe, I've brought into how we run Seezo. When prospects ask what's different about us, I tell them:  You won’t have to navigate layers of support to reach someone who can help. You won't be treated like a ticket number. Any of us, me, Sandesh, the team is accessible. 

And we genuinely care about solving your problem, not about closing your ticket and moving on to the next one.

Our design philosophy is simple: make it as simple as possible to consume Seezo. Fit into how the customer already works. Don't force them to change their processes.

And there's a real reason for that. Organizations don't resist change because they're stubborn. They resist it because their workflows were built over years, often for good reasons. If you introduce a new tool that forces a process change, they don't abandon the old way. They work around your tool, use it in ways you didn't design for, and eventually stop using it altogether.

So we start with a different question: what does the customer's existing workflow look like, and how does Seezo fit into it? That's harder engineering. That's harder product design. But it's the right approach.

That is exactly why Seezo exists.