Pierre Burgy and the price of giving it away

Pierre Burgy helped build a piece of software anyone could download. The awkward part was finding enough time to work on it. In the beginning, he and his co-founders were students who paid their way with freelance development. Clients had requirements, deadlines and invoices. Their own project had whatever hours remained. Giving software away was straightforward. Paying for the people who maintained it would take considerably more invention.

The problem began with ordinary web work. At HETIC, Burgy, Aurélien Georget and Jim Laurie were building websites and applications while studying. They wanted to use JavaScript across their work, including newer frontend tools. Traditional content management systems imposed constraints that became particularly irritating when content also needed to reach mobile applications. The three developers made a tool for their own projects, then discovered other people wanted it too.

In October 2015, they published Strapi on GitHub. Its name condensed a practical instruction: Bootstrap your API. There was something appealingly unceremonious about that. An API is a way for software systems to exchange information; these students wanted to make creating one less laborious. Their answer would eventually become a company. For the moment, it was another responsibility competing with coursework and client requests.

Burgy’s route into the work had included an earlier detour through real estate before he turned toward digital technology. The interesting part of that change is its scale: a career direction became a technical education, then a shared problem with classmates. His entrepreneurial story grew out of work he was already doing. The eventual market was large; the initial irritation could fit on a freelancer’s desk.

A website learns to lose its head

The technical choice explains much of the human story. In a conventional CMS, the content and the machinery that presents it are closely connected. A headless CMS separates those jobs. Editors manage their material in one place, while developers decide how a website or an application displays it. The content travels through an API. One store of information can therefore serve several destinations.

Burgy has written about this change as part of the web’s longer history. Static pages gave way to systems that let more people publish; phones and other devices created more places for that material to appear. In that account, open source keeps returning as a way for different pieces to work together. Strapi belonged to a continuing argument about who gets to build, modify and distribute the tools of publishing.

For Burgy’s team, access to the code had immediate practical value. Clients could run the software on their own servers and developers could customize it. Those decisions also gave outsiders room to contribute. Yet permission to inspect a codebase does little for someone who cannot get started. A useful tool still needs a comprehensible entrance, preferably one without a three-hour queue of configuration errors.

In the early years, the team posted on Reddit and collected feedback. Tutorials became a deliberate means of reaching developers in 2017. Burgy described teaching people to build something concrete with Strapi and complementary technologies, rather than expecting documentation alone to do the selling. That approach suited a founder who had first encountered the problem as a working developer: demonstrate a finished task, then let curiosity take over.

The first customer was also a distraction

Client work financed the early effort, but it brought a structural problem. Every bespoke request consumed time that could have improved the shared product. By 2017, the founders wanted to concentrate on Strapi. Raising money offered a way to buy back their attention. It also required persuading investors that software freely available to everyone could support a company with salaries and obligations.

The first fundraising process lasted nine months and the company’s bank balance went negative before a $1 million pre-seed round closed in June 2018. There was another uncertainty to settle: users were split between building custom APIs and managing content. The founders tested willingness to pay with a pricing page and chose to concentrate on the headless CMS. Even the product’s identity had to earn its place.

A $4 million seed round followed in 2019, then a $10 million Series A in 2020. The investor list eventually brought Burgy into the orbit of founders and executives associated with businesses such as Docker, Vercel, Algolia and Netlify. Those connections put Strapi inside a wider developer-tools economy. A school project was becoming something other builders were prepared to finance.

The funding did not settle the business model permanently. Strapi introduced an Enterprise Edition in 2020, selling additional capabilities around the community product. Burgy later emphasized keeping those editions on a single codebase. Maintaining separate versions would create its own expensive tangle. His account of the early financing also became more cautious with time: he would no longer recommend raising on community traction alone without evidence of revenue.

The office gets smaller. The map gets bigger.

