At RVO Health, documentation had its own place in the backlog. That was the trouble. A feature could ship while its explanation waited. In a customer interview published by Swimm, staff engineer Ryan McKenna described folding the documentation work into the original ticket. The feature was finished only when its explanation was finished too. A small administrative change exposed a larger question: when does a company actually possess the knowledge its engineers have created?
- Swimm links explanations to code so knowledge can keep pace with changes.
- Its current business delivers modernization projects using analysis, AI, and senior engineers.
- The useful habit to copy: make understanding part of the work’s acceptance criteria.
The explanation has an expiry date
McKenna had tried internal documentation efforts before. Developer surveys kept pointing to the same unresolved pain. Putting Swimm inside the code editor reduced the distance between writing software and explaining it. He started with one team; at the time of the interview, seven of roughly fifteen teams were using it. The newer teams proved particularly enthusiastic. A better tool helped, but a manageable rollout and a different definition of completion mattered too.
Swimm’s documentation proposition addresses a peculiar form of waste. An engineer writes a useful explanation. The code changes. The explanation remains perfectly readable, and becomes misleading. A conventional wiki can preserve the sentence without preserving its relationship to the system. Swimm couples documents to code, brings them into the development workflow, and uses Auto-sync and verification to help maintain that relationship. The promise is less glamorous than writing software. It is also rather difficult to fake over time.
RVO Health combined Swimm with Backstage, the developer portal framework. Swimm documents could appear in Backstage’s TechDocs, giving teams a common place to discover knowledge while retaining the code connection underneath. The company’s case study describes benefits for product and business colleagues as well as engineers. A searchable library is useful; a searchable library whose contents still describe the machinery is considerably more useful.
“Knowledge discovery, especially for non-engineers, has improved significantly”
Ryan McKenna · RVO Health
A thousand repositories cannot rely on memory
The problem grows teeth at Recursion, the drug-discovery company. Swimm’s published case describes more than 1,000 active repositories and over 200 developers working alongside scientific disciplines. Knowledge was scattered, unreliable, or absent. People asked Slack for explanations and sometimes recreated solutions. Recursion connected documentation to code changes and incorporated Swimm into tools for starting new projects. That last detail matters: the habit arrived with the project, before documentation could become somebody else’s chore.
Recursion’s estate in Swimm’s published customer story. Scale turns “ask someone” into a fragile operating model.
An unnamed Big Four consulting firm supplies another example. Swimm reports that new joiners working on microservice endpoints went from an estimated fifteen days to independent effectiveness to about half that time. The firm used organized document playlists and an IDE plugin that surfaced relevant material. This is a vendor-published customer result, rather than a universal speed guarantee. Its practical point is straightforward: useful knowledge must be available at the moment an unfamiliar task begins.
Then Swimm took responsibility for the work
Founded in 2019 by Oren Toledano, Gilad Navot, Omer Rosenbaum, and Tom Ahi Dror, Swimm originally tackled knowledge sharing among developers. Its November 2021 Series A raised $27.6 million, led by Insight Partners with Dawn Capital, Pitango First, and TAU Ventures participating. Disclosed funding reached $33.3 million. The funding announcement also introduced an open beta. The early ambition was to make continuous documentation part of ordinary engineering practice.
By May 2026, Toledano was explaining a different commercial proposition. Customers wanted modernization outcomes, but evaluating, procuring, integrating, and rolling out another tool added friction. Every old application had its own conventions and buried rules. Swimm would use its technology and experienced people to do the project itself. The shift is revealing: a company selling better understanding discovered that delivering it required accepting more of the customer’s work.
Its current offerings include API-first architecture, a context layer for AI development, and large migrations. Java and .NET services sit beside mainframe modernization and monolith-to-microservices work. Customers receive changed code or a usable knowledge base, plus the maps, tests, playbooks, and training needed to continue. A live workspace makes the engagement visible. The business now sits between developer tooling and specialist engineering services.
The machine reads. The expert remembers.
Swimm combines three kinds of work. Deterministic analysis maps dependencies and flows from source code. AI helps turn that structure into explanations and apply patterns at scale. Subject-matter experts validate results and contribute knowledge that source files cannot contain. The distinction matters. Code may reveal a condition; it may say little about the commercial negotiation that produced it.
Swimm 2.0, announced in March 2026, lets business users navigate by domain and organize modernization context into collections. Its MCP server exposes validated knowledge to AI agents. This makes Swimm a potential companion to tools such as Claude Code, Cursor, and Copilot. The competitive question becomes whether those tools have enough application-specific context to preserve the behavior that matters.
Buy one stage. Inspect the evidence.
The current service model divides a project into assessment, specification, modernization, and enablement, with a fixed price for each stage. Assessment establishes scope, risks, and success criteria. Specification establishes the behavior to preserve. Execution changes the system; enablement hands it back. Separately, Swimm’s platform pricing page describes pricing by lines of code and proof-of-concept options. Buyers need a scoped proposal to establish the actual bill.
This approach depends on access to the relevant code, available organizational expertise, and serious validation. A tidy dependency map cannot supply an unwritten policy by itself. Swimm advertises on-premise and air-gapped deployment and customer-managed language models for sensitive environments. For teams that only need a simple README, the service machinery may exceed the problem. For a complex application, the useful question is whether the next engineer can explain what must survive before changing it.