Self-evolving SaaS builds half a factory

A reel came past on Instagram that occupied me longer than it deserved. Two founders are standing at a Y Combinator hackathon in San Francisco, day two, making a prediction. The caption underneath was selling a product, so I ignored it. The spoken part turned out to be a different story, which is why I pulled the audio and had it transcribed.

One of them says: “we figured out how to automate the code creation and the implementation part.” What is missing, in his view, is no longer how you build but what you should build. His prediction for the coming year is software that moves with each user. If a customer keeps reaching for one feature, the system builds on it, and someone else ends up looking at a different interface. As evidence he mentions a company that got into Y Combinator with a landing page that reshapes itself around the visitor, so a dentist reads different copy than a plumber.

My first reaction was that I had met this idea before. Build one product, wrap a shell around it per customer, switch features on and off. That is multi-tenant SaaS with feature flags, and it has been standard practice for twenty years. Yet something in the prediction is genuinely new, and it concerns who writes the code.

Four levels that keep getting conflated

To judge what a vendor is actually promising, it helps to separate four levels. They differ on one question, which is who writes the functionality and where it ends up.

Level 1 is daily practice at any SaaS company. The serious stories end at level 2. Most app builders sit at level 3, while their marketing implies level 4.

The cleanest example of level 2 comes out of Y Combinator’s own summer batch. Vendo lets users build their own features and micro-apps inside someone else’s product, on the existing API and inside the existing guardrails. The decisive sentence sits in their own launch post: the agent only ever gets the access the logged-in user already has, and the source code is never touched. Everything runs in a sandbox. That is the only version of this you can sell to a company that has customers of its own.

Y Combinator is also asking for this direction explicitly, in the Summer 2026 Requests for Startups, under the heading “Dynamic Software Interfaces”. Ankit Gupta writes there that coding agents have become good enough to let users act as their own forward deployed engineers, with the example of an email client that looks like a task list to him and like an events calendar to a student. Underneath, both interfaces share primitives that the software team builds and ships.

What struck me is where that text stops. Gupta raises the follow-up questions himself, as open problems: would a developer have to ship source code instead of a packaged binary, and should users be able to change only visual elements or the middleware as well. Even the party funding this thesis keeps it at the interface and puts a question mark on anything deeper in the stack.

What I verified myself

One project shows up in the research I commissioned as proof that level 4 exists: Neo.mjs, a JavaScript framework that calls itself a self-evolving software organism. I queried the GitHub API rather than trusting the website. In June 2026 the repository merged 978 pull requests, in May 736. The contributor list holds the maintainer plus a series of bot accounts, one per model, named after different vendors. So the numbers hold up, and the arrangement where competing models review each other’s code is real.

There is one problem. It is a framework, not a SaaS with customers. There are no tenants, so there is no per-customer functionality and no feedback path. A repository that rebuilds itself is not the same thing as a product that rebuilds itself per customer. Treating the first as evidence for the second skips the step the entire promise rests on.

Half a factory

Picture the model as a factory with small satellite factories around it. Every customer gets one, with features switched on or off. You watch what a customer actually uses, build that out, wrap a different shell around it. And whatever proves itself there travels back into the main factory, so the next customer inherits it.

That last step is the one I could not find anywhere. Not with the vendors claiming level 4, not at Vendo, not in the Requests for Startups, not in the papers. Everyone ships the outbound journey, which runs from the shared product to something shaped for this one customer. Nobody ships the return leg, where a feature that earned its place with one customer gets promoted into the shared product.

Without that return leg this works like a photocopier. Every customer receives a version that then drifts in its own direction. The pattern has a name in software product line research, where it has been studied since the nineties: clone-and-own. Copying is cheap and fast, and the invoice arrives later, when every security patch and every migration has to land in dozens of diverged versions.

