This is a guest Post by Jake Lumetta, Founder and CEO, ButterCMS, an API-first CMS. For more content like this, follow @ButterCMS on Twitter and subscribe to our blog.

Conventional wisdom for startups counsels starting with a monolith, but are there situations where you should start with microservices instead? Interviews with dozens of CTOs illuminated the key considerations when deciding whether to start with a monolith or microservices.

Challenging Conventional Wisdom

My good friend Darby Frey recently kicked off a greenfield project after assuming his new role as Sr. Platform Engineering Lead of Gamut. Despite starting out with monolith at his previous company Belly, he discovered that — in the right circumstances — starting with a monolith isn’t always the best way to go.

“As one does, I allowed much of my thinking in my early days [at my new company] to be influenced by my previous company,” Darby told me.

At Belly, Darby and his team broke down their monolith into a fairly large microservices architecture. They managed to get it to a good place, but only after months of trials and tribulations migrating to microservices.

With this experience fresh in his mind, he approached his new project at Gamut a bit more cautious of microservices.

“I was firmly a member of Team Monolith. [I thought] let’s build a single application and just pull things apart later if we start to feel pain,” he said.

While this was a greenfield project, Darby’s team was small, and he had aggressive timelines, so on the surface, a monolith seemed like the obvious choice.

“[But with this new project], I was anxious to not repeat the mistakes of the past.”

And with that, he found himself faced with a decision we all struggle with, should we start with a monolith or microservices and how do we decide?

Evaluating Pros and Cons

Facing A Monolith