Swimm is becoming a service company. From Software as a Service to Service as Software.
Here’s why. The pace of AI has turned long-term tool decisions into a moving target. The model that looks right today might be middle of the pack in six months. The framework that wins this quarter might be deprecated next year. In this environment, committing confidently to a tool for a multi-year modernization project is a hard ask.
But we kept hearing the same thing from customers. They desperately need the outcome. And fast. The path to it, evaluating yet another tool, getting it through procurement, integrating it, aligning the org around it, has become slower and slower. We have the technology and the people to deliver that outcome ourselves, without the friction. So that’s what we’re doing.
The cost of waiting
While buyers stay stuck on the tooling question, the underlying problem gets more urgent every quarter. A million-plus lines of legacy code that nobody fully understands is not a problem that waits.
We’ve decided to stop adding to that pile of decisions and start solving the actual problem.
Why services, specifically for this work
Modernization is a project problem at heart. Every legacy codebase is its own animal, with its own history, its own undocumented business logic, its own conventions, and its own list of people who left the company five years ago.
Software is good at consistent problems. Modernization is the opposite of consistent. The “right” approach varies by stack, by industry, by codebase age, by what the team actually has time for. No platform fixes that on its own. People with deep experience do.
That’s why we’re betting on a service model. The unit of value is the project, not the seat.
What we’re doing
For years, Swimm has worked in the deep end of enterprise software modernization. We built a technology that combines proprietary static analysis, LLMs, and heuristics to extract business logic from large legacy codebases as accurately as possible. That extraction is the critical first step in any modernization project, and it’s where most projects die.
We’re now using that technology ourselves to deliver modernization end to end. Discovery, planning, execution, handoff. The deliverable is the outcome.
That means we own the mess: the dozens of tools, the integration work, the legacy quirks, the team coordination. If the modernization works, that’s the win. If it doesn’t, that’s on us.
The team behind it
Our differentiator is the combination. Static analysis and LLMs handle the parts of the work that scale. Senior engineers who specialize in legacy systems handle the parts that don’t. They’ve spent careers inside the codebases the rest of the industry avoids: large, old, sparsely documented, business-critical.
Technology and experienced humans, working on the same project. That’s the model.
Why now
Two market signals worth pointing at.
First, OpenAI and Anthropic both recently announced services arms to help enterprises implement AI. When the foundation-model companies are standing up services teams, that tells you where the value is moving.
Second, Sequoia recently published a number worth sitting with: for every dollar enterprises spend on AI product, six go to services. That’s the real market for delivery, not tools.
We’re not alone in seeing it.
If you’re modernizing
If you’re modernizing Java, .NET, or another legacy stack. If you want to make your product AI-ready or headless. If you want to move your engineering org toward agentic workflows without throwing out your existing code.
Let’s talk.
