Le French Product - The web you know is about to be rebuilt - Aurelien Georget (Founder of Strapi & Fimo)

Transcript

Intro

We had those two options. Either we see a competitor, an AI-native CMS, being created in front of us, or we decide to create our own competitor that could become our best ally. The web was mostly built by humans for humans. The web, I think, is going to be built by agents mostly for agents and humans. And I think that's the big shift.

90% of the code is being AI-coded compared to what we used to do with Strapi. What used to take two weeks now takes two minutes. I think it's great for the role, actually, because I don't like to see PMs spending their time doing tasks that can be done by AI, where their real value is about making the right decisions. The market window is right now; it's not tomorrow, it's not in two or three years. That was Aurélien. He co-founded Strapi in 2013 as a student project.

Today, it powers content for the websites of Apple, Adidas, and IKEA. $50 million raised, millions of users worldwide. Two weeks before we sat down together, he launched a brand new company called FIMO. FIMO.ai is an AI-native website builder built on one specific observation: every existing tool out there can build a website, but none of them were designed to let AI maintain and evolve it over time.

In this conversation, you will hear about how 10 years of running Strapi gave him the exact insight to see what everyone else is missing, and what building FIMO in six months with a team of five taught him about what it actually means to be AI-native. Here's our conversation. Brilliant. Thank you so much for being on the podcast. As you know, I am already a big fan of Strapi, and you just launched FIMO, and we are going to get into it. But before we dive into it, tell me about your journey. How did you end up as the CPO of Strapi, and why did you go into content management?

How Strapi Was Born

Thank you for having me. It's a pleasure to be here. We started as a student project in 2013. This is where I met my co-founder while doing my master's degree. At first, we were just three freelancers working on different missions, mostly building websites.

Mhm. We were at the same time when mobile apps started to rise. Our customers wanted to build not only websites but also mobile apps at the same time, and the content was the same. We were using WordPress at the time, and it started to be not a good fit anymore for those products and projects. So we created our own product, Strapi. It had another name; I think the first name was Wisti or something like this. I have never, I don't remember that time.

That's exclusive news. We built it for our own customers. We published it on GitHub, hoping to get some traction, but it was nothing, just a few hundred stars on GitHub. Nothing serious.

Yeah. At the end of our studies, we decided to create a company. We thought we should give it a try. The three of us were, I think, entrepreneurs, and all three of us were engineers. I started to code at 13, so I have mostly an engineering background, but we still had different skills. Pierre, the CEO, was clearly the best one for doing sales and managing the company. I was the one, I think, better at managing projects and building a product.

This is how I ended up being the CPO. Now we are a company of 70 people, fully remote. We launched Strapi 10 years ago, and we launched a new product called FIMO two weeks ago. So, I am super excited to talk about this.

Why Launch Fimo Now?

That's amazing. So, why launch FIMO now? You are already a CPO at a successful company. So, why now, and why start something new? It's a tough call. I think we had two options when Strapi was working well. We are doing millions in revenue.

We are going to be profitable in less than six months. We raised $50 million with the best US VCs. It's a successful company, and we have millions of users. We have most of the big corporations in the world using it. If you go on most of the websites built by Apple, if you go on adidas.com, if you go on Vectid, IKEA, all those brands, they use Strapi for their main website. It's huge. But AI is redefining pretty much everything in our industry.

And we had those two options. Either we see a competitor, an AI-native CMS, being created in front of us, or we decide to create our own competitor that could become our best ally. This is what we decided to do. It's not easy when you have a product that is 10 years old; it's like a big cargo ship, not easy to change direction. Also, we have very long-term contracts with some companies. We have those millions of users. So if we want to make Strapi AI-native, it's going to take some time.

And the market window is right now. It's not tomorrow. It's not in two or three years. So we decided it was faster, better, and certainly a better decision to start a new product from scratch. We wanted to learn from it, apply those learnings directly into Strapi. We can fail with Strapi, but it's better to fail on a small product, apply those learnings on a very major product, and maybe something is going to happen with FIMO. We will see how it goes.

Awesome. So, when you first pitched FIMO, did you pitch it to investors and product leaders? What was the reaction, and did they get it immediately compared to what we are used to with Lovable, Replit, or Bolt?

The Agentic Web

I think when I pitch it, people get it. I spent the last three months of 2023 in San Francisco to actually be in the right mindset to build an AI-native product. The pitch with FIMO is pretty simple. We really think the web is going to be different in the sense that it was mostly built by humans for humans.

This means digital agencies and freelancers were coding manually on their coding tools, and the web was mostly browsed by humans, clicking, typing forms, and all of that. In the last two years, I think we have seen more and more AI coding tools, or we have more agents like Cloud Code and Cursor developing websites during the entire night when we are sleeping. They develop the website; they develop apps for us. When you wake up the next morning, it's done. It's working.

