When a software engineer bumps into a problem and discovers the market doesn't have a solution for it, they just don't give up – they build it themselves. In 2017, Guillaume Monnet, a French developer based in Luxembourg, went through that process himself. As part of the technical team at a bank, he frequently struggled with testing and prototyping, especially given the need for tight security in such an environment.
This led him to create a developer-focused tool to make these processes easier, but the dev community quickly appreciated what he initially built to meet his own needs. ⭐️ With over 800k downloads and a +7000 GitHub star count, Mockoon has grown steadily over the past eight years, helping huge brands like Booking.com, Impala, or Amadeus manage their testing more easily.
Despite knowing the challenges of growing a project alone, Guillaume has kept his focus on building a tool for developers by developers. In this interview, we chat with him about the challenges of bootstrapping your own project and the current state of the industry for software creators. Pour yourself a cup of coffee, and let's get started! ☕️
🤿 How API mocking works 🔗
Hi, Guillaume. Congrats on the product. We are using it internally!
Hey! That's awesome. Thank you so much for using Mockoon and for supporting us over the years!
What is Mockoon's mission, and what kind of problems does it solve?
Well, it started as a side project nearly eight years ago. I created an MVP out of a need that my colleagues and I had at work, which was quick and easy API mocking. It wasn't something that I invented (far from it!). It's a developer tool for developers: any dev who's working on the integration of an internal or external API (like a payment provider such as Stripe or Localazy's API) may not be able to access it right away if it's a production-only API or if it's still under development. Mockoon is used by front-end and back-end teams to simulate that API. 🖇️
"API mocking is basically creating an imitation of the real API to simulate that you have access to it. [...] For those who are unfamiliar with it, a good analogy I've heard is that it's like a false hand"
API mocking is basically creating an imitation of the real API to simulate that you have access to it. Your front-end application (mobile app or website) connects to the API to get some data. If the API is not available, you have to simulate it somehow. So, the idea is that you have software that mimics the real API. Usually, it's not an exact replica because it's very complicated to replicate the behavior of the real thing. But you may simulate the most common data you receive, which saves you time.

How do your services integrate with other software workflows?
It's pretty easy. You download the desktop application, launch Mockoon, and instead of making all the calls and requests like a real API, you just have to do some setup work (like creating endpoints and API routes) and launch the mock. Your app will connect to it, and you can continue working on it. Then, you can use it regularly for any kind of API needs (it's particularly good for prototyping).
For example, if you're working on a specific feature and you start wondering what it will look like, instead of creating an account on a provider's website, you can create a small endpoint, put some fake dummy data in, and immediately start working. You can also use these endpoints during manual and automated testing, which is probably where API mocks are the most popular.
Who are your customers?
We have all kinds of users, from developers working at DeFi startups to more traditional companies like Walmart. I mainly talk to them through support requests and user interviews, and I found out that we have many teams working in the finance industry. Most of the time, they use Mockoon during their tests (automated or not).
You mentioned the finance industry, a sector that you know very well since Mockoon was created when you were part of it. How do they use the tool?
Yes, I was working in a bank when I created the tool. We couldn't use any cloud service, so I did it as a desktop application. That's why Mockoon is privacy-friendly and security-aware. Recently, one team from a bank decided to migrate to Mockoon because they couldn't use the cloud. I wouldn't have expected that seven years ago!
Paradoxically, we are now creating a paid cloud version for people who don’t want to self-host. Of course, we’re keeping both options because it’s important for us to stay true to our open-source community. It’s also a way to help make the project sustainable in the long term.
👀 Curious about the project? Check Mockoon's full documentation here
👨💻Creating Mockoon 🔗
How was your journey creating Mockoon? And what was your experience and background prior to that?
I'm a full-stack developer, mostly specializing in the JavaScript ecosystem. I started coding in high school, where I worked with PHP, Java, and icon design, so it's an old passion of mine. I was previously a lawyer specializing in intellectual property, but I switched careers in 2015 when I started working on bigger dev projects. One of them was a social network for pets that I worked on with a friend. It was a fun experience: we had several thousand users, and even though we didn't succeed in the end, it helped me during the career-switching process. Then I started to work as a full-stack developer in Luxembourg, and the rest followed.
"I was previously a lawyer specializing in intellectual property, but switched careers when I started working on bigger dev projects. [...] By 2021, Mockoon had grown so much that handling support requests in my free time wasn't sustainable anymore, so I decided to go full time"
Did passion play an important role in the project?
Passion definitely played a role. I mean, I was working at a bank and we couldn't use the cloud, and Postman's mocking option was good, but it required it. And at that point, I told myself, "I'm a developer now. I should do something". 🤔
I had switched careers to do what I love full-time, but I still wanted a side project to work on. So I decided to create this tool. After launching it on Hacker News and Reddit, people responded really well. They gave great feedback, requested new features, and encouraged me to keep working on it. By 2021, the project had grown so much that handling support requests in my free time wasn’t sustainable anymore. So, I decided to go full time, and now, this is my main focus.

