Achille Morin Lemoine

Closing a €150,000 deal & becoming a real tech company

For broader context, this post is Chapter II of the Why Cyrius Failed series.

Recap of the previous part: We launched our cybersecurity startup while still at school, using no-code tools. We secured our first clients and transitioned from a school project to a full-time venture.

Yet, we were still looking for a stronger sign of traction.

Table of contents

Lessons learned

The CIO told me how satisfied he was with our work.

We had been working with them for a year now and had always made sure to over-deliver.

Then, abruptly, he offered us to switch on a company-wide contract.

"Great", I said casually, not getting what that sentence meant, "what numbers are we talking about?".

The answer: +10k users and a 145,000€ contract.

I was left speechless. Our usual deal size was typically 5–10k€ a year...

But that happened only after a first year in business full of twists and turns. Let's get back to where this chapter begins: after we entered STATION F, the biggest startup campus in the world.

Now things were getting serious.

We had clients, a working product, and seats at an accelerator.

We even started hiring. We brought on two summer interns and an apprentice. I feel like we hired and treated them more as friends than anything else, but it was fun.

They helped us with content creation, setting up the processes, and finding clients. We love you Hugo, Nate & Ali 🫶🏻

LESSON #7: Hire interns thoughtfully.

Hiring interns or apprentices can be great if you are aware of the implicit deal. What you get is a cheap workforce. What you give is time to train and manage them. If you have easy, operational tasks that only a smart but inexperienced human can do and little budget, then interns are a good idea. Otherwise, the time investment may not be worth it. That is why I would not advise every early-stage start-up to hire interns. Let big corporates that have time to waste take care of the training.

Opportunities and limits of no code

The only missing thing to be a "real tech startup" was a CTO. We asked ourselves the question of whether we should go for code quite early, as we were ambitious and knew we wanted to grow. But the product was already performing well, despite our tech stack solely made from no-code tools.

The tools we used were:

It was working fine at first. It allowed us to quickly ship features with total autonomy. 

However, as we added more users and features, we experienced our first bugs.

We struggled early on to provide correct figures in our stats. Too bad that our clients rely on these stats to ask late employees to catch up with the training… 

Further down the road, it became latency issues: barely noticeable at first, then 5 more seconds to load a dashboard. A month later, 10 additional seconds. And so on.

Bugs are insidious because you always think it is gonna be okay - until it is not anymore, and all your clients are screaming at you all at once.

1_XEjh2zw8Hm3mCTzWBDbWoA Year 1  -  Us: "Awesome! You're not lucky, the module works for everyone except you apparently 😅. May I send you the latest module?". The user: "Yes it's been 2 times and it is still not working… It's too bad, makes me feel that I don't want ever to do it again".

Despite the bugs, however, we lost only a few customers because of that specific reason over the years.

When we could not fix the issue directly, we did whatever was possible to make their situation work anyway. We offered extensive service work to perform what they initially intended. 

But truth be told, bugs lead to terrible relations with customers and mountains of stress and operational work. This will be learning for later, keep reading.

LESSON #8: No-code ≠ scrappy tech.

We have a lot of experience with no-code tools. These are amazing and we would have never made it that far without them. But you have to know their limits.

No-code is especially great for prototypes and internal tools. You can ship no-code production-grade platforms IF their architecture is properly structured. Be mindful of security as well.

Another issue with no-code is that it gave us the false feeling that shipping a feature is easy. As easy as a drag-and-drop on an interface. It's not. When we switched to actual code, we realized that scalability comes with a price. Tech is hard.

In retrospect, we lacked the agility to change tools soon enough. We should have audited our processes more diligently and find more workarounds.

Instead of that, we decided that switching to code was the solution. We would find a CTO and they would fix everything with their magic. (Spoiler: There is no such thing as magic in tech.)

But who would join such a young cybersecurity start-up founded by 3 business guys? With almost no budget for a full-time hire, we needed someone willing to start for free.

The search had already started a few months before. Although we met interesting and interested people, we could not find exactly what we were looking for  -  especially in the human fit. We didn't want to mess that up and waited for better opportunities.

Prioritizing features

The product was improving despite the bugs. 

We were very resourceful for shipping "quick and dirty" (but functional!) features. We even engineered complex tools such as integrations with third parties.