The web, I think, is going to be built by agents mostly for agents and humans. And I think that's the big shift we used to have. We can also call this the agentic shift. This means that agents are the decision-makers, and most decisions are going to be made by them. They are the ones coding, and we think it's also going to apply to websites. So they are going to be the ones maintaining those websites.

Yeah. They are going to add pages. They are going to update the content. They are going to see, "Oh, I see a drop in the analytics." Maybe you should try something else for the homepage. "I can see that your competitor just released a new feature, or they added this to their website, or they just changed their pricing." I think we should react. We should have a defensive approach, or we should maybe fight back.

Yeah. And this is what we are going to do with FIMO. We are going to try to help people build the first generation of autonomous, proactive, and intelligent websites, which is completely new. I think people get that; they also see what I see and what we see. That's what we are doing, but right now, when you test FIMO, we just built the first brick. So we are only providing the website builder, but we are working on the agentic part. I think most people will get where we are going in a few weeks.

Gotcha. So, you are seeing this wave of AI code generation tools. Instead of thinking, "Oh no, this is going to disrupt everything we do," you are thinking, "Yes, there's a massive gap that needs to be filled." So, let's talk about what you learned at Strapi that helped you see that gap. What I am interested in is what breaks a company that goes from 10 pages to 10,000 pages, and when does content management start falling apart?

When Content Management Breaks

I think we were talking about this before. Content management is like any company: when you start to grow, and you have only, let's say, 10 people, it's easy to just go in a room with those 10 people and share information, saying, "Okay, we need to do that; we need to update that."

When you are in a big group of 10,000 people, there will always be someone missing, someone who is sick, someone who is in a sales call, or someone who just cannot attend that meeting. So, the bigger you are, the bigger the communication gap starts happening, and I think it's the same for content management. If you have a website with 10 pages, it's super easy to maintain all of them. But if you have a giant website, you can think about adidas.com. They have so many pages. We are talking about maybe 10 or 100 thousands of pages.

It's super hard to maintain those pages, to make sure you don't have information that says the opposite, or to make sure that the new tone of voice applies everywhere on every page. Even if you have an army of content maintainers, writers, and editors, it's not easy. So this is where AI is going to fill the gap. AI is so good at manipulating text. It's so good at just browsing your website, and it will notify you of those gaps and fix them for you, or at least tell you, "Okay, you have a gap here and there."

Yeah. So, this is exactly what we are seeing with most of our users. It's easy to build a simple website, and it's really hard to maintain. I think maintenance is what we often forget when we build a website. We are thinking, "Oh yeah, I am going to use that tool; I am going to create those pages." It's super easy because you have a clear idea of what needs to be done. But when this website is live for three or four months, and you need to, "Oh, we just changed the pricing."

Actually, we changed the positioning, or we need to completely update our images because they are not fitting the brand anymore, because the designer decided to do something else. This is where the problems happen, and we have seen that for the last 10 years. I don't think software and the way we built and designed CMSs was truly helping to solve that problem. It made it easier to do bulk actions. But I think AI is going to really change the game for that problem, because you need to do human work but at a scale that a human cannot do.

Yeah. Yeah. Yeah. Of course, that makes sense. If you take traditional CMS platforms, they were built by humans, creating every bit of content. What needs to change now? As you said, sometimes people are not going to be there. What do you delegate to the AI versus the human side? We were having a discussion this morning with Jonathan from Upstream. He was saying, "Hey, I am discussing something on LinkedIn, for example, and I could see that I was talking to an agent." He could tell because he asked two different questions, and there was a smiley face in the middle of the answer, a rocket at both ends for no reason, and just the way it felt. It felt like it was an agent. Of course, he was saying relationships, you are not going to change that. And of course, there's a human side that you have to do.

I commented that now it's getting pretty scary, because you can actually say, "Match the tone of voice," or things that you would say. Sometimes you can actually prompt them to make mistakes or whatever. But when it comes to content, all these things, where do you think AI is going? And where do you see the limit? I don't know. I was actually writing an essay about this. Imagine tomorrow we don't manage the website in the same way we are doing it right now.

Where's the Human Limit?

In three years, during the Christmas season on apple.com, an AI agent decides to remove all other products except the AirPods. Yes, because the AI knew or knows that during that season, those products are selling the most.

This is where the margins are the highest, and this agent has only one goal: to increase or maximize revenue. Yeah. Is it a bad decision? It's like when you are also looking, I don't know if you watch those games where the chess player or the Go player loses against the AI made by IBM. I think this is a move, like move 37, that's super popular because everybody was commenting, "Oh, this is a huge mistake; the AI is going to lose." Actually, that was the smartest move ever; we just didn't know at that time that this was a new move, something new. If you apply that to content management, that move of just showing the AirPods, is it bad? If the goal of Apple at that time and the company is just to increase revenue and maximize profit, and this agent is making the decision based on a lot of data points, then maybe it's not bad.

