Sai Teja Mutchi
Before Ziek, I spent three years building enterprise software at Dassault Systèmes, working across APIs, automated regression testing, CI/CD, production debugging, and major software releases for products deployed to more than 50,000 licensed users.
Today I build production AI systems in a regulated enterprise environment, where changes have to survive retrieval pipelines, distributed services, evaluations, regression checks, and deployment gates before they can be trusted in production.
Why I'm building Ziek
Across both worlds, the pattern is the same: software has become extraordinarily good at producing code, but changes between systems still propagate through documentation, release notes, tickets, and engineers manually reconstructing what an upstream change means for their code.
That is the problem I'm exploring with Ziek.
Ziek is building toward a change-distribution layer for software: understand what changed upstream, determine which downstream code is actually affected, establish the right action, verify it against the current codebase, and deliver a reviewable fix.
This problem is also part of Y Combinator's Fall 2026 Requests for Startups under Self-Maintaining APIs.
Talk to me
If you're building APIs, maintaining developer infrastructure, or dealing with downstream software changes, I'd like to hear how you handle them today.