How a perfectionist engineer mindset can fail your startup

Thomas Boni is a French engineer and entrepreneur, and CTO & Co-Founder of R2Devops. His career started in HPC (high-performance computing), then evolved towards DevOps. This — and in particular CI/CD pipelines — became the focus of his consulting company, which then became his startup, R2DevOps.

He told its enlightening story at Scaleway’s recent “The Jam” event, April 5 in Paris. Read on to find out how an engineer’s perfectionist mindset doesn’t always fit with that of a flexible startup founder… and how Boni overcame that gap!

In 2020, my co-founder Aurélien Coget and I started our own consulting business, helping other companies to develop their DevOps methodologies. We both have pronounced engineer mindsets, I should point out at this stage.

Beginnings in CI/CD

Our main focus was on CI/CD (continuous integration/continuous deployment); we offered a way to automate testing, building, and deployment of clients’ software. Our clients were happy with the value we provided, and we grew quickly to a staff of eight.

However, we felt like we were reinventing the wheel every time. Creating a CI/CD pipeline requires considerable effort. After all this effort, you have something that’s great for your customers; but you also create a single point of failure in their development workflow.

Because, if one day the pipeline stops working, the developers can’t code anymore. So it’s become really critical.

Nobody cares about CI/CD until it fails

Creating a CI/CD pipeline can be a huge waste of time, and money. In this domain, there are no reusable components on GitLab; testing is hard; and it’s a vast ecosystem.

A pipeline itself consists of hundreds of YAML lines — YAML is a way to write your configuration — which are undocumented, because there’s no single way to write these configurations. Everyone has their own recipe. So nobody cares about the CI/CD pipeline until it fails, and then no one knows how to fix it… and the customer certainly isn’t going to maintain it themselves.

This exact thing happened with a founder I met earlier this year: he hired someone to create their company’s CI/CD pipeline. Then that person left. When it broke, no one in the company could fix it. So the founder decided to trash everything and start from scratch.

We also discovered incredible inefficiencies in the projects we worked on. One client had 15 different custom-built pipelines, all of them serving exactly the same purpose. They had spent a lot of money on each of these 15 different pipelines, when they could have been using variations of the same one.

The Eureka moment

So we realized this was a generalized problem, that we could do something about. We started by creating an open source repository of reusable CI/CD templates on GitLab, as a side project. People liked them, and we gained some contributors. This showed us we needed to build something more ambitious; what we saw as the ‘perfect’ product.

However, when we decided to launch our startup, we made a lot of mistakes:

• We kept being consultants, so were trying to work two jobs at once
• We didn’t talk to our users, so we made useless features
• We had a perfectionist spirit, so we lost a lot of time building perfectly-executed technical features… that the market didn’t want.

On top of that, we made some major technical choices:

✅ Cloud native product
✅ CI/CD everywhere
✅ Reuse existing components, e.g. to manage system identities, we used Kratos (an open-source identity service)
❌ Design the whole system as microservices
❌ With hexagonal architecture (putting the business logic at the core of each component, input and output are modular)

With hindsight, the latter two decisions were not great ones. Using microservices, for example, added a lot more complexities than necessary. Overall, this was a fail.

Successes from failure

But it wasn't all bad!

Firstly, GitLab called us, because they were interested in what we’d done on their platform. We’re now an official technical partner.

Secondly, in Spring 2022, we went to San Francisco for a few months to explore the tech ecosystem there, to talk to developers, founders and investors, to try to identify what we did wrong and work out what we could do better. It was an awesome experience, if a bit harsh at first, as you have to change the way you present your product.

Even more so if you’re a French engineer, who wants to explain everything in great detail; they don’t want to hear about that! The feedback was a bit harsh at first, but super useful for us in the end.

Then, we applied for funding from Y Combinator (one of the world’s leading, and most selective, startup funds). We were two months late, but they still called us back, and we got to the last stage: a ten-minute pitch to three investors, where you have precisely 15 seconds for each answer. So you have to be really impactful. We weren’t selected in the end, but still learned a lot, so it was a great experience.

What we learned

This experience inspired us to try again, but with some radical changes:

• We stopped consulting, in late 2022, to go all-in on the startup. We had a 12-month runway at that stage, and no more income (from consulting)
• We started talking to users every day. I got that advice from Solomon Hykes (the inventor of Docker); he said that after just a few weeks of talking to users daily, you’d be able to identify problems, and therefore what you need to focus on. Today, everything we do in the company is driven by customer feedback and discussion with developers
• And we realized perfection is the enemy of ‘done’. We had to fight our engineer spirit to make sure everything we put into the project was impactful.

So today, we work by iteration, on the assumption that nothing is definitive, and that any part of the project can be changed radically from one day to the next. We also understood this way that we didn’t need to build a project that’s scaleable to millions of queries from day one. We need to put the product on the market first, see if developers like it, and then think about making it scaleable, resilient, and bug-free.

Finally, we stopped being ashamed of the product, and showed it to customers even if it had issues. This was really stressful at first, because there were plenty of bugs, but it was the right move in the end.

Users helped us to test real-world use cases, and gave us feedback about their real needs. Some of them ended up developing parts of the system. For example, one customer needed to deploy an Instance of our product on Kubernetes. He wrote the Helm chart himself, gave it to us, and we just had to integrate it into our system.

Perfectionism, the greatest foe

The ‘non-perfectionist’ principle was one of the hardest points to get across. One developer actually quit when we told him we’d enforce this principle. But it worked.

Better yet: the user with whom we had the most bugs at first was the first to sign up as a paying customer. When customers are that involved in the product, they feel like it’s being developed just for them.

This is where we really saw that failing is the best way to learn. And to learn, you need to be proactive about sourcing feedback. Share your calendly everywhere and anywhere developers might be online. Start the conversation by not talking about your product, and then it’ll come up naturally, later in the conversation.

We also had the humility to rethink some of our aforementioned technical choices, to favor more simple and efficient tools. So we opted for Monolith instead of the cumbersome previous choice of microservices; and for MVC instead of hexagonal architecture.

So, to conclude, we learned from our big fail, and continue to iterate today. We’ve run 300,000 pipelines for our users on our public CI/CD marketplace; and we made our first sales in Q1 2023. So much for that perfectionist mindset!

More enlightening engineering insights at the next edition of The Jam; sign up here!