Maybe they end up meeting their goals thanks to that decision made by an agent. I just don't know if it's bad or not. Maybe it's a bit sad to see that, but I don't know where the limits are. I think some companies would never let an agent manage their homepage, or at least they would just ask the agent to make proposals of what could be updated. But I don't want you to make any decisions. But I think for most pages, or maybe you can just identify some pages that are critical for your business. I don't want you to update the feature pages. For me, I don't want to update the contact page.

Do not update the homepage without asking for permissions. But I think for most of the pages, you don't care. If the tone of voice is great, if the AI has a lot of constraints, I think we can let agents do most of the work. And I think we can focus on something else.

Yeah. Well, I think when it comes to branding and the general feel of the website, so far I haven't seen anything super successful that can be replicated. There are emotions, things that it doesn't get yet. Even though it has data points, it's hard to create a real identity for the brand and leave that completely to the AI. I think there are some industries where it doesn't apply. Think about perfumes; the way you sell a perfume or fragrance is so unique, and each word is super important.

I don't think we are going to have an AI building the creativity of a human pretty soon. But for a SaaS company, often the tone of voice is not that important. It's always the same: it's friendly, it's concise.

Yeah, I think it can be reproduced pretty well. I think it will depend. And that's why we need to build CMSs that adapt to all those situations. That's why I am thinking a part of the web is still going to be, of course, managed by humans, but maybe a majority will be managed by agents. And I don't think it's sad. It's just that if agents can be as good as humans, maybe it means that we are not adding that much value, and we should maybe focus on the creativity part.

Workflows Nobody Actually Uses

Yeah. No, that is fairly true. So you mentioned review and approval workflows in FIMO. What did you learn in Strapi about how organizations actually ship content? Do developers even want to manage content?

We don't have that feature yet on FIMO. It's going to come at some point, but one of the learnings is that we have one good example. It's Adidas.

Mhm. When you are browsing the adidas.com website, you are actually seeing content that has been produced into a Strapi application. It's a giant one. They have 15 people working on it. They customize pretty much everything in it. And what we learned is that they are producing and writing that content 18 months before publishing it.

Wow. So it's huge when you are seeing content from a year and a half ago. Whoa. Maybe produced in 2024. Mhm. That's one of the best examples we have about how they need strong workflows because they have this unique publication workflow. But that's an exception. Most people think they need reviews and workflows, but actually, they don't.

They need that to reassure themselves. They need that to check a checkbox when they are doing research and discovering new CMSs. But to me, they don't need that at all, or they have it but don't really implement it. So I think they need boundaries.

They need to make sure they don't publish something to production without having someone reviewing it. But do they really need strict workflows? I am not sure about this. And most people are actually managing small to medium websites.

Yeah. And you often have one or two people managing the content on it. So I think you don't need that many workflows, mostly for big corporations. This is mostly our target for the enterprise edition of Strapi, so they are using it. But even if they are buying it, they don't really use it. I think it's about 15% of them using it in our customer base, and if you look at the entire user base, it's less than 1%. So it's kind of ridiculous.

Yeah. Gotcha. Well, sometimes you need those high-end features. Yeah. For some of your best customers. I was wondering when you realized that AI code generation tools were missing something fundamental. What was the moment that triggered that realization? I think it's even earlier than this. I remember having a board meeting at the end of 2022 where AI was one of the main topics. We asked, "Should we go all in on AI right now and be the first one?" It was even before ChatGPT, and with the board, we said, "Oh, maybe it's too early; the tech is not ready." That's true; it's not easy to set up LLMs, and we didn't have any APIs that were so easy to use right now. Then came a huge revolution in 2023. We have seen those coding agents getting better and better. I think one of the signals we got is that some of our customers started to tell us during the negotiation process, when they were buying the enterprise edition of Strapi, "Oh, I am going to just recode that feature." I think coding is one thing, but the other thing that we miss, and I keep repeating myself on this, is the maintenance. And maintenance is also cheap right now.

The Signal That Started It All

Yeah. If your customer who developed a small CMS or a small feature in the CMS left your company, you don't really care anymore. You can still ask an AI coding agent to maintain that feature for you.

Before, it was, "Oh, we don't have the documentation; he left with all the knowledge." But right now, we don't really care about this anymore. So I think the shift is that if people start to recode the features that we are selling, those features are actually worth nothing, or just a little. How do we fix that? What do we do? This is how we thought, "What if we create an AI-native CMS that embraces AI from the very beginning at its core, instead of trying to put AI on an existing product where it's going to be slow?" So I think that was the signal. The website building market is a giant market. We are talking about billions of dollars of revenue each year, and it's still growing 10-15% per year. So it's huge. The number of websites being published every day is just increasing super fast. You have different categories. You have the people who were manually coding, like the IDE category, people using VS Code and Cursor, building their website manually. You have the CMSs, like WordPress, where you can build a real website using it. You have the visual platforms, like Framer and Webflow.

Vibe Coding Is Eating the Market

