How a perfectionist engineer mindset can fail your startup

How a perfectionist engineer mindset can fail your startup Deploy • Thomas Boni • 13/04/23 • 5 min read

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. O ne 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 ,…