Background & Origins
How did you end up building a red team company if your role leans backend engineering? RTA needed real infrastructure to be credible: a bounty aggregator, a CTF platform, an Academy with hands-on practice environments, admin tooling. Someone had to build that side while the offensive-security work happened. I gravitated toward being that person, the security company needed a foundation as solid as the expertise it was selling.
What’s your technical background, and how did backend engineering lead you into cybersecurity? Java/Spring Boot and Rust on the backend, comfortable across the infra stack: Kubernetes, Docker, CI/CD, identity systems. Cybersecurity wasn’t the starting point; building systems that have to hold up under real adversarial attention was. A red team company is one of the few places where your own backend’s security isn’t optional, it’s the product’s credibility.
What was the moment you and your co-founders decided to actually start RTA? There wasn’t a single spark, it came out of a presentation we’d been developing for a long time. That process forced us to actually define what we’d need technically and operationally to make this real, not just talk about it in the abstract. Once we had that plan, we started executing incrementally, a little more of the actual build each day, rather than waiting for some perfect starting point.
How did your time at 42 Tirana shape the way you approach backend work today? 42’s project-based, no-lecture model rewards figuring things out under real constraints rather than memorizing answers, that’s basically every debugging session in this project: work the problem methodically, verify each layer instead of guessing, don’t assume the first plausible explanation is the right one.
Role at RTA
What exactly are you building and maintaining for RTA? The full backend: a Spring Boot gateway (auth, admin panel, public-facing forms) fronting a Rust service that handles fast data processing and scraping. Bounty aggregation across three real platforms, CTF event infrastructure, the Academy’s practice-environment pipeline, and now the identity system tying it all together.
How is backend engineering different when the product is a security company rather than a typical SaaS business? The people using your product are trained to find what you missed. A misconfigured permission or a forgotten firewall rule isn’t just a bug, it’s the exact class of thing RTA’s own clients get hired to find. That raises the bar on things a normal SaaS team might deprioritize: least-privilege scoping, content filtering, session isolation.
What’s the tech stack behind RTA’s platform, and why did you choose it? Java/Spring Boot for the security-and-auth-facing gateway: mature ecosystem, strong typing, Spring Security genuinely earns its reputation. Rust for the data-processing side: fast, memory-safe, good fit for concurrent scraping. Postgres (via Supabase) for persistence, Redis for caching/rate-limiting, Kubernetes with Argo Rollouts for deployment, and Keycloak for identity, chosen specifically so we’re not the ones responsible for getting password storage and auth security right from scratch.
Building the Infrastructure
How much of the CTF/Academy infrastructure did you build yourself? Essentially all of it, end to end: the bounty scrapers, the CTF event pipeline, and, most recently, the full Academy practice-environment stack. That last piece meant integrating Kasm Workspaces (isolated, disposable VM sessions) with Keycloak (identity) and the Java gateway, including dynamic per-user provisioning, session quotas, and hardening so a training environment can’t be abused.
What’s been the hardest technical problem you’ve had to solve? Genuinely, the Kasm to Keycloak integration. It surfaced a real, obscure bug: the JVM defaulted to resolving localhost over IPv4 while curl defaulted to IPv6, silently routing identical requests to two different backends, which looked like nothing was working for most of a session before the actual cause became visible. That, plus deploying Keycloak to a real production server from scratch: Docker networking fundamentals, Traefik/DockerAPI version incompatibilities, a multi-layer cloud firewall (OS-level and cloud-level, on two different VCNs at one point), every layer of a real production deployment, debugged one at a time.
Security companies are high-stakes environments to write code for, how does that change your approach? It means declining shortcuts that would work fine elsewhere. When a scraper hit a platform actively defended by Cloudflare’s bot protection, the tempting move was a headless-browser bypass: technically doable, but that’s deliberately defeating an anti-automation control, not just finding an unlocked side door. We didn’t build it. Same instinct applies to how user data and session isolation get handled in the Academy environment.
How do you handle the tension between shipping fast and holding your own code to security standards? By being explicit about what’s temporary. Local development uses dev-only shortcuts: a trust-all SSL bypass, relaxed env vars, clearly commented and tracked on a running checklist, with a hard rule that none of it goes near production untouched. Speed comes from not re-litigating settled decisions; safety comes from never letting “it works locally” quietly become “it’s fine in prod.”
Team & Culture
What’s it like being the engineer among co-founders from an offensive-security background? It’s genuinely one of the better parts of this. My co-founders are direct and communicative, which means the collaboration works both ways, I bring the engineering discipline, and I’ve picked up real offensive-security intuition from them in return. It’s made me a more well-rounded engineer than I’d be building this alone.
How do you and Orgito divide responsibilities day to day? We stay in sync daily, on the technology choices, the methodology, and whatever’s changed since the last conversation. Before any responsibility gets built out, we’ve already talked through it in enough detail that there’s no ambiguity about who owns what or why we’re doing it that way.
What does a backend engineer bring to a red team company that a purely offensive-focused team might miss? The discipline of building things that are correct and maintainable, not just clever. Offensive security is about finding the one flaw; backend engineering at this level is about not leaving one. Those are different mindsets, and a red team company genuinely benefits from having both in the room.
The Bigger Picture
RTA launches September 1st, what has the lead-up looked like from your side? Compressed and real. The Academy’s practice-environment pipeline, login, identity, per-user disposable VMs, session hardening, went from an idea to a fully working, production-deployed system in a handful of sessions, alongside migrating to canary deployments so future changes ship safely under real traffic. A lot of it was genuine infrastructure debugging, not feature-building, the unglamorous work that has to be right before launch.
Where do you see RTA’s technical infrastructure a year from now? Fully on Keycloak for identity across the whole platform, not just Academy, real auto-scaling for practice environments instead of a single fixed server, and canary deployments as the default way anything ships, not a novelty we just adopted.
What advice would you give to other engineers in the Balkans who want to build products, not just work for companies elsewhere? Build the boring infrastructure. Anyone can prototype a feature; fewer people will sit through a multi-hour firewall-and-DNS debugging session to get a real deployment working end to end. That patience is the actual differentiator between a demo and a product.
What’s one thing about running a startup that surprised you, coming from a pure engineering mindset? How much of “engineering” turns out to be resource-constrained decision-making, not writing code, deciding whether a free-tier VM is good enough for now, whether to scale down one service to afford another, when a workaround is genuinely fine versus a real risk to revisit later.
Any final thoughts on what makes RTA’s engineering culture different from what people might expect? We don’t treat “it works” as the finish line. A feature isn’t done until we’ve asked what happens when it’s attacked, misconfigured, or under real load, and we’re willing to decline a shortcut (like bypassing a platform’s bot protection) even when it would save time, because that’s exactly the standard we’re asking our clients to hold themselves to.