Cycloid · DevOps platform · Product design · Design leadership
From internal tool to SaaS product
Building Cycloid's design practice from zero while shaping the product that took the company from $8M to $28M.
- Role
- Founding Designer → Design Lead
- Team
- Founding team (founder, CTO) and Core DevOps team; built and led a design team of 5
- Timeline
- 2018 – 2020
As the company's first designer, I built the practice from zero and grew it to a team of five, combining designers focused on visual design with hybrid designer-developer profiles.
Context
Cycloid is a platform for DevOps teams that brings together pipelines, infrastructure as code and environment management across multiple clouds. Its idea: a platform team defines good practices once, and the whole organization benefits from them, deploying without needing to be infrastructure experts.
The technology was powerful, but it was sold and used like an internal tool: on-premise installations, delivery through partners, heavy customization for every client. Going SaaS meant two things it didn't have yet: self-serve capabilities like subscription, and a product customers could use without someone from Cycloid guiding them.
How I worked
Building a design practice that didn't depend on me
When I joined, the team was small and everything was debated asynchronously in GitHub threads. It was part of the company's DNA, but it didn't scale. I pushed for regular weekly sessions that brought together development, the DevOps engineers who validated the functional decisions, and product (the CTO and me). Within the design team, async critiques handled the work that didn't need a meeting.
It changed who got heard. Decisions stopped going to whoever was most persistent in a thread, and started coming from people thinking through problems together. Fewer back-and-forths, more involvement, and a way of working that held up as the team grew.
As the company scaled and teams specialized, every team adopted these rituals, and we added new ones to track and steer the roadmap.
Findings
What we learned
I audited the product against competitors, and became fluent in Concourse and Terraform myself. You can't simplify what you don't understand.
Nobody could see the whole picture. Teams lacked a shared view of their whole infrastructure and how it was connected. It was the gap we saw against competitors, and the first thing customers and partners asked for.
Non-experts got lost in the possibilities. Terraform and Concourse can do almost anything, which is exactly the problem for someone who just needs to deploy.
Opinions were welcome. I expected users to resist being told how to do things. Instead, they were happy with an opinionated product, as long as it solved their problem.
Key decisions
Opinionated defaults, full power on demand
Good practices applied by default, so non-experts could deploy safely and consistently. Progressive disclosure for experts, who could still use everything Terraform offers. One product, from newcomer to platform expert: catalog → configuration → operations.
A design system as a contract with engineering
The goal wasn't a style guide, but a shared language that could scale without me in every room. The same type of data always looked and behaved the same way in the UI. And we left room for free-text editing where structure would have been a constraint, not a help.
Impact
What design moved
of customers on the first self-serve offering, in a business still built around enterprise sales
Driven by: Opinionated defaults that let non-experts deploy on their own (decision 1).
design team, with rituals adopted across engineering teams
Driven by: The weekly sessions and async critiques described in how I worked.
Where the business went
- Company valuation
- $8M → $28M in just over 2 years
- Orange Business Services
- Strategic partnership: investor and key customer, with 20+ internal teams adopting the product
What I'd do differently
I'd set up research with our community much earlier. We had a technically engaged user base that could have told us what to prioritize and what to skip. Without that signal, we built some things we shouldn't have and delayed others we should have shipped sooner.
Get in touch if you want to go deeper.