Behind the scenes, episode 06: Partage, leaving the workshop

You can spend years building something nobody knows how to find.

That nearly happened to us.

We had learned to develop applications, host them, make them communicate and track their revenue. Skalpai tested and deployed them. Spore let them send messages. Lungor organised their payments. Synthiz kept what we learned. L'Alter assisted us every day.

The applications existed. They worked together. I used them every day, as did several people around me.

Yet almost nobody knew about them.

We knew how to build.

Now we had to learn how to leave the workshop.

Why not sell earlier?

The Fabrique's applications are not prototypes independent of one another.

They use each other. They share an infrastructure, means of communication, a payment system and monitoring tools. A change to one can alter how the others work.

While they were being built, some technical choices were deeply revised. Interfaces were replaced. Services were brought closer together. Entire foundations evolved to meet the difficulties we ran into.

Not having customers yet gave us a precious freedom: we could make these changes quickly, without forcing every migration on people who already depended on the system.

With customers, we would have had to preserve more compatibility, give notice, support people and sometimes keep choices we already knew had to go.

That period let us test the applications in our own use and considerably improve their quality.

But it also had a limit.

Using a product yourself lets you test how it works. It does not prove that a market exists.

Our daily use validated neither the applications' positioning, nor their price, nor their ability to find users.

Waiting longer would no longer just have improved the products. It would also have delayed the lessons only outside users can bring.

We knew our trade, not yet this one

Our expertise was mainly technical.

We knew how to turn a problem into an application. We knew how to build an infrastructure, automate tests and deploy a new version.

But knowing how to make something does not automatically give you the ability to make it known.

How do you explain an application without reciting its features? How do you find the people it can really serve? How do you understand their needs without getting them to confirm your own idea? How do you choose a price? Where do you publish? With what message?

Selling demanded new skills: positioning, listening, acquisition, pricing and communication.

Five books served as our first landmarks:

• —Do Things That Don't Scale, by Paul Graham, to go and find the first users one by one;
• —The Mom Test, by Rob Fitzpatrick, to understand real needs without steering the answers;
• —Traction, by Gabriel Weinberg and Justin Mares, to test acquisition channels methodically;
• —Obviously Awesome, by April Dunford, to learn how to position a product against existing solutions;
• —Pricing Low-Touch SaaS, by Patrick McKenzie, to think through the plans and prices of self-service software.

See our go-to-market reading →

A new stage was beginning.

Building the applications was no longer enough. We had to learn to present them, publish about them and create chances to meet them.

One idea, four platforms

The difficulty showed up very concretely.

To talk about an application, you first have to write. Then you have to adapt the text to where it will be published.

A text for LinkedIn does not necessarily take the same shape on Bluesky. X imposes its own constraints. Dev.to welcomes longer, more technical content.

The same idea then becomes several posts.

You have to open each platform, take the text again, adapt it, check its length, pick a date and come back at the right time to publish it.

Then start again a few days later.

We had built applications to avoid this scattering in knowledge, email, payments and deployment.

Now it was coming back in our communication.

An idea was written once, but sharing it still took four different jobs.

Partage was born from that repetition.

One draft, several posts

Partage is a social publishing tool.

It takes a single draft, rewrites it in the format of each platform — LinkedIn, Bluesky, X and Dev.to — then publishes each version on the chosen date, without you needing to be at your screen.

The principle fits in four steps:

1. —you write the idea you want to get across;
2. —Partage adapts it to the format and tone of each platform;
3. —you choose the networks and publishing dates;
4. —Partage publishes the different versions at the planned time.

So it is not about copying exactly the same text everywhere.

A post can keep more context on LinkedIn, become more direct on Bluesky, respect X's constraints or take the form of longer content on Dev.to.

The idea stays the same.

Its form adapts to where it will be read.

Easing the writing, not inventing a conviction

Partage also makes generating posts easier.

A draft does not need to be a finished text. It can start from an idea, a few sentences or a still-imperfect message. Partage helps turn it into several versions ready to publish.

But it must not invent what you think for you.

It knows neither your experience nor the deeper reasons you built something. It cannot manufacture expertise that does not exist.

Its role is to shorten the distance between an idea and its publication.

Partage does not replace what you have to say. It helps you actually say it.

That distinction matters.

We did not want to build a machine to fill networks with generic text. We wanted to remove the repetitive tasks that end up stopping a person from sharing what they truly know.

Publishing without organising your day around a network

Scheduling is the other half of the problem.

Preparing a post does not necessarily mean wanting to send it right away. Some have to go along with an article's release. Others match an announcement, a project milestone or a particular moment of the week.

Without a tool, the communication calendar quickly becomes a string of reminders:

open LinkedIn at 9 am
post on Bluesky at 11 am
go back to X
put the long version on Dev.to

Partage separates preparing from publishing.

The text can be written when the idea is clear. The versions can be prepared together. The dates are chosen afterwards. Once the calendar is set, Partage publishes without anyone having to interrupt their work at the planned time.

It is not spectacular.

That is exactly why it is useful.

Publishing becomes a task prepared in advance rather than a repeated interruption.

Partage does not find users for us

Partage makes communication easier. It does not solve selling on its own.

Publishing more guarantees neither attention nor interest. Poor positioning stays poor when spread across four platforms. A message that meets no need does not become useful because it was scheduled.

Partage does not replace conversations with the first users. It does not choose our market. It does not set our prices or decide what we should build.

It removes one particular friction: regularly turning an idea into several adapted posts and sending them at the right time.

That friction seems small.

Repeated every week, it is enough to make a lot of good editorial intentions disappear.

Partage's first user is the Fabrique

Partage first became the tool we use to make the other applications known.

Articles can be announced on several platforms. A development milestone can become a post. A technical difficulty can be told. A new application can gradually meet its first users.

Every post made with Partage therefore serves twice.

It presents a Fabrique application while testing Partage in real use.

We can see which adaptations work, which distort the message, which formats are missing and which steps are still too long.

Like the other applications, Partage starts by being used before being promised.

Leaving the workshop

The first episodes of this story were mostly about building.

We had to acquire the means to keep knowledge, send messages, handle payments, develop, test and deploy.

With Partage, the question changes.

We are no longer only asking how to produce an application. We are asking how to let it meet the people it could serve.

We did not sell earlier because the whole was still changing deeply and we first wanted to be able to rely on it.

We are starting now because no internal improvement will replace meeting real users.

Until now, we were learning to build. With Partage, we are starting to learn to be seen.

Publishing will make the applications known.

Then we will need to carry on the conversation directly with those who respond.

That will be the story of Messag.