This interview features Émile Fugulin, co-founder of Caido — a security auditing toolkit built for the hacker community. Rust powers the core of the Caido platform, from the backend to the desktop app. Émile shares how Caido has grown in recent years, with Rust + SeaQL essential to the product’s evolution. He also emphasized the team’s commitment to bootstrapping and building the company sustainably.

---

From Bug Bounty Hunting to building Caido​

Chris: How did you and your co‑founder come together to start Caido? I’ve known you for quite a while, I still remember you being one of the first contributors to SeaQuery, and we’ve interacted quite a bit in the past.

Émile: Caido is a reverse proxy built for security engineers, penetration testers, and bug bounty hunters. It’s designed for people testing web applications to find vulnerabilities, then producing reports or earning bounties through platforms like HackerOne, Bugcrowd, or Intigriti.

The idea came from my co‑founder Ian Bouchard who had been a bug bounty hunter for about eight years. He’s a good friend from high school, we stayed in touch throughout our university years.

In mid‑2021, Ian shared his idea for building this product. He wanted to move beyond bug bounty hunting, so we started working on it that summer.

Chris: That’s interesting. I’ve never known anyone who makes a living from bug bounty hunting.

Émile: Yeah, bug bounty hunting is a peculiar world. Many people try it because you don’t need a traditional job or formal qualifications. You can just start testing websites and get paid for the vulnerabilities you find. It’s fun and compelling, but it’s also not easy.

Committed to a Self‑Sustaining Path​

Chris: When did you decide to go full‑time with it?

Émile: We said to ourselves in early 2022: “Okay, we’re going to go full‑time on this and aim to have something within a year.” However soon we realized it would take more than a year to get the product out and generate enough revenue to sustain ourselves.

So I went back to doing some contracting to stay afloat, on top of working full‑time on Caido.

Chris: I saw you guys had decided to bootstrap — what’s the reason behind it?

Émile: Yeah, there are a few reasons. We did try at the beginning to see if we could raise, but I think we were a bit young and naive. It was also a strange time, in 2021 the VC activity was at its peak, with zero‑interest rate money funding almost anything. AI hadn’t taken off yet, so you could get funding for all sorts of projects. We realized it wasn’t a good fit for us, since our market is quite niche.

In the long run, I think it was the right decision not to raise. It gave us the time to focus on the product for a couple of years without the pressure of chasing growth. It hasn’t been easy — it’s definitely not the easiest path — but if you can do it, it’s a good one. You keep full control over your business, with nothing pushing you in a direction you don’t want to go.

Caido: Postman for Security Testing​

Chris: You’re happy with Caido right now, right? If it continues on this trajectory, what’s your vision for it?

Émile: Yes, I am happy with where we are today. Right now we’re very much in the penetration testing world, focused on security professionals. But we want to expand beyond that: to managers, with features around scheduling, report building, and workflow support.

On the developer side, we also want to make these tools easier to use directly. We could ask AI to operate advanced tools and explain the results, even if you don’t fully understand the technical details of the vulnerabilities.

We’ll remain a security‑focused company, but the goal is to empower developers and reduce friction between security and engineering teams. Right now, a lot of productivity is lost when security folks try to explain how a vulnerability is reproducible, or when developers claim they’ve fixed something but the patch is incomplete. This communication gap is a real problem we want to solve.

Chris: To me it sounds like Postman for security testing?

Émile: Yes, exactly.

Chris: Can you give me an example of how Caido is designed to catch bugs?

Émile: At its core, Caido works by intercepting the traffic between you and a server. Once you capture that traffic, you can replay requests, modify them, and see how the application responds.

One of our key tools is called Replay. For example, you might change a request from ID=1 to ID=2 and check if you still get access to data you shouldn’t. That’s a classic “Insecure Direct Object Reference” vulnerability, where the system fails to verify permissions properly.

We also provide brute‑force tools, where you can test common passwords against a login page to see if any match. Beyond that, Caido has plugins for many things including SQL injection testing, a GraphQL analyzer to exploit recursive queries, and a scanner that detects exposed sensitive files.

The goal isn’t to “auto‑hack” a site with one click, but to give security practitioners the right set of tools, much like Postman does for API developers, to perform their work more efficiently.

From Learning Rust to Building a Platform​

Chris: So when Caido started, were you all familiar with Rust? Did you decide from the beginning to build everything in Rust?

Émile: No, actually none of us were familiar with Rust at the start. When I joined, the project was already in Rust — the team had heard it was a cool language and just went with it. For me, it took about four months to really ramp up my Rust skills. I came from a C++ and Golang background, so I had some reference points, but it was still a big learning curve.