Yeah. And you have the website builders, mostly Squarespace, Wix, Odoo in France, and many others. I think all those categories, which are subcategories, but the main one, the website building category, are being eaten by the vibe coding category. Do you really need a visual editor if you can constrain the AI to use your brand?

Do you need a CMS if you don't really need workflows and you don't manage a website with 13 different languages, and you have only one or two people going into the administration panel editing the content? Do you need an engineer to be involved in the creation of your website if an AI coding agent can do it for you? Prompting is so easy that using Wix or Squarespace is great, but they all look the same. You are using a template, and you can personalize it a bit, but it's quite limited. If you are a doctor and you want to create your own website, or a chiropractor, you just prompt it, and it's super easy. You get something that sounds unique or looks unique to you, that looks personalized. So you have this IKEA effect of, "Oh, I built something," so it's much more rewarding than going on Wix, finding the right template, and saying, "Okay." So I think for all those reasons, the vibe coding category to build websites...

It's going to be huge, and maybe bigger than the entire market, because it's not only for professionals; it's a consumer mass market opportunity. We don't know where this is going, but this is my belief right now. I agree that I have seen many small creators, young or old, who were missing a certain amount of hard skills, and now they are able to actually launch things that are crazy. There used to be that gap between what's in your head and how it materializes in real life, and usually that used to be the gap.

I have worked with a bunch of doctors, and I know doctors always have crazy ideas about this and that. But putting it from the idea to production, even finding the proper talent, like finding good developers who will be able to tell you, "Hey, this stack is the right thing for you," was difficult. Because you don't have to have something crazy now; honestly, you can just go and use natural language and get something out of it. Plus, as you said, you get the satisfaction.

Yeah. You build something for $50. Which is ridiculous. Before that, you had to find an engineer, a freelancer, whom you would have paid a few thousands. So, it's super cheap as well. It's faster and cheaper, and you have more control. So, I think that's unbeatable. You can't fight that.

Fimo vs. Lovable

Agree. I agree. So, here's where we get into the meat of what FIMO makes different. And I want to be really precise here because I think there's a lot of noise in the AI builder space right now. Everyone's promising fast websites. I think they are promising assistance also. But you are making a very specific claim: that FIMO ships a real content structure that AI can reason about and manipulate. So that's the thesis. So let's unpack what this exactly means. If I need to launch a product line landing page—landing page, pricing, features, FAQ—in four languages in two weeks, walk me through FIMO versus Lovable, for example. What happens three months later when I need to update everything: pricing everywhere, all those things?

I am going to share where this is going to be once we develop FIMO in six months. But if you do it with Lovable, that's a great product; what they are doing is amazing, actually. But it's really made to build apps, and apps are different than websites. So a website is about displaying content, promoting content, promoting your brand, promoting your product. It's not there to build an app that helps you to translate or learn Italian.

This is not what we are doing. We are helping you to build marketing corporate websites or personal websites. So if you do it on Lovable, you will prompt it. It's going to work. You are going to have a website.

The UI is going to be okay, good. They kind of all look the same. I think we are better on the UI aspects. And the content is going to be generated during the code generation. I think it's going to be aligned with what you had in mind. It's going to create the pages, and if you enable Lovable Cloud, you will have your content maybe saved in the database if you ask for it.

So the first thing is that if you don't ask Lovable to store your content in a database, the content is static in your code. Also, the way the websites are coded is not optimized for SEO. This means they are not optimized for SEO. This means search engine optimization. This means your content is not going to be visible in ChatGPT, for example.

So first, their websites are not optimized for visibility. The content is always stored in the code, except if you ask for it to store it in the database. And if the content is in a database with three different languages, you just have access to it. It's using Supabase, so you have just a very raw interface that is mostly made for developers to edit your content. You don't have any rich text editor. You cannot easily make some parts of your text bold or italic. So, formatting of the text is quite difficult. You don't have a media library. So all the assets are not going to be easy to manage. If you want to replace one, you need to always upload it via the AI. So, you are going to burn a lot of credits.

Yeah. So, that's the current experience with Lovable, but it's the same with Replit, Vercel, and all the others. When you use FIMO, what really changes is that we build a website, I think we are offering a better UI, and we have three different agents working in the background. There's one doing the design of your website, one coding your website, and another one managing the content.

What Makes Fimo Actually Different

The content created is not exactly the same. It will better fit your brand, industry, and goals, and we always store the content in the CMS. This means in a database, but with a way better interface to manage it. So you will be able to see it, edit it; you will have rich text, lists, selects. You have a real CMS interface to manage your content at scale in many different languages, and we also offer a media library. So you will see all your media in a clear tab. You can replace them.

You can generate new ones. All of that, and because we have made the content structured, we can play with it. This is how we always have a view of your entire content on your website. If there's a competitor, like I was mentioning this example, who updated their pricing page, or updated their homepage, or their positioning, we can compare it with your entire content. Because it's something that's available as a context.