As our value proposition was "the best way to learn cyber", we wanted to enhance the user experience as much as possible. We added a dashboard on their end, and they loved it! The "fake it until you make it" approach was thrilling and helped us secure our first clients, but it also set a dangerous precedent.

We overpromised on our capabilities, which put immense pressure on our team to deliver. This taught me the importance of being honest about what we could realistically achieve and the risks associated with overcommitting.

LESSON #9: Start fast, but take the time to improve after.

Rule #1 at Y Combinator is "Launch now", which we followed thoroughly on many occasions. But you must only be scrappy initially to get you to move. We failed to take a step back regularly and fix our broken stuff. It only postponed problems.

However, new user-facing features would not help me to sell directly.

The tug-of-war between user features and admin features reflected their intertwined relationship: unhappy end users (employees) meant frustrated buyers (CIOs) - but too much effort on the admin side could make the user experience soulless. Striking that balance required constant calibration.

We switched from focusing on the user to focusing on the admin, and this swing went back and forth for almost all our time in business.

Screenshot 2024-06-09 at 15

Screenshot 2024-06-10 at 16

The first version of the dashboard (Year 1) VS the last (Year 3)

LESSON #10: Listen to the opinion of whoever writes the check.

When your product serves different personae, prioritise features according to the criteria of the person who gives you money. It took time for us to have that sink in. More on that on my 2021 Journal Entries

In our case, the security manager or CISO was the admin and the buyer most of the time (when it was not the CTO/CIO).

But we were also interacting with the end users, as they completed the learning modules. Plus, a good completion rate was part of the CISO's objectives, so some effort was needed in UX.

When we realized that user-facing features were not enough to drive sales, we dropped the investments there.

We should have searched for the right place between 1) to please users enough so that they tell the CISO they love the tool, and 2) keep shipping purely admin-facing features such as advanced statistics, exports, and so on.

Beginning of the marketing

Despite challenges, we kept growing thanks to our intense prospection and first marketing moves.

For instance, we interviewed 6 CISOs from famous companies (like Doctolib, a French unicorn company) and released their insights in our first white paper called "All you need to know to involve your employees in your cybersecurity program".

It received fair attention in our network and positioned us as one of the players in the field.

LESSON #11: Produce content as early as possible.

Even if it did not bring us direct customers, I would recommend to create high-value content as early as possible. It fosters credibility, expands your network, and can be repurposed. Our very first white book, updated 2 years later, kept generating inbound opportunities for us.

64f87a435cc8e8cee4673a72_Image ebook cyber-p-500 2 Year 1  -  All you need to know to involve your employees in your cybersecurity program (here is the link to the actual guide). Look at that sleek design.

We also attended our first cybersecurity conference, the FIC, the largest in France and well-known across Europe.

There is a YC rule stating "Don't go to conferences unless they are the best way to get customers". Given CISOs' preference for such events, it made sense for us. Unable to afford 5,000€ for a booth, we went as visitors and embraced the hacker mindset:

We printed QR codes and stuck them on every wall, leading to a special webpage for meeting registrations. That was forbidden of course 😁

We shared branded cardboard sleeves for people to store the prospectus from the other vendors. Pretty smart eh?

Unfortunately, we did not get any customers from that initiative. Almost no one scanned our QR codes…

But by chance, we met a friend who recommended us to his journalist friend, leading to our first press article.

fic1 Year 1  -  We even sticked QR codes in the bathrooms…

LESSON #12: Keep the hacker mentality.

One thing we did well was being creative with limited resources. Always maintain a hacker mentality -  financial constraints fuel creativity.

However, we could have anticipated that security managers would not scan a QR code from an unknown source. Ahem…

I even got my first TV interview!

We -obviously- did not pay the 1,000€ fee to get the rights (without money at that time),so we could not use the video. But we used screenshots everywhere to cement our legitimacy and show we were serious. Let's hope I will not face a lawsuit for sharing the video now that the company does not exist anymore. 🕺🏻

In parallel of the marketing initiatives, I was still pushing prospecting as hard as I could: emails, calling, LinkedIn DMs...

Another example of our hacker mentality was the different tricks I tried to grab our prospects' attention. One of them was sending a personalised video for each of them.

You read that right. I spent days recording videos of myself and sending them to 30+ targeted prospects.