A paper by Xhevahire Tërnava from June 2026 examined ten projects written entirely by a language model. She found almost no variability inside the code, and no configuration options. Every choice is resolved the moment the model produces the source. She draws a different conclusion from it than I expected. Instead of calling it a defect to be repaired, she proposes treating it as an approach in its own right, with the model as the derivation engine and a dispatcher routing users to the matching build. That is a proposal rather than an indictment, and it is fairer than my own first reading of it.

What it does not solve is that you then maintain hundreds of builds instead of one product. A factory with a return leg needs a single shared codebase where an improvement can actually land.

The caveat

Three things shift quietly here, and they deserve naming before anyone starts building.

The standard moves from “what is good” to “what gets clicked”. When usage signals decide which features get built out, whatever is touched often will grow and the rest withers. That is exactly where the rarely used and still necessary things live: the accessible route and the screen that handles the difficult application.

Accountability lands somewhere that was not designed to hold it. At levels 1 and 2 you can reconstruct who approved a change. Once an agent edits shared code, somebody has to explain why that line is there, including a year later in front of an auditor. The change management requirements in ISO 27001 and SOC 2 assume a human requester and a human reviewer.

What drains away from the user is the ability to recognise the product. If my screen differs from my colleague’s, they can no longer help me, support cannot look over my shoulder, and the documentation is no longer true. That is a real cost that never appears in a demo.

What I do myself

I stay at levels 1 and 2, and I say out loud why. What I build with agents generates configuration, copy and screens inside a codebase I own and read. The agents in my own publishing pipeline do write code, but every change passes automated checks I wrote myself, and then passes me. For anything that touches customers I would want to see the return leg working before automating the outbound one.

And for any vendor putting “self-evolving” on their website, I now have one question: show me how a feature that works for one customer reaches everyone else’s product. If the answer is a demo rather than a changelog, this is level 3 wearing a more expensive name.

Frequently asked questions

Is self-evolving SaaS the same thing as feature flags?

No, although the promises rhyme. With feature flags the functionality already exists and a setting decides per customer what is switched on. With self-evolving software, new functionality would come into being without a developer having written it. The difference is whether anyone has seen the code.

What does the “return leg” actually mean here?

That a feature built for one customer, which works well there, gets absorbed into the shared product so other customers receive it too. Without that step every adjustment produces a separate version to maintain. With it, every customer becomes a source of improvement for the rest.

Can I deploy this safely today?

At levels 1 and 2, yes, because generated output never reaches the source code and the blast radius stays inside an application you tested yourself. For levels 3 and 4 I would first want to know how a bad change gets rolled back for one customer without disturbing the others. I have not seen a working example of that.

Sources

• Instagram, reel by sorhan.hq on self-evolving SaaS, posted 26 April 2026. Audio transcribed by me on 21 August 2026.
• Y Combinator, Requests for Startups, Summer 2026, “Dynamic Software Interfaces” by Ankit Gupta. Accessed 21 August 2026.
• Y Combinator, company page and launch post for Vendo (S26). Accessed 21 August 2026.
• GitHub API, repository neomjs/neo, counts of merged pull requests for May and June 2026 and the contributor list. Retrieved 21 August 2026.
• Xhevahire Tërnava, “Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration”, arXiv:2606.19042, submitted 17 June 2026.
• Liyi Cai, Yijie Ren, Yitong Zhang and Jia Li, “AI-Driven Self-Evolving Software: A Promising Path Toward Software Automation”, arXiv:2510.00591, submitted 1 October 2025.

Checked on 21 August 2026. The transcript of the reel, the Requests for Startups text, the Vendo launch post and the GitHub API figures I retrieved and read myself. Both papers I read at abstract level rather than in full; the description of Tërnava’s proposal comes from the author’s own summary. The claim that no feedback mechanism exists anywhere is a claim about absence, and therefore weaker than the rest: I did not find it in the sources above, nor in two extensive research reports I commissioned, but absent evidence is not evidence of absence. If you have a working example, I would like to see it.