Yeah. For the agent, which is not really the case for Lovable. It's just part of the code. It's the static text.

But we can manipulate that content, and we can do whatever we want with it. We can translate it easily. We can change the entire tone of voice on all the pages at the same time. It's not part of the code; it's something outside that's being injected. So it's faster and easier to play with it. So that's the main thing. And then we will have these agents that are going to watch the web for you, watch your competitors. If you have a good discussion in a thread on Slack, you can ask FIMO directly in Slack and say, "Okay, convert this thread into a blog post for the engineering category." Then you have a preview URL coming back, and you can see, "Okay, that's amazing." I have my blog post ready. Or you can say, "Every two weeks, I want you to write a blog post about all the updates that happen on our GitHub repository."

Those things are really optimized for marketing corporate websites. Lovable is never going to offer that. That doesn't mean you can't do it with Lovable. You have to create your own agent. You can do it, but not everybody wants to build their agents. We are the ones maintaining the prompt. We are the content experts, and we are doing the job for you to optimize your visibility. It really depends on the goals of your website. That's something we are actually going to capture: do you want to optimize signups, the number of demos? Do you want to maximize activation or MQLs?

You will tell us, and the agents are going to react to those goals.

Yeah, that's funny. How do you use analytics to actually base your decisions? As you said, there's the content itself, but then the content usually serves a purpose. So how do you make sure that the agent understands what the goal is, what the funnel looks like, and then what metrics to play on?

Do you have integrations with proper analytics software, or is it coming? First, we want to build this agentic system that brings autonomy to the website. Then we are going to bring the data that helps this autonomous part to be even better. So it's going to come in different milestones.

But it's going to come. Yeah, this is super cool. And so if you take Lovable, Bolt, Replit, they are fast. They are getting traction, obviously. Why can't they add a content layer in V2?

Why Can't Lovable Just Add a Content Layer?

They could, but they didn't think of their product this way. They are not targeting exactly the same audience; as you said, it's more applications rather than content websites.

They are building apps. Bolt is great to build mobile apps, for example. They have a great integration with Expo. Lovable is mostly going to replace software engineers. We spend a lot of time on the UI part. They could do it as well. But you don't have the same kind of UI for a marketing website and an app where you need a dashboard and all of that. We have some exclusive partnerships for the media. Our media looks better than the others. When you start seeing what needs to be done, we need to optimize the SEO. So the way we generate the website is not the same. It's costing much more than the way they do it. We will need analytics. We need to have those autonomous agents that are going to collect specific information about your competitors, your industry, your goals. We need to collect information about your main topics, like the critical page that you need, the tone of voice, and the SEO. Those are verticalized software optimized for building corporate marketing websites.

They could do it, but I think that's not their play. I think the market is so big that there is a place for everybody.

Yeah. And so one of the things that I love about doing this podcast is that we can extract lessons that go beyond the single product and talk about the entire industry where it's headed. And I think FIMO represents something way bigger than just a website builder. It's also a bet on how AI will fundamentally change what we are building and how we manage digital products. I think it's a bet on what it means to be AI-native that we talk about so often.

What Does AI-Native Really Mean?

So to you, what does it mean to be AI-native? And can you give me something concrete that you do at FIMO that you couldn't if AI was just not bolted on it?

I think any product can be transformed or translated from a non-AI-native product to an AI-native product. We could have done this on Strapi, and we are actually doing it. It's just going to take a while because you need to change the UI/UX of your product so much. When you have tons of customers and users, it's just slower. You can't change everything radically. People are not going to like it, and you are going to lose trust and all of that. One of the principles we have at FIMO, for example, is that we never start from a blank page.

So you never have this feeling of, "Okay, I want to create something new," and all the values and fields are empty. No, we always say, "What do you want to generate?" Either it's an entry, like a new post or a new image, tell us what you want to do, and we are going to generate the first version for you. Then you can iterate over and over.

I think that's the first thing: the AI can avoid the blank page, which is something that happens very often when you use a product. You click "add" on a Notion page, for example, and it's blank; you have nothing. You can use their templates, but I think it's way better when you click "add a new page," and it asks, "What do you want to build?" Or, "I would like to talk about this, but I don't know how to structure it." This is why AI is so good at helping you structure your ideas into something tangible for the users. The other thing, I think, is that the stack is so different compared to another product.

We don't use the same billing system. We don't use the same observability systems. I think 90% of the code is being AI-coded compared to what we used to do with Strapi. The way we work, and the way the product is being built, is also different. We don't open tickets in Linear to do QA. Our engineers, our designers, even myself, we all vibe code and fix the issue when we see them. For example, "Oh, this button is not correctly positioned; there are two pixels missing." I am just going to vibe code and do it and ship it. This is completely new compared to before, when I would have opened a ticket in Linear. I would have recorded a video or taken a screenshot, and I would have posted that in the sprint or in the backlogs. Then an engineer, a week later, would have asked, "Are you sure this is this button or the other one?" So you start to have a discussion, and it's been shipped for the next release, which would have taken two weeks. Now it's taking two minutes.

