SanityDesk

The problem

Every customer SanityDesk signed arrived with its own instance to run, patch, monitor and upgrade. Growth made the operations load heavier rather than spreading it across a larger base, and engineering time went into keeping copies alive instead of into the product.

Single tenant is rarely a mistake at the start. It is the fastest way to a first customer and it makes the early promises easy to keep. It turns into the problem later, when the cost of the next customer is the same as the cost of the last one and the release that should take an afternoon has to be done one estate at a time.

The clean answer, stop and rebuild as a multi-tenant platform, was not available. There were customers on the old shape and a business that had to keep running while the architecture changed underneath it.

What we did

Frank served as advisor and executive consultant to SanityDesk, working through its own engineers rather than as the delivery shop. He re-architected the back-office systems, led the migration from Google to AWS, and took the backend from single tenant to a multi-tenant hybrid. In 2022 he also started the company's SaaS financial model with its finance lead, so the architecture and the unit economics were planned together.

The hybrid is the part worth reading twice. It let existing customers stay on the shape they were already served on while new ones landed on the new one, so the route to a fully multi-tenant platform became a sequence of steps the team could take at its own pace.

That shape also changes the conversation with the people paying for it. A rebuild asks a board to fund a year with nothing visible at the end of it. A hybrid asks them to fund the first step and shows the second step working before it is funded.

Why a hybrid, and not a cutover

• The business does not pause. Existing customers keep their service on the architecture they are already running on, and nobody is asked to accept a migration window in exchange for a benefit they cannot see.
• The hybrid is a stepping stone, not the destination. It was scoped as the stage before a fully multi-tenant platform and described that way to the people who had to fund it, so the remaining work stayed on the plan instead of quietly becoming the new normal.
• The work went through the client's team, not around it. The engineers who would own the platform afterwards are the ones who moved it, which is the only version of this project that still works a year after the advisor leaves.

How we work inside somebody else's engineering organization

Two things a buyer usually has to get from two different vendors: a cloud migration that does not stop the business, and an architecture change delivered through the client's own team instead of around it. This engagement is the record that we do both, as the senior technical voice in a room we do not own.

That role has a different discipline to it than delivery. The decisions have to be explainable to the engineer who will implement them and to the executive who will pay for them, and they have to survive being disagreed with, because the team can and should push back. An advisor who can only be right by doing the work themselves is not an advisor.

It was an advisory engagement and we describe it as one. No delivery team of ours sat on it. The work was the architecture, the migration route and the judgment calls along the way, handed to the people who had to live with them.

What the client said

“Thanks to Frank we efficiently started the finance modeling process for the start-up company. Frank has very deep knowledge and skills in many areas: engineering, software developing, management and finance. He is patient, honest, intelligent, and dedicated.”