Why did you decide to make Mockoon open-source?
At first, Mockoon wasn’t open source. I didn’t really think about it. I just published the desktop application on a website and set up an empty GitHub repository so developers could report issues. But not long after, people started asking if the project was open source. They noticed the source code wasn’t in the repository and pointed out that open sourcing could build trust. Since I already used many open-source tools, I realized it was the right decision. I wasn’t contributing much to open source at the time, and this felt like a great way to give back to the community. At first, I had some doubts. Making the project open source could attract more users, which was great, but I worried it might take away the chance to sell it. In the end, I realized that growing the project’s popularity could open the door to other ways of monetizing it later.
Can you tell us anything about your current runway or financing?
The project is mostly self-funded. It’s not the kind of thing venture capitalists typically invest in since they focus on fast, exponential growth. Ours is steady but calm. So, it's not something I’m looking into actively. I would even say that it can do more harm to open-source projects than good. But this is another topic.
Currently, the project is primarily supported by sponsorships, my freelancing work, and the new cloud offering we are building. We launched it last year and have started getting some customers, but there’s still a long road ahead! That’s why we’re grateful to companies like Localazy for sponsoring the open-source project — it really helps keep the lights on. I also had the chance to see Mockoon selected for the first cohort of the GitHub Accelerator. It was a great experience, and the financial support made a real difference.
Do you have any subscription models, or is Mockoon a one-time payment plan?
Mockoon Desktop was always fully open-source and free. There is no subscription or one-time fee required for using it. You can also self-host your mocks using several libraries we built. Now, things are changing slowly as we are building a cloud-based SaaS platform to help make the project sustainable in the long term. It offers paid cloud features on top of the open-source application: real-time team collaboration, cloud deployments, etc. It’s a recent project, so we still rely on sponsorships and freelancing to keep everything running. While donations help, they don’t fully cover the costs yet. In open source, only a few projects get substantial funding, while most rely on smaller contributions.
It’s important for us to find a sustainable way to keep working on the project. Otherwise, we may eventually have to return to full-time jobs, and the project could slowly fade away, like many open-source ideas, unfortunately. Building a cloud offering is our way of addressing this challenge, and we hope time will prove that it was the right decision.

What do you think makes Mockoon stand out from similar products?
Mockoon is built specifically for API mocking. Other tools like Postman or Stoplight include mocking as just one feature within a larger platform, but Mockoon is entirely focused on it.
This makes it easy for teams to start working right away without needing to design an API first. Many tools follow a strict, waterfall-style approach, but Mockoon supports more flexible and agile workflows, allowing teams to create endpoints and start testing quickly. It also includes advanced features like rules and a templating system. This combination of agility and functionality is what sets Mockoon apart.
"Many tools follow a strict, waterfall-style approach, but Mockoon supports more flexible and agile workflows, allowing teams to create endpoints and start testing quickly"
What does success look like for you?
I hope that one day, Mockoon will grow enough to sustain my work on the project and maybe the work of frequent maintainers. My goal is to build a calm, well-functioning company that serves its users while staying sustainable as an open-source project. Being able to stop freelancing and focus entirely on Mockoon as my main source of income would be life-changing.
Starting something new is complicated. Around 95% of startups fail, and success depends on a mix of hard work, luck, and being in the right place at the right time. Having a small, stable company that works well and makes everything “good” for everyone involved — that would be a success for me.
"Starting something new is complicated. Around 95% of startups fail, and success depends on a mix of hard work, luck, and being in the right place at the right time"
What are the biggest risks for Mockoon in the current market?
The biggest challenge is competition. Many of my competitors are large companies like Postman or WireMock, and new API mocking tools appear almost every month. It’s a crowded space, and there’s always a chance that a better tool could come along and reduce interest in Mockoon.
Being a solo founder makes it harder to compete in terms of innovation since there’s only so much one person can do. But it also has advantages. I can stay closer to users, listen to their feedback directly, and respond quickly to their needs. Bigger companies don’t always have that level of flexibility, which gives Mockoon an edge in some ways.

