Case file · Smart Things
Cervello Cloud (IoT)
What it is
Cervello is an IoT platform for integrating, monitoring, automating and controlling devices and systems, sold not to end users but to integrators and software vendors, who use it to build vertical smart solutions for their own customers.
It already existed as an on-premises product, installed inside a customer's own data centre. My work was the cloud version: the same platform, multi-tenant, reachable from anywhere.
That sentence sounds like a hosting change. It isn't. Moving a single-customer installation to a shared platform breaks almost every assumption underneath it: who owns what, who can see what, who pays for what, and what happens when two people work in the same place at the same time. That is the design problem in this case file.
Individual contributor, from zero to delivery. I started this project alone and carried it through: research, information architecture, user flows, wireframes, interface design, the design system, and developer handoff.
A second designer joined later and worked on UI. None of his work is shown here; everything in this case file is mine.
Status, honestly
The cloud version shipped. It runs in production in several countries, including Spain and Egypt.
And I have no numbers for it. This was four to five years ago; I don't have adoption figures, retention, time-to-build, or any other metric I could stand behind. So none are claimed here.
That limits what this case file can be, and I'd rather name the limit than manufacture a result. What it can show is judgement: the decisions, and the reasoning under them.
Why this one still matters
Everything I do in regulated banking today started here.
This is the project where I wrote down design principles instead of just following instincts, built a design system rather than a set of screens, and invented a documentation method that traced a feature from first idea through post-release iteration. The permission architecture I designed (four nested layers, each with its own scope) is the same class of problem as designing a bank's internal review system.
It also sits outside banking, and that matters for what this portfolio is for: B2B SaaS, a developer-facing platform, a product whose users are integrators building products of their own.
Three ways in
- If you want the hardest architectural problema single-customer installation became a multi-tenant platform, and every assumption about ownership, visibility and billing had to be rebuilt. Chapter 1.
- If you want complexity handledInstance → Organisation → Team → Project, four nested layers of permission, in a product where the person who buys it often isn't the person who uses it. Chapter 2.
- If you want methodfour written UX principles, a design system, and the Feature Catalogue: a documentation format that tracks a single feature from problem statement to acceptance criteria to every iteration after release. Chapter 3.
- On-Premises to CloudTake a platform that lives inside one customer's data centre and make it a shared, multi-tenant product anyone can sign up for — without breaking the structure the existing product already depends on.
- Permission ArchitectureBuild a structure that lets an integrator manage many clients, many teams and many projects inside one platform — while making sure nobody sees anything they shouldn't, and everybody can find the people they need to work with.
- Method & Design SystemBuild the working method the product needed — written principles to decide by, a design system to build from, and a documentation format that survives a feature past its release.