Co-founded a security startup and built its scanner

I co-founded Crashtest Security and led development of a fully automated security scanner for web applications, JavaScript apps, and APIs. I was there from the first commit onward: five and a half years, from three founders in a GbR to a GmbH with a product and paying customers. I left at the end of 2020; Veracode acquired the company two years later.

The problem we were solving

Dynamic application security testing was, at the time, something you bought as a consulting engagement. You hired a pentester, waited weeks, received a PDF, and by the time you had read it your application had moved on. That model priced out exactly the teams who needed it most: small and mid-sized engineering teams shipping continuously, with no security specialist on staff and no budget for a retainer.

Our bet was that the majority of what a pentester finds on a first pass is findable by a machine, repeatedly, on every deploy - and that the value was not in the depth of a single audit but in the continuity of many. That reframes the product from a report into a pipeline step.

The constraints that shaped it

Three things constrained every technical decision.

We were scanning systems we did not control. A DAST scanner is, mechanically, an attacker. It has to authenticate against someone else’s application, crawl it without destroying data, and probe it without taking it down. Being wrong here does not produce a bad result, it produces an incident on a customer’s production system.

Scan load is spiky and unpredictable. A scan is minutes to hours of concurrent, network-bound work, and demand arrives in bursts tied to customers’ own deploy schedules. Provisioning for peak would have been ruinous for a startup; provisioning for average would have meant queues.

We were a small team building both a product and a company. I was writing code, hiring the people who would write more of it, and out at conferences explaining why any of it mattered. Anything that needed constant hand-holding was not affordable.

Decisions and tradeoffs

I designed the system as microservices on Kubernetes, which was the direct answer to the load-shape problem: scanner workers scale independently of the control plane and the web application, and a burst of scans does not degrade the dashboard for everyone else. The tradeoff was real - we took on cluster operations very early, and I owned that infrastructure personally rather than hiring for it. For a team our size that was a deliberate concentration of risk, justified because scan isolation was a product requirement and not an optimization.

Go for the scanning path, PHP for the product surface. The scanner is concurrent, network-bound work where goroutines map cleanly onto the problem and a static binary is trivial to ship into a container. The customer-facing application is CRUD, billing, and reporting, where PHP’s ecosystem and our own velocity mattered more than raw throughput. Splitting languages by workload rather than standardizing on one cost us some context-switching and meant hiring for two skill sets - worth it, because the alternative was writing a concurrent scanner in the wrong tool.

I owned the payment flows directly. In a self-serve security product, billing is not a back-office concern: it gates scan quotas, it is where trials convert, and getting it wrong is both a revenue and a trust problem. I kept it close rather than delegating it early.

Building the team

I built and managed the backend team from nothing. What I learned there has shaped how I have led every team since: in a startup, hiring is not a recruitment activity you do in parallel with the work, it is the work, and every hire either widens or narrows the set of problems the company can take on. I hired for judgment about risk over familiarity with our stack, because the stack is teachable and judgment about breaking production is not.

I also represented the product publicly - conference talks and hands-on workshops on web security, pentest automation, and DevSecOps, including at Daho.am, the DATEV Agile Security Konferenz, and International PHP Conference. Teaching people to attack their own applications turned out to be the most honest form of marketing we had, and it made the engineering better: you cannot run a workshop on a rough edge without wanting to file the rough edge down.

Outcome

I left at the end of 2020, two years before the exit. The company was acquired by Veracode in 2022, extending Veracode’s dynamic analysis capabilities with the technology we had built. The scanner went from a prototype to a product a public application-security company chose to buy rather than rebuild.

What I would do differently

I treated everything outside engineering as the tax you pay for getting to build. It was closer to half the job. Investor expectations, sales cycles that ran twelve months and longer, customers who wanted the product and never got the budget signed off for it: none of that was adjacent to the product. It set the conditions the product had to survive in, and I engaged with it later than I should have.

The pattern worth taking seriously is the one that cost us the most. Engineers liked the scanner and engineers rarely sign. Above them sat managers being asked to spend on a promise - security work whose payoff is an incident that does not happen - against budget lines that could buy something with visible results this quarter. Deals died a week before signature after a year of work, and not because the product had failed the evaluation.

So I would have let that shape the engineering, not just the pitch. Optimising for the first hour of a trial and for what a champion can carry upstairs - evidence a budget holder can act on without understanding DAST - is worth more in that market than the depth a security engineer appreciates. And I would have stopped treating the commercial cycle as an interruption to the roadmap. In a startup it is an input to it.