Bootstrapping to $25K MRR solo: Martin Donadieu on growing Capgo

Martin Donadieu runs Capgo, a live-update tool for Capacitor mobile apps, at over $25,000 MRR. He built it without investors, without a cofounder, and without a conventional growth strategy, until he found one already working that he hadn't noticed.

Why he left the funding route

Martin got interested in entrepreneurship at a software-development school in Montpellier, France. Early projects with friends mostly failed. One medical-sector idea hit regulation before they found an adjacent use case. He chose to finish his software-engineering master's anyway, partly because he'd borrowed for school, partly because his parents encouraged finishing.

He eventually joined a funded startup in Finland. Then became CTO of an open-source data-science startup. Both experiences pointed toward the same problem: investor demands displaced useful customer work. The pressure to perform for fundraising rounds crowded out the work that actually mattered to him, watching real customers use what he'd built.

When his bootstrapping preference conflicted with his cofounders' plans, he left.

Working alone exposed something else. He had relied on colleagues for sales and marketing without realising it. Those skills proved harder to replace than he expected.

The kind of business he wanted

Martin describes customer appreciation as a stronger motivator than press coverage or a fundraising announcement. He's direct that the funding decision depends on what a founder actually wants. He doesn't argue everyone should bootstrap.

He wanted freedom over his work. He mentions that customers accept when he needs time for family responsibilities. He believes that way of operating attracts people with compatible expectations, which is a self-selecting effect he seems to have planned for, even if loosely.

How he gets useful feedback

His developer customers often prefer writing to calls. He makes written contact easy.

His emails are plain and personal, no elaborate headers, no forms. The footer promises a reply from him directly. Customers know the founder will read what they send, not a bot or a detached support layer.

He treats angry feedback as a reason to investigate and help. Customers upset by an important unresolved problem can become strong supporters when he takes care of them. That's an experience he reports, not a recommendation to tolerate product failure.

His broader point on feedback:

• Match the channel to the audience
• Silence can mean customers haven't tried the product enough, or don't care strongly enough
• Work on a painful problem where success or failure genuinely matters to the person using it

Why he started a podcast, and what he got from it

Martin spent roughly three years running a French-language podcast before prioritising building. He describes podcasting primarily as a relationship-building activity, not an audience-acquisition channel.

A guest gets a chance to discuss their work and some exposure. He gets direct answers to questions relevant to his own building. Some guests became long-term friends. One became his best friend in Madeira.

Episodes ran about 90 minutes, with at most three hours weekly of his own time plus paid editors. The podcast cost money. What it returned was access, learning, ongoing help, and emotional support from people further along than him.

He primarily approached podcasting as a relationship-building activity, rather than an audience-acquisition channel.

He also describes English-language interviews producing close friendships. The conversations drew people in because they felt personal, like joining a real exchange rather than listening to one.

The discovery that changed how Capgo grows

For a period, Capgo plateaued around $3,000 MRR.

After Martin shared SEO frustrations on X, someone offered a free audit. What they found reframed everything. Many searches were already for Capgo by name. People weren't discovering Capgo through articles. They already knew it existed. The question was where that name recognition came from.

Capgo serves the Capacitor mobile-app ecosystem. Martin had been repairing poorly maintained plugins because he needed them, and those plugins carried Capgo branding. Other developers sometimes paid him for the repairs because they lacked the native-development knowledge to do it themselves.

The audit made the mechanism visible: he was sometimes getting paid to build the exact tools introducing customers to Capgo. He increased that work instead of abandoning it in pursuit of conventional SEO content.

He went from roughly 20 to more than 150 plugins over about 18 months. He reports a 10× increase in people discovering Capgo each day from that effort. That is a discovery claim, not a revenue multiple.

What a fresh user revealed about onboarding

Martin compares explaining a product to someone else with rubber-duck debugging in coding: describing the problem can expose flaws before the other person even supplies an answer.

His wife joined the business in January and tried onboarding Capgo with AI assistance, despite not being technical. The command-line onboarding failed. He had assumed users already had prerequisites like Xcode and Node.js. The tool didn't check for missing prerequisites. It just broke.

He reports substantially improved conversion after fixing these gaps. The lesson he draws: test from a new user's actual starting point, not from a developer's prepared machine.

What he shares publicly, and why he changed his mind

Copycats initially made him more secretive. He reconsidered because publishing work brought customer feedback and practical knowledge that competitors couldn't reproduce simply by copying features.

His distinction is worth noting: "You cannot copy the conversation I have."

Customer relationships and knowledge acquired through doing the work are more defensible than temporary secrecy. That's his reason for returning to building in public. It is not a guarantee that copying carries no commercial cost, but a calculation that openness compounds in ways secrecy doesn't.

He recommends asking someone outside the customer base to read the landing page and explain what the product does. Familiarity with a technical niche can conceal assumptions about terminology, tools, and setup knowledge that ordinary users don't share.

What he's building now

Capgo. Still bootstrapped, still customer-funded, still run by someone who measures progress by whether real people are using what he built.

The plugin work didn't start as a growth strategy. It started because he needed working plugins and fixed them. The growth mechanism was already running before he knew to look for it. The audit just made it legible.

Most of the better ones seem to work that way.