So I think it's not only about the product itself and how you build it. The UI/UX changes a bit. The economics around the product change. The mindset of how you build the product, but also the processes, are completely different. We have been able to redo a lot of the features that are available in Strapi with a team of three engineers, one designer, and myself in six months. So, when you compare it to how much time it takes to create something like Strapi, we also learned so much from Strapi. So we apply all the learnings from all those years. I think you can't really compare it, like if we were starting from zero and we had to build a payment billing system, it would have taken years, even with AI. So, I think it's not fair to compare it this way, but still, you are faster, and you are building those products completely differently, but it's mostly by the mindset.

Have you noticed a shift because you said now you can do it super quickly? Have you noticed a shift between engineers and product people? I know that at Lovable, I think they have this concept—I forgot what it is—but it's product engineer. I was going to say product builders or whatever, but yes, product engineers, in the sense that now everyone is building. But have you seen a shift in ownership between what devs usually did and product? Is this something that developers value, or is this something that they fear? Everyone is having this discussion about who is going to die first. I think we are going into more of a hybrid final product, and people are just going to have better skills or stuff like that at some point. But what have you seen in terms of shift?

I don't think those roles are going to merge, but definitely the scope of each role is being reduced. This means that a product manager or product designer used to never code, or rarely, even if they have some technical skills. Right now, they can code and fix the small issues, or they can improve the responsiveness of your product. This is doable for them using AI tools. So it removed those tasks where the engineers were not adding a lot of value.

It removed those tasks from their backlogs, so they can focus on something else. But they are also not only doing more on the deep tech side, but they also have more time to think about the products they are building.

And what I am seeing is that, yes, they are much more involved in the discussion. They are challenging the UI/UX even more. The designer can really also talk. I think it just kind of balances the discussion between the tech and the non-tech people. And we just go in the fastest way. But I think we are not replacing those roles. They are just getting closer to each other. And there are, of course, roles that are kind of disappearing. For example, so far we have no one managing the documentation; it is being generated by AI.

Yeah. I still think we need someone to have a view on the documentation. And you still need to think about the way you structure it, all of that. But most of it can be AI-generated. And I think AI products are so much easier to use compared to other products. So you don't need that much documentation. And most of the roles, especially the product management roles, are being kind of automated. You have more time thinking. You are not writing a transcript of your meetings. You are not doing the triage or categorizing of your different problems and feedback you got. You are not writing user stories anymore. You are not opening tickets and doing very long backlog reviews because everybody can just chip in and do their own stuff. So you save so much time by automating your role that you can really talk with more users. You can have more time to really know your competitors and test the product, so you can develop your product sense even more. So you have more time to just feel your market and make better decisions. I think it's great for the role, actually, because I don't like to see PMs spending their time doing tasks that can be done by AI, where their real value is about making the right decisions.

The PM Role Is Being Automated

That's true. What skills do you think PMs have to build currently? Where you want to be AI-native, let's say, and not for traditional products, what's the difference? What are the unique failure modes? I think we are just going back to the roots of that role. You need to control where your product is going without controlling it.

Yeah. So, without controlling your team. You just need to set a clear vision.

That's why it's super important to know your market, to know your competitors, and to have what they call product sense. Only senior PMs have it. And that's funny because you don't need to do a lot of user research. If you have an idea, you build a prototype. If you have 10 customers saying, "That's amazing, I want to buy this thing."

It goes to production, and they develop it. But only senior PMs that really feel the market can work this way. But I think as a PM, you need to embrace AI. You need to automate all the boring tasks. Even if you like to write user stories, stop doing it; you are just wasting your time.

It's more about being nostalgic than actually helping your company add value. Yeah. I think each PM should have a suitcase full of agents. Whenever you are going to work for a company, you have your agents; you can address them to the company's workflow, but automate your job. Spend more time looking at your competitors, spend more time understanding the market, test all the new products, all the new stuff that are actually being released, not only in your field, but there are so many things happening in the AI field. This is what I am telling the PMs at Strapi: it's okay if you spend two hours doing an active watch on X, LinkedIn, or Product Hunt, and all of that. It's going so fast; you need to keep the pace. So if you automate your job, you have more time to do those things. Try to make sure the engineers are super motivated; they have the right mindset; they really understand the product; they really understand the audience, because that's always the same thing. They are going to be super proactive; they can ship super fast, but if they ship in the wrong direction, you are just losing time. So, make sure that they know who is going to use my product.

When Engineers Ship in the Wrong Direction

