Publishing content as a team: why we built our own tool for it

We spent two years publishing almost every day. And still, nobody at Figue could answer one simple question: who posted this week?

At Figue, we build in public. It is a deliberate choice, not a marketing pose. The newsletter is past 1,000 subscribers. The podcast has around 500 subscribers on YouTube, and a similar audience across social. We post on LinkedIn, on YouTube, on X. Every founder has their own account, their own tone, their own rhythm.

Content is our first acquisition channel. But as soon as several people feed it, it becomes invisible to the team feeding it. Nobody sees the collective effort. Nobody sees the gap when someone drops off for three weeks. Groowth came out of that frustration, exactly like our other products: a need we lived ourselves, every day.

Publishing alone is a discipline problem. Publishing with five people is an organisation problem. The two have nothing in common, and most tools on the market only address the first. Here are the three leaks we found at home, by looking honestly at why our content months were so uneven.

These three leaks have one thing in common: none of them is solved by more discipline. They are solved by visibility. That observation defined the scope of the product.

Groowth starts from a deliberately simple idea: plug all the team's accounts into the same place, and count.

Each person connects their TikTok, Instagram, YouTube and LinkedIn accounts. The tool pulls posts and audience, then puts them into one global view: how many posts this week, what combined audience, who is up to date, who dropped off. Nobody installs an extension, nobody fills a spreadsheet, nobody declares anything. If the team has to enter data by hand, the tool is dead before it is useful.

The product is live at groowth.io, with three accounts free forever. That is enough for a small team to test the mechanic over a full month before paying anything. We set that limit high on purpose: if the mechanic does not hold over a complete month, it will not hold after a payment either.

A dashboard gets opened once, then forgotten. We have built enough of them to know. What made it stick internally is the game side, and it is the only part of the product that was not obvious to design.

Three building blocks. One lane per person, so everyone's effort is readable without a humiliating leaderboard. A streak to keep alive, because nobody wants to be the one who breaks a 21 day run in front of the whole team. A shared target, so the collective wins over individual performance and the top performer has no reason to keep their methods to themselves.

“Consistency does not come from discipline. It comes from someone noticing the day you stop.”

These rules did not come out of a design workshop. They came out of six months of internal use, during which we removed everything the team was not opening. What remains is a smaller product than the one we first imagined, and it gets used every day.

We built Groowth for ourselves. Showing it around, three profiles came back with exactly the same problem, for different reasons.

The agency case surprised us. We were aiming at internal teams, and marketing agencies showed up: they run several clients' accounts and spend a day a month rebuilding reports. Same need, different scale.

Groowth is not our first tool born from an internal need. ReactIn followed exactly the same path: a problem we lived, a tool hacked together for ourselves, then people around us asking for access. The difference between an internal tool and a product is not code quality, it is the moment an outsider insists on using it.

The upside of that path is simple: you cannot lie to yourself about quality. You are the first user, every day, and every friction you let through, you suffer the next morning. It makes scoping far more honest than a backlog full of assumptions.

The downside is real too: a tool shaped for three founders who publish a lot is not automatically right for a fifteen person agency. That is the work in progress, and it happens with the first users, not against them.

To go further, we have written up how we build a SaaS go-to-market plan, what sits in our daily tool stack, and where to draw the line between an MVP and a V1.