It turned out that even that heavy time investment did not pay well, as not even a quarter of the people opened the video...

thumnail Year 1 - Can you imagine the energy needed to record 30x the same video? AI-clones did not exist yet...

In retrospect, our growth was too slow despite those significant efforts. We could have done better by exploring more distribution channels and adapting the product for a smaller niche.

This would create issues later on, but more on that later. Keep reading…

The first enterprise deal

However, there was one bright spot.

Remember our first customer, the public works company?

We kept working closely with them all year, being very proactive, advising them on their cyber strategy, and so on.

One evening, at the end of the year, we discussed the future of our collaboration. It was a pivotal moment for us. Although we had invested a great deal of energy in them, I did not know what to expect exactly.

The CIO told me how satisfied he was with our work, and offered us to switch on a company-wide contract.

"Great", I told him, "what numbers are we talking about?". The answer: +10k users and a €145,000 contract.

I was left speechless. Our usual deal size was typically 5–10k€ a year.

I remember hanging up a bit stoned by what had happened. Almost €150,000 (€174k all taxes included), for real? At our stage, receiving that amount was like raising funds.

While at that moment I was feeling ecstatic, the net outcome of that moment is to be balanced. Landing such a big contract that early distorts your reality:

The lesson here is the same that the one I share in the previous part: be mindful about your first customers, especially the ones who hold power on you. Don't bite more that you can chew, and don't let them distract you from your vision.

(As a side note, there is a piece of advice from YC saying that you might have to fire some of your customers at some point. I believe it is one of the hardest move to make, every founder knows how freaking hard it is to close the first clients.)

virement Year 1.5 - How can anyone refuse that amount of money?

Anyway, as soon as I exited the call with our client, we bought a huge bag of chocolate (and maybe a few drinks at our favourite place). We had a rule at that time to invest a maximum of 1% of each sale into something "fun and useless".

Another time, we organized a breakfast for other startups with a mountain of French chouquettes. A few months later, we made the very first luxury purchase in our professional life: brand-new MacBooks.

IMG_0077 Year 1.5  -  Buying professional, expensive equipment with customer money, what a pride!

LESSON #13: Do things seriously, but don't take yourself too seriously.

Starting a business is hard, especially a start-up. Rules like investing in random activities helped to nudge ourselves towards fun. Because if you're not having fun, what's the point of the journey? We progressively dropped the "1% Rule" rule as we became too serious, which was a mistake.

Hiring a CTO

Now that we had enough revenue, we could consider getting into the Venture Capital (VC) game. However, investment funds would not consider us without a technical associate.

At least now we had money to scale the search.

We hired a recruitment firm to find a technical co-founder. We met five suitable developers and clicked with one.

We had a couple of online meetings, invited him for dinner, and decided he was perfect for the job. We agreed on his condition to work remotely, even though our team was based in Paris.

We began with a freelance contract meant to last 3 months. After one month, since freelance is expensive and everything was going well, we decided he would join us as a late founder, with 15% equity (vested over one year).

Those are a lot of red flags. 

Picking your associates and first employees is one of the most important elements to ponder. We were too naive:

LESSON #14: Picking an associate is as critical as it sounds.

Take your time to find the right technical co-founder or CTO. Ensure they are a good cultural fit and thoroughly vet their skills. Consider starting with a freelance or part-time arrangement to evaluate compatibility before offering equity or a full-time position.

We clearly went too fast on that one. Looking back, our desperation to quickly find a technical co-founder clearly clouded our judgment. We rushed into bringing someone on board without thoroughly vetting their skills or cultural fit.

IMG_2419

Year 1.5 - Fantastic Four

Of course, we got along well with him and he was very skilled.

But I'm being honest with myself, secretly I hoped checking the 'CTO' box would lend us credibility and make fundraising conversations easier. 

Anyway, with our CTO on board, we aimed to fix our product issues and keep our clients happy, but the journey was far from smooth.

From dealing with persistent bugs and onboarding our first full-time employee to gaining traction and visibility in the market, we faced a series of challenges that tested our resilience. 

In Chapter III, I'll share how we managed to achieve 20k€ in monthly recurring revenue, navigate the complexities of fundraising, and secure more than half a million euros in financing to fuel our next growth stage. Stay tuned!