Why Mend.io. Why now.

Why Mend.io. Why now.
A couple of days ago I said more was coming. Here it is.

The last year changed how I think about software. Building at Tricentis, building on my own at nights and weekends, watching the models get better release over release, I felt the shift in my own hands before I could name it.

Vibe coding stopped being a novelty. The Full Stack PM stopped being a slide. I was shipping things I would have specced and handed off a year earlier.
And I was not alone. The builders are everywhere now. More code was written this past year than in any year in history, and the line is still bending up.

The pipeline did not just get faster. It changed shape. And every line of that code still has to be trusted.

That is the part the market is only starting to feel. For two decades the question was how fast we could build. AI answered it. What is left is harder: can you trust what just got built, at the speed it now ships. That is a verification problem, and verification is not the same discipline as generation. It is what Mend has been doing since day one.

Three things made the decision for me.

Independence. The model that writes the code cannot be the one that clears it. A more capable model is not a more independent one. Trust has always come from a second, independent set of eyes, and in the agentic era that eye has to sit outside the lab that generated the code.

The data. Mend scans across thousands of enterprise codebases, which produces something no frontier lab or standalone startup can replicate: real-world intelligence about what actually breaks and what it takes to fix it, per codebase, over time. That is the asset. The install base and Renovate compound on top of it.

The timing. The category is forming right now, and the window to define it is months, not years.

I spent the year as one of the builders growing the pipeline. Mend is where that same shift gets met on the other side: making all that code safe to ship at the speed it now arrives.

That is what I came to do.