get in touch
Late last year, CloudVane’s Platform Architect started a pilot. He used Claude Code for his CloudVane work on a personal Claude Max plan. The rest of the team used AI tools only lightly, each in their own way, with no shared rules or guardrails.
In September, we helped CloudVane turn that one-person pilot into a shared team setup on the Claude Team plan. Seven weeks later, the four developers who got Claude through the Team plan were merging 2.2 times as many merge requests a week as before.
CloudVane is a startup based in Zagreb, Croatia, and a spin-out of Neos. Its platform, also called CloudVane, helps organisations see and manage their multicloud spend by pulling in cost and usage data from AWS, Azure, Google Cloud and Oracle Cloud. Behind it sit about twenty repositories: an Angular frontend, a Java backend, Python data pipelines on Apache Airflow, forecasting and anomaly-detection services, an Oracle database layer and Kubernetes clusters run with Flux GitOps. A small team of developers and a business analyst look after all of it.
Every developer works across several of these systems, and much of the operational know-how sat with one or two people: how a change reaches production, how to triage a failing pipeline or a Sentry alert, what is safe to touch on a production cluster. Since July, the team has shrunk by three people. The roadmap hasn’t.
Claude Code suited this kind of work. It runs in the terminal, next to the tools the team already uses – self-hosted GitLab, kubectl, Flux, the OCI CLI and the Oracle database – and connects to Jira, Sentry and the browser through MCP. In the pilot, it handled whole tasks across the stack, from backend and frontend changes to CI failures and Kubernetes incidents. What a personal plan couldn’t provide was everything around it: shared rules, shared tooling and guardrails around production systems and customer data.
Neos is a Certified partner in the Claude Partner Network. Our AI Department Manager led the engagement, and we built it around CloudVane’s own code and workflows rather than generic training.
We started by setting up the Claude Team plan: ownership, domain verification, seats and the organisation-wide settings that control spending, sharing and which Claude products people can use. CloudVane moved onto the plan on 6 September 2026 with seven seats, for the developers and for colleagues who work in Claude chat, Projects and Cowork. It has been in production use across the team since.
Next, we installed Claude Desktop and Claude Code on every developer workstation, recommended which Claude models to use for which kinds of work and ran a hands-on Claude Code workshop on CloudVane’s own codebase. The non-developers got an introduction to Claude Cowork. Today the team works mainly with Claude Opus 5.5. Claude Sonnet 5.5 handles subagent work, and Claude Fable 5.1 is used for selected tasks.
Then came guided adoption. Each developer applied Claude Code to real work: features, tests, refactoring and documentation. The Platform Architect behind the pilot became the team’s internal champion. A short weekly sync gave the team a place to compare notes, refine its conventions and decide where to extend Claude Code with MCP servers, skills and hooks. Once usage settled, we reviewed it with CloudVane’s lead and adjusted seats and setting.
Claude would be working next to production clusters and customer data, so the safeguards came early. Together with CloudVane’s developers, we had a shared Claude Code setup in place eleven days after the Team plan went live. It lives in CloudVane’s own GitLab repository, so everyone works from the same rules.
A CLAUDE.md file, which Claude Code reads at the start of every session, sets out team rules for commits, merge requests, review comments and production safety. Organisation-managed settings stop Claude from reading secrets, database wallets and cloud API keys, prevent it from adding every changed file to a commit at once and make it ask before it changes production Kubernetes, Postgres or Keycloak configuration or writes to the production Oracle database. Two plugins, cloudvane-dev and cloudvane-ops, turn the team’s own workflows into skills Claude can reuse, from merge request review and CI and Sentry triage to Jira drafting and promotion to production.
We kept refining it with the team in the weekly syncs. By late October it had grown to 28 skills across three plugins, including an office plugin that files invoices and travel orders for the non-engineering side of the business.
A merge request is a finished code change accepted into the codebase. The four developers who got Claude through the Team plan now merge 24.9 a week on average, up from 11.3. That is 2.2 times as many. The comparison covers the seven full weeks since the Team plan started and the nine weeks before it. Two other developers didn’t get Team seats and have since left the project, so they aren’t part of the comparison. The earlier period includes August, when some of the four were on leave.
Adoption has held up across the team. As of 28 October, all seven seats were active weekly and six were active daily. In October, every active Claude Code user worked with the shared plugins, and six of the seven used MCP servers and subagents. Outside engineering, colleagues ran 177 Cowork sessions over the last 60 days and use Claude Projects for business and finance work.
Merge request figures come from CloudVane’s GitLab history and count merge requests by the same four developers, excluding automated dependency updates and develop-to-master promotions. Usage figures come from Claude Team analytics.
“We started with one engineer on a personal Claude Max plan. Once we gave the whole team the same setup on Claude Team, with our own rules, skills and guardrails, most of the team was using it within two weeks, and now the developers are shipping more than twice as many merge requests a week.”
– Matej Cubek, Platform Architect, CloudVane
Talk to us about bringing Claude into your team’s work with shared rules, skills and guardrails from the start.