rootpath.studio needed infrastructure that matched its open-source values. We replaced their full SaaS stack — files, email, communication, and design — with tools they own outright. Here is what the migration involved and what changed.
Most businesses don't choose their SaaS stack. They accumulate it. One tool at a time, over years, until one day you add up the invoices and realise you're paying four different companies — every single month — for access to tools your business depends on entirely. Tools you don't own. On pricing you can't control. With terms that can change without asking you.
For most teams the question is eventually about cost. For rootpath.studio, it was about something more uncomfortable than that.
The client
rootpath.studio is a co-creative studio founded by Esaú Gozalo. The work is built around helping small teams cultivate brand identity and creative capacity — specifically through systems and business models that don't extract value from the people they serve.
The problem Esaú came to us with wasn't hard to state. A studio that helps clients build ethical, values-aligned brands while running on infrastructure it doesn't own, can't inspect, and pays for on someone else's schedule — that's a contradiction. Not a theoretical one. A live one, every day.
The infrastructure needed to match the practice.
What we replaced
The studio was running a standard set of SaaS tools: cloud-based file storage, third-party business email, a proprietary design platform, a communication tool that kept all conversation history on servers it had no control over.
None of it was broken. All of it was owned by someone else.
What we deployed
We built a full self-hosted stack on a single VPS that rootpath.studio owns and controls directly. Everything runs on one server, configured to work together — not five separate installs that happen to share a billing address.
Nextcloud with OnlyOffice handles files and documents. Client project folders live in Nextcloud, shared through access-controlled links. Clients edit directly in the browser. The studio's files sit on a server it owns.
Mailcow handles business email. Full control over the mail server, email authentication, delivery. Esaú's Matrix address is now publicly listed on the studio's website — clients can reach him directly through infrastructure the studio runs.
Matrix with Element handles communication. End-to-end encryption on by default. Conversation history the studio keeps on its own terms, not subject to a platform's retention decisions.
Penpot handles design and prototyping. The full design workflow on the studio's own server. Open-source, self-hosted, entirely owned.
Automated backups, uptime monitoring, and environment documentation were in place before any of the old systems were switched off.
How the migration actually went
Both systems ran in parallel for two weeks. The studio used the new infrastructure for everything — email, files, design work, client communication — while the old systems stayed live as a fallback.
We didn't touch the old systems until the studio's team had gone through every workflow and confirmed it worked. The final cutover was quiet: DNS records updated, subscriptions cancelled, done.
Three weeks total from the first assessment call to go-live.
What changed
The tools work. Clients use them without friction. The monthly per-seat costs for four separate platforms are gone, replaced by a fixed server cost that doesn't move when the studio adds a team member or a new client.
Esaú put it better than I can:
"What stood out wasn't just the technical execution. It was the care taken to understand how we actually work with clients before recommending anything. Our infrastructure now genuinely reflects how we work: open, collaborative, and fully ours."
That's the thing that's hard to put on a pricing page. Understanding how someone actually works before recommending anything. It's also the thing that made this migration succeed where others fail — we weren't fitting rootpath.studio into a standard deployment template. We were understanding what they needed and building for that.
Why I'm writing this
Not every team comes to us because of cost. Some do — and the savings are real and significant. But some teams, like rootpath.studio, come because their infrastructure doesn't reflect what they stand for. That's a different kind of problem. It's also a more interesting one to solve.
If that second description sounds familiar — the full case study shows what the process looks like from the inside. Or if you'd rather talk through your specific situation directly, the assessment call is the right place to start.