For example, at FIMO, we had this example that was a small, quick learning for us: the engineers were shipping so much that they loved the code part. We have three or four different tabs in FIMO. You have the preview when you see your website, the content when you see your content, the assets when you see the media, and the code when you see the code. The engineers liked to do so much stuff around the code part; you have a super search; you could follow other engineers and follow them coding; that was amazing. But none of our customers are actually coders; they don't know how to code; they don't care about coding; they just want to build websites. So it makes no sense to develop this side of the product right now, just more to maintain something where we can have issues. If people see that it's going, we are maybe going to receive feedback about, "Ah, maybe we should do that," when none of our people paying for it actually care about this. So I have to do my job and say, "Okay, that's the wrong direction, and we need to remove those features." Actually, this is what we have done: the next day after the release, we removed those features because that was not matching with the customer profile at all. That's still our job as PMs, to set the direction.

I remember, actually, it's funny that you talk about that, because I remember that was one of the reasons I jumped on a discovery call with you. I don't remember if it was September or November; you said maybe November. Yeah.

Yeah. You told me, "Okay, I am building something; just try it out." So I played with it, and then when you were looking at the result of what I had done, you were like, "You are definitely not a coder, because I wasn't looking at it at all." You said, "We built this, and you are not looking at it at all!" But that's true. That's true. But again, you never know. Now I feel that you get a good grasp of who your customers are and where you are adding the most value.

Yeah. But that's why, even if you let the team build stuff, you should let some space for that. You never know; it could be a great idea, and everybody can have great ideas. They have their own way of feeding the product and feeling where this market is going. So you should let them do stuff, but you should always control in some way, making sure they don't go too far in a specific direction until we get signals and data points. But that's true. So maybe we are in the final section, and I want to make this as practical and forward-looking as possible.

The product is live; people are using it, and you are learning in real time. Let's talk about what you have learned and where you are going, and what advice you would have for people who are building AI-native products. What's the most surprising thing about people who use FIMO, and what's one thing that was harder than expected?

What Fimo Learned After Launch

I think one thing that's surprising is that our first customer is Chinese and uses FIMO behind a VPN. Mhm. So we had some issues because of the VPN, and we had to fix them. That was unexpected. I didn't expect it, because we didn't mostly launch; we had done a soft launch. We mostly expected to have European users. Actually, all our customers are from China, UK, US. They are not from Europe. So that's one of the most surprising things. The willingness to pay for those products is maybe not the same in Europe. And the first customer is actually a consultant who helps you import your business in China.

Mhm. I thought we would have maybe a small startup or someone launching a landing page to get emails and leads. Instead, we got just a very simple website of a guy promoting how to import a business in China. So that was surprising. The other biggest learning is that, as I was telling you, none of our customers—I know them all—none of them are good at coding.

Yeah. They are not afraid of seeing code, but they don't code at all. And I kind of had this gut feeling that this would happen, but I was not sure, and the team was not so aligned with that. They were sure that some developers were going to use that, actually. No, nobody is going to use it. So that's good. Another thing is about the churn: I expected people to convert, to buy, to get more credits, but so far, we didn't get any churn.

But I think people are also seeing the value in the first use case. And I think we have a better hook because there's no way to escape from FIMO when you start from it right now. So if you want to publish a website, you need to stay on FIMO and you need to keep paying.

Yeah. So those are the first learnings. I think one thing I almost regret—it's not a mistake—is that we should have launched way earlier, even if the product was not good when you tested it in November, for example. You had tons of issues; it was not stable. But I think we should have launched it anyway. Even if I know that because I watch a lot of podcasts and listen to a lot of product experts, you always have this feeling that if I am launching too soon, the first impression is going to be bad, and I am not the first one on this market. So people are going to say, "This is not stable; fix your thing, and then go back." You also want to do a good product when you know the first impression is going to be correct or good. But you are also going to be late. So I think we waited too much to have a product that was working well. But anyway, we got our thousands of users. We have our first customers. We are learning a lot. But this is: do not ship.

Do not wait. Ship. I think that's always a rule in life, especially when you are an entrepreneur. But now, as I said, you are seeing that daring is going to be what differentiates people who succeed from those who don't. Because now you just have to try and iterate.

What I feel with Lovable and other tools is that it can get to a point where you get frustrated. Whereas you do a more consistent job; at least so far, I have seen that it's more consistent, especially when you want to build a website. Mhm.

Advice for Founders & PMs

What do you think for founders who are building AI-native products? What's the first decision they need to get right? Do you think retrofitting AI into existing products is a mistake to avoid? I think one thing is: do not optimize the economics right now. We know that on AI products, the margins are not like they used to be with SaaS. So do not expect 80-90% margins. Mostly, it could be around, for example, Lovable and Vercel had negative margins for months before optimizing their systems. That's something we are doing with FIMO: we don't have negative margins, but we have zero margin. We don't care about the margins. We want usage. We want to grow the usage. We want to see traction, and we know we could use other models. For some tasks, we could stop using code and other models. So do not work on that; just optimize for the usage. The more credits you can give to your users, the better.

