Take 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.
Context
On-premises software runs on the customer's own hardware, inside their own building. That single fact decides almost everything about how it behaves.
There is no sign-up, because there is no stranger. Someone bought the software and installed it; everyone using it already belongs. There is no trial, because you can't try a thing you have to install. There is no billing inside the product, because the money was handled by a contract before anyone opened a screen. And there is no real question about who can see what, because everyone in the building works for the same company.
Moving to the cloud removes all of those assumptions at once. The design problem was never "put it on a server." It was: who is this person, what may they see, and who pays for what they use.
And one constraint made it harder: the existing structure had to survive. Customers already running Cervello on-premises knew how it was organised. A cloud version that reorganised everything would have been a different product wearing the same name.
Decision
A trial, and an instance you own
The unit of the cloud product became the instance, a customer's own space, reached by a subdomain they name themselves, so they log straight into their own environment rather than a generic front door. And it comes with a 14-day trial. That single decision is what opens the product to a market that previously had to commit before seeing anything. The ownership rule underneath it is deliberate: you may join many instances, but you may own only one. This is the rule that makes everything else tractable. Joining is how you work in other people's spaces: an integrator's engineer working inside a client's environment. Owning is what you pay for. Keeping ownership singular means billing, resource limits and the trial all attach to something unambiguous. A person arriving with an invitation link is routed to choose which instance they're entering; a person with none is setting up their own. And the first setup is automatic. Creating an instance also creates the first organisation, the first team, and gets the user working in seconds, rather than making a new user assemble an empty hierarchy before they can do anything at all. The structure exists because the product needs it; the user shouldn't have to build it by hand just to begin.
Decision
A sign-up that refuses to confirm who exists
Sign-up is by email with a verification link. What matters is what happens when the email is already registered. The ordinary behaviour, this email is already in use, is a small convenience and a real vulnerability. It confirms to anyone who asks that a specific person holds an account on this platform. Ask it repeatedly and you have a list of confirmed targets. So the product doesn't answer. The flow looks identical either way. If the address is already registered, a security notice goes to its owner instead: someone attempted to sign up with your email. They can ignore it, or change their password. Preventing account enumeration is a standard security practice. What's worth noting is that it was designed into an ordinary sign-up screen on a platform that eventually controls physical infrastructure, where knowing who operates a system is itself useful to an attacker. A related decision: the profile screen after sign-up is skippable. Not every field belongs at the door. What's missing gets requested later, in context, while the user is already working, including region, which matters more than it looks, because time zone determines how alarm and event timestamps read.
Decision
Reselling, without a rebuild each time
An integrator builds a smart-parking solution once and sells it to four cities. On-premises, that was four installations. Buy the platform, set it up inside the customer's own building, then rebuild the solution on top of it. The solution stayed where it was installed, the way an open-source project becomes one application on one desktop and never leaves it. The answer everyone wanted was a marketplace. The product manager proposed it, it went to the development team, and it came back too large to build in the time there was. What shipped instead was smaller and did the same work. Duplicate, then transfer. Where the copy is made is the whole of it. The customer creates their own account, opens the instance link, and takes a copy, so it is theirs from the first second. The integrator's engineers then join that instance to add the integration and whatever that customer's site needs. Nobody hands ownership over after the fact, because ownership never sat in the wrong place to begin with. That is what keeps the rule above it intact. You own one instance, and you join many. Billing, resource limits and the trial stay attached to something with a single owner, and a resale stops being a rebuild. The marketplace still had not been built when I left.
The problems, as they actually presented
Five things surfaced from testing the existing product, competitive analysis, and interviews with the people who build on Cervello:
Nobody could try it. The only way in was to buy it. For a platform sold to integrators evaluating options, that is a closed door in front of the entire market.
Registration was long, and it asked for too much. Extensive required fields at the moment a stranger is least willing to give anything, compounded by legitimate security and privacy concerns about a platform that will eventually control physical devices.
Reselling meant duplicating. Integrators build a solution once, then resell it to multiple customers. Every resale meant manually duplicating and re-customising the whole thing. The product treated a reusable solution as a one-off.
The buyer wasn't the user. Whoever purchases the platform frequently isn't the person operating it, a structural fact of B2B that the on-premises model never had to model, because a contract handled it outside the software.
Multiple people in one workspace collided. No way to see who was doing what, no activity tracking, no way to manage a shared space while several people worked in it simultaneously.
Result
The cloud version shipped, and runs in production in several countries including Spain and Egypt.
What the work demonstrably produced: a platform a stranger can enter, evaluate for two weeks, and pay for, with an ownership model clear enough to carry billing, and a sign-up that declines to leak its own user list.
Next chapter: The Permission Architecture, four nested layers, and the question of who may see whom.