Rust is approachable, but the error messages can be tough, especially when I was working with Diesel early on. For someone new to Rust, it can feel daunting to figure out why something doesn’t compile. That’s what drew me toward SeaQuery.

Chris: The Caido platform has many components: there’s a web app and a desktop app. Is it all built in Rust?

Émile: The back end, which includes the proxy, business logic, and protocol interception, is all written in Rust. That’s the core engine of Caido.

The front end, whether it runs in a browser or as a desktop app, is built with Vue.js. For performance‑critical parts, we compile Rust to WebAssembly and integrate it into the front end. We then package the back end and front end together as an application.

Originally, the desktop app was shipped with Tauri, but we switched to Electron a year ago to simplify QA. If Tauri adds a bundled browser engine we’d like to switch back. On the cloud side, the setup is similar: Rust powers the back end, while Vue.js handles the front end.

Chris: How many people work on the Rust codebase? What’s the most difficult part of onboarding new developers to a Rust project?

Émile: We have four developers on it now, including our intern. We’ve gotten better at onboarding, and it depends on someone’s background. Developers coming from C++ usually adapt more easily, since concepts like smart pointers and destructors feel familiar. For those from Golang or TypeScript, lifetimes and ownership can be harder to grasp. We also rely heavily on trait‑based interfaces, which can feel intimidating at first. But once that clicks, people ramp up quickly.

Use of Postgres, SQLite and SeaQL​

Chris: On the data engineering side, I know you use SQLite and Postgres. Do you also use Redis?

Émile: Yes. In the cloud we use Postgres and Redis, while on the desktop app we rely only on SQLite. We actually push SQLite quite far, even building custom extensions to add new syntax. Redis is used as a pub/sub system for events. Since we don’t need events to be persistent, it’s fine if some are occasionally missed.

Chris: How are SeaQuery and SeaORM used in the stack?

Émile: In the desktop application we use SeaQuery for dynamic database queries. We built our own DSL called HTTPQL, a query language for HTTP that lets you filter on different criteria. We parse HTTPQL with Pest into an AST, then transform that AST into SQL using SeaQuery, which is executed against SQLite. That’s how we bridge high-level domain-specific queries into actual database operations. We also use SeaQuery for building CTE queries, which are not supported by Diesel.

Some developers prefer writing raw SQL, but I prefer using a query builder because it scales better and provides safeguards through the type system.

Émile: On the cloud side we use SeaORM, and occasionally SeaQuery when needed. It’s been a very solid stack: reliable, flexible, and not difficult to update. There haven’t been any breaking changes that forced us to rewrite code, which I really appreciate.

SeaQuery integrates well with SeaORM, and I’ve never felt limited by the abstractions. As for SeaORM itself, it just works — and that’s exactly what you want from your database layer.

Supporting Open Source and Hacker Culture​

Chris: Caido has been a supporter of SeaQL early on. Thank you so much for that. I know you also sponsor other open source projects?

Émile: For me, sponsoring open source is very important. My goal is to dedicate around 1% of our revenue to sponsorships, that’s the target we’re slowly getting to. The principle is simple: we sponsor the tools we use. If every company contributes even a small amount, it would add up to something significant. Supporting the major creators of the stack, and especially niche libraries that might otherwise be overlooked, makes a huge difference.

Émile: We sponsor many of the key projects we rely on, including SeaQL. I believe more companies should do the same. For larger organizations, the amounts involved are tiny compared to their budgets, but the real hurdle is cultural. Sponsorship often isn’t part of the procurement process, so allocating a budget for it can be difficult. And that’s frustrating, because if you had to pay engineering hours to work around bugs or missing features in those libraries, it would cost far more than simply sponsoring the creators of the libraries.

Chris: I also see that your company is sponsoring hacker events.

Émile: We try to sponsor a lot of hacker events, usually by giving out licenses to our software. Our approach has always been bottom‑up: supporting the community as much as we can is important to us. For example, our software has been fully free for students for about two years now, and we’ve kept that promise. We want students to have access during their school years, and of course there’s a long‑term benefit: when they move into enterprise roles, they’ll already be familiar with Caido and hopefully encourage their teams to adopt it.

Émile: As we grow, I hope we’ll be able to contribute even more: not just through licenses, but monetarily as well.

I see hacker culture as very similar to open source culture. Both are about tinkering, sharing knowledge, and working in a horizontal, merit‑based way. If your work is good, that’s what wins. I really like that mentality, and I enjoy being part of it by supporting the community.

---

That brings us to the end of our conversation. A huge thanks to Émile for sharing his insights. We hope the open source and hacker communities continue to thrive.

If you’re a startup building with Rust, we’d love to interview you and share your story. Contact us on hello(at)sea-ql.org.