So I think that's my advice for the founders: do not work on the economics, even if—and that's why sometimes you need to raise a bit of money—because it's going to cost a lot.

Yeah. For PMs building AI-native products, I think you would have to change your approach. If you are working in a company, depending on the size, like us, a Series B company with almost 100 people, you cannot innovate with 100 people being involved. That's one thing we have done right: innovation always comes from a compact team.

So you need to have a very small team that's super lean, where you remove all the constraints. We pulled three engineers, including our CTO, one designer, and myself. We told them to work for six months in another room, in a private channel, and work in isolation from the rest, because everybody wants to be involved. Everybody wants to test your product. You will have the support team saying, "Oh, we need to set up the support."

I am glad we didn't do it. We have zero support tickets since we launched FIMO. Yeah. So I am glad we didn't spend weeks with the support team setting up a new workspace or thinking about the workflows. Same for the documentation. Nobody is complaining about documentation. It's fully AI-generated. I spent just a few hours doing it. I am glad I didn't involve our documentation team.

Yeah. into that process. By doing that, I think I protected them from distraction, and they can actually focus on our main product, which is Strapi.

So that's another piece of advice for founders. If you already have a company and a non-AI-native product, if you want to create one, create a small, separate team. Be okay if that team is not part of the process anymore.

For example, we have another billing system where we used to use Chargebee. I would not recommend that software, by the way. We are using Appwrite right now for FIMO, and it's the same for support; it's another software. The same for documentation; it's another software. No constraints, small team, lean process. For PMs, if you are in that situation where you are working for a non-AI-native product, your fight might be to talk to the founders or talk to the people making the decision. We have two options. I think you are going to be in the same position as we used to be: do we wait if the market window is right now, or do we have just two years ahead of us? Is it enough to completely change the direction of our current product, or is it too big already and too slow to change it? Or do we start from scratch with a specific target, specific segments, and small features?

I think that's where the decision is. As a PM, if you feel the market, if you know the competition, if you know where this market is going to go and what's the direction, you might have to go to a higher level and ask the right question to your leadership team. Gotcha. You might not be able to do a lot of things at your current level because, I think, for most companies, it's what we are doing. Actually, with Strapi, when I was in the US for three months, I have seen 80% of the companies doing the move we have done. That's not something I am seeing a lot in Europe, so maybe we are afraid; we are conservative. Maybe we don't see the risk the same way. So, to wrap things up, what keeps you up at night? What are you most excited to ship? I think I can't believe that the web is going to be completely different in five years. I even think about this idea: are we going to have a browser that only displays human-created content?

What Keeps Aurélien Up at Night

Mhm. Because I think the web is going to be full of agentic content, like video and media. We just don't know what's going to be real. I don't know where this is going. I want to support this because I think there are a lot of benefits for the world in doing this. But at the same time, I just don't know how the web is going to look in five years. So I am not concerned, but I am trusting the industry leaders to make the right decisions, and we are going to find solutions to our own problems. But what we are actually doing is creating the way to have this agentic web.

Yeah, I want to be part of it. But at the same time, I know it's going to create a lot of issues about whether we can trust what we are seeing on the screen. And I think the answer is no. You can't trust it anymore. So, I think the creative jobs, like real-life experiences and artists, are going to have to play a huge role in offering something else for us citizens, humans. Because what we are going to see on the web is going to be different.

And maybe that's for the good, because it means we are going to spend less time watching screens, hopefully.

Rapid Fire questions

Wrapping things up, I just have a couple rapid-fire questions. So, what's the best product decision that you made in the last six months?

To fully delegate my job to our product.

Oh, that's super important. If you could have one feature in FIMO, what would it be?

The full autonomy of websites.

Amazing. And what's one thing that you believe about AI that most people would disagree with right now?

I think it's not going to replace jobs. But it's definitely going to redistribute jobs. If I can explain that, it means that I think all jobs are still going to exist, like they exist in factories and all of that. It's just we don't need exactly the same skills to do the same job.

And so, five years from now, what do you want to be known for?

I think to have created a new generation of websites. I think we have those simple static HTML websites. We then have dynamic websites, and we are going to have the autonomous website, and I want to be known for this.

This is great, man. Honestly, congrats for everything that you have done. As you know, Strapi, I was already a big fan. There are two companies that I worked for where I brought Strapi, and I think it made things completely different. Now, FIMO, it's great as well. So, congrats on that launch, and I really hope that five years from now, you will be known exactly for that.

Awesome. Thank you for being here, man. Thank you. It was nice.

And that's a wrap on this conversation with honestly one of the more grounded takes on AI I have heard in a while. No hype, just someone who has been in the trenches for 10 years and knows exactly what's broken. If this episode made you think differently about how websites get built and maintained, share it with someone who needs to hear it. And if you are not subscribed yet, now's a really good time. There's a lot more of this coming. Links to FIMO in the description. Go check out Building.

Thank you so much. I am Cedric. This is the French Product. I will see you in the next one.