🏭 The industry 🔗
The software industry moves fast. And over the last few years, I think you might have noticed this while working on Mockoon.
Yes — some trends, like Web3 and the multiverse, have already faded. They promised a lot but didn’t live up to expectations. On the other hand, AI has been the biggest revolution in decades.
While working on Mockoon, I’ve seen how tools like GitHub Copilot now write about half of my code. It’s not perfect. It makes small errors or even fabricates things. For example, a user recently tried a syntax suggested by Claude that was completely made up. Still, these tools are a huge help and have changed how we work. Another major shift is remote development, with tools like GitHub Codespaces. You don’t need a powerful computer anymore; everything runs remotely.
These changes are exciting. Yes, they might disrupt some jobs, but that’s part of progress. We need to manage these advancements responsibly, but resisting them isn’t realistic. It’s a new era of innovation, and the possibilities are incredible.
"The software industry changes quickly, and some trends, like Web3 and the multiverse, have already faded. [...] On the other hand, AI has been the biggest revolution in decades"
Are there any products, apart from Localazy, that you use daily and that you love and would recommend?
One tool I really like is GitKraken, a graphical user interface for Git. I think using a Git interface is underrated, especially for beginners. Even though I’m very comfortable with Git and usually use the command line, I still prefer using an interface. With Kraken, you can see much more at once, which is harder to do with the command line. 🦑
For beginners, I think it’s easier to learn Git with a GUI because it offers a more visual way to understand things. Of course, when I mention this in forums, some people get upset, saying Git should only be used with the command line for a purist approach. But honestly, I think using an interface is a great option.
Earlier we were talking about privacy, which is a feature that you take pride in. How do you plan to face the challenges of privacy as Mockoon grows?
Privacy is a complex issue. I like to compare the internet to real life. In physical stores, when you use a loyalty card, they track your habits without asking for consent, and it’s not seen as a big deal. But online, tracking is considered a major privacy violation, and you need to ask for consent just to collect basic data. It’s ironic because people freely give away a lot of personal data in real life, yet online, we treat it as a major issue.
I’ve made Mockoon as privacy-friendly as possible. I removed most tracking and built a simple telemetry system that tracks only page views — nothing personal. I also realized a lot of the information provided by analytics tools are vanity metrics and don’t offer much insight. I used to worry about drops in users, like during Christmas, but now I focus on more meaningful metrics, like subscriptions to the SaaS platform. I’ve learned to relax about metrics and focus on broader trends. If there are more support requests, blog posts, or contributors, that’s a good sign. I’ve also removed Google Analytics and cut back on tracking because developers, especially, care a lot about privacy. It was a tough decision, but it feels like the right one to maintain trust. 🔏
"I’ve learned to relax about metrics and focus on broader trends. If there are more support requests, blog posts, or contributors, that’s a good sign. I've also removed Google Analytics and cut back on tracking because developers care a lot about privacy"
Let's do a little bit of foretelling. What do you think the API industry will look like in 10 years?
I’m not sure about 10 years, but maybe five. While I don’t have all the answers, I believe API design specs like OpenAPI will become even more important. Another trend I see is treating APIs as products. For example, Impala, a company using Mockoon, offers hotel reservation APIs as their core product, with documentation serving as their interface. This approach makes sense because their users are developers, and clear documentation is crucial.
I also think closing APIs, like what Twitter and Reddit have done, is a bad move. It limits the ecosystem and growth. Building open APIs has been proven to be beneficial in the long run, even if it doesn’t generate all the revenue right away. APIs are here to stay, and industries like banking are still behind. For instance, the banks don’t yet fully open their APIs, but once they do, consumers will benefit from tools that integrate easily with their accounts, making the bank look more attractive compared to others like Revolut.
So they would first need to know what an API is, which is not widely known. Do you think there's a way to increase API literacy?
When people ask me what I do and they’re not developers, it’s hard to explain. I usually say, “It’s an application for developers,” but that tends to lose them. From what I’ve seen, there’s a lack of computer literacy, especially at the C-level in companies. Some executives just don’t want to dive into the technical side, focusing more on high-level strategy and meetings instead. But I think more hands-on experience could help. It’s like in hospitality, where you learn every part of the job, from cooking to serving. In our industry, if more people gained practical experience with APIs, they’d better understand how to use them and how they work, which would improve how we approach projects.
"There's a lack of computer literacy, especially at the C-level in companies. Some executives just don’t want to dive into the technical side, focusing more on high-level strategy and meetings instead"
I was asking this because it seems that coding is becoming more accessible for the new generations, and learning coding is a little bit easier than 10 or 20 years ago. Do you think that building APIs will become easier and more accessible over time?
Yes and no. It’s definitely easier than 20 or 30 years ago, when accessing coding knowledge was harder. You had to buy books or magazines. Today, we have bootcamps, online courses, and tools like Copilot that make learning to code more accessible.
However, even with these resources, I still see many people struggling. For example, on Reddit, I often see people who completed a bootcamp but feel they didn’t learn much. I also taught at a bootcamp in Luxembourg, and I noticed that while front-end development is a popular entry point, it’s become much more complicated over the years. Ten years ago, front-end development was simpler, with less JavaScript and fewer tools. Today, the ecosystem is vast and complex, definitely as complicated as back-end development.
📲 Using Localazy 🔗
Regarding Localazy, firstly, I don't know if you've looked into our API. Do you have any thoughts on that?
No, I haven't looked at the API. I looked at the interface, specifically how to translate things. In my previous work experiences, I always had to deal with translations. It's a common situation where you join a company and people are just sending texts to the dev team to integrate into the application. It's a nightmare! I always suggested separating the app release lifecycle from the marketing and copywriting. Using an external application is better and Localazy seems to perfectly fit in.
Do you have a favorite Localazy feature?
I think the most interesting feature is being able to order translations directly. 📬 "You don't need translators in your company". When you think about it, it doesn't make sense. Having the product owner translate the application and then the legal advisor translate something in Polish because they happen to be Polish?! I've experienced that in the past. It works up to a point, but it's better to have professional translators.
Yes, there are many ways of doing it. Many open-source projects have people from the community translate them themselves. But then you have the option to hire a professional team to help with one or several languages. There's always a review process that can improve the final translation.
I think that's a very good feature to have.
Why do you think localization is important today?
This might be a bit disappointing, but since I work in development, I feel that English is so dominant that most things don’t necessarily need translation. That said, I have mixed feelings about it. I’m French, and French people generally struggle with learning languages — it’s crazy. I know developers who speak only French, and it can be a handicap because there are far fewer resources available in the language, making things much more challenging for them. So, translating to French could help, but it won't help them learn a new language! I also know many Mockoon users are in Brazil, so translating it into Brazilian Portuguese would be beneficial.
Last question. And I know you are not an expert, but I want to hear your input about the localization industry. What do you think the future holds for it? Will translators still be needed?
It's a good question. Let me share a story. I was a lawyer before, drafting agreements in both French and English. When I wrote the terms for a SaaS platform, I used ChatGPT — not because I didn’t know how to write it, but because I wanted to save time. I knew exactly what I needed, like non-compete clauses or late fees, and ChatGPT helped me quickly generate the content. It wasn’t perfect, but it was close enough to save me some time. I just had to review and polish the content.
When it comes to translation, I’ve used tools like ChatGPT for courses and emails, and the results were great. The translation is mostly accurate, especially for everyday content. But for legal clauses, I found it produced general translations that were decent but not always perfect. As a translator, I’d be a bit concerned, but it’s clear that technology is improving fast. It’s not a question of if, but when. In a few years, I think AI will handle translation almost perfectly.
"In a few years, I think AI will handle translation almost perfectly. [...] While human translators will still be needed for more nuanced work, AI will play a major role in it"
That said, it’s a very complex debate. AI systems always feed from human input, and there are many ethical questions around this. But when the tool is available, people will use it. Kids already use AI tools at school, and we’ll have to adapt to that reality. While human translators will still be needed for nuanced work, AI will play a major role in translation, and its capabilities will only improve. I’m not scared, but the shift is coming.
🥇 Share your story on the Localazy Blog 🔗
If you enjoyed this interview and have a similar experience as a Localazy user, we’d love to hear from you. Let us know how your business was built and how localization helped it grow into an international success.