In June 2022, Strapi announced a $31 million Series B led by CRV. Burgy’s plans included a hosted service, a plugin marketplace and improvements for the people editing content. The division of attention mattered. Developers choose much of the infrastructure, but editors spend their days inside it. A technically elegant system can still make changing a paragraph feel like an administrative hearing.

Strapi Cloud opened to invited users in early 2023. It bundled work such as deployment, database storage and content delivery, while preserving customization. That added a different reason to pay: someone else could handle the infrastructure. The company could offer both a tool customers operated themselves and a managed route for teams that preferred to spend their time elsewhere.

Burgy took the distinction seriously enough to make it the subject of a 2024 talk on selling SaaS versus open core. A hosted product and paid extensions to self-hosted software bring different routes to customers. They can also pull a company toward different kinds of organization. The question of what to sell had become inseparable from the question of what sort of company he wanted to run.

By 2023, Strapi had given up a physical office and described itself as remote-only. Burgy’s public biography explicitly connects him with remote work and organizations that put people first. A team photograph from that June gives the policy a less abstract form: colleagues gathered outdoors, with some absent teammates present on laptop screens. Even a company spread across countries sometimes needs everyone to squeeze into one frame.

“We definitely listen to the community.”Pierre Burgy

A birthday, followed by a repair list

On October 1, 2025, Burgy marked ten years of Strapi. The anniversary figures included more than 20 million downloads and production deployments at more than 3,000 companies. They described the reach of a shared project rather than the size of his personal fortune. By then, people were also building plugins, businesses and their own working routines around software that had begun as the founders’ solution to a recurring nuisance.

Two months later, his message was more uncomfortable. A December post acknowledged that the pace of new features had affected stability. Community requests were concentrating on error handling, performance and basic reliability. Burgy described the strain of maintaining the Community Edition, Enterprise Edition and Cloud together. Revenue paid for the project, while the project depended on a community with its own perfectly reasonable list of things that ought to work.

His response included more attention to fixes, documentation and reviewing outside contributions. The specifics were wonderfully resistant to launch-day glamour: media-library behavior, relations, bulk operations and filters. A founder can promise the future in a keynote. Someone still has to make the present function on a Tuesday afternoon. Burgy’s public priorities now included doing more of that work.

The January 2026 review placed those obligations beside new capabilities. Strapi had shipped Live Preview and AI tools for creating content structures, generating media descriptions and translating material. The ambition was to reduce repetitive work for both developers and editors. The repair list remained a useful companion to that ambition: saving people time begins with avoiding fresh ways to waste it.

After the machine has built the website

Burgy’s next move returns to the place where the story started: the gap between making a website and keeping it useful. Fimo, built with Georget and a team drawn from Strapi’s world, focuses on websites created with AI coding tools. Its premise is that generating code leaves plenty of work behind. People still need to edit content, manage changes and keep a live site current.

Fimo’s September 2026 launch described agents preparing tasks such as translations, internal links and content refreshes. Changes pass through review before reaching production. That design assigns ongoing work to software while retaining an accountable human decision. Burgy is now asking how a team should operate when some of the contributors can produce changes at machine speed. Someone still has to decide which changes deserve to be published.

There is a commercial evolution here too. Fimo describes itself as a proprietary service, with customers retaining their website code and the ability to move it. The emphasis on ownership survives in a different arrangement. It would be too tidy to treat a decade of experiments as a single doctrine. Burgy has repeatedly adjusted the business around the work customers need to do.

Away from that work, his biographies mention windsurfing and mountain biking. His public GitHub profile offers another small joke: the location is localhost:1337/admin, Strapi’s familiar development address. A founder with an international business has supplied directions to an administration panel. After years of explaining APIs, perhaps he can be forgiven for finding the address more expressive than a pin on a map.

The thread through Burgy’s career is an appetite for removing the next obstruction: a rigid CMS, too much client work, difficult deployment, unreliable features, a website that needs attention after its code exists. Each solved problem exposes another job. That makes for a less convenient ending than a funding announcement, but a more recognizable working life. The project is public. The work keeps coming.