Writing is easy.

Okay, maybe not that easy. Writing is a skill, and like most skills, you have to develop the habit. But at least the main obstacle is personal discipline.

But getting people to actually read what you publish is much harder.

That's why I've spent a lot of time building distribution features into Writizzy. Good SEO, RSS feeds, cross-posting to social networks, newsletters… All of these are different ways of helping your content find readers.

Another approach would have been to build a network of articles: one place where readers could discover content from everyone at once. That's more or less the approach taken by Medium.

The problem is that, with this model, your articles depends on the platform. The platform decides how your content is displayed, who gets to see it, and what happens to it over time. And, in Medium's case, they can decide to put content behind a paywall.

I'm not a big fan of that model.

When I started Writizzy, I actually tried a smaller version of it. I built Discover, a feed where readers could browse articles published on Writizzy without any algorithm and the content stayed on each blogs. But it wasn't enough, because Writizzy had no network effect.

So I started wondering:

What if Writizzy could connect directly to a network of tens of thousands of blogs and ++millions of potential readers++?

That's what we're doing now.

Welcome to the Atmosphere

If you've been following the evolution of the open social web, you've probably heard about the Atmosphere.

Think of it as a galaxy of applications built around the same social network, with the same users.

The best-known application in that galaxy is Bluesky. But Bluesky is just one of many applications using the underlying network. (I’m personally using mu.social instead of Bluesky).

There are apps for social networking, news, forums, video, music, and increasingly, long-form publishing.

They all build on ATProto, an open protocol designed to make it possible to build different social applications that can still participate in the same network.

Blogging on an open social network

One of the things that makes ATProto particularly interesting for Writizzy is that it isn't limited to short social posts.

It can also be used to build blogging applications.

That's where site.standard comes in.

It's a standard for representing websites and long-form publications on ATProto. Different applications can understand the same blog posts, authors and publications without needing to be part of the same product.

Writizzy now supports this standard.

Which means that your Writizzy blog can be part of the Atmosphere.

Your posts can now also become discoverable through applications connected to this network.

Your blog, connected to a network

This is what I find exciting about this integration. Writizzy doesn't need to become a social network. We don't need to build our own audience from scratch. Instead, we can connect your blog to a network that already exists.

It's a bit like RSS, but with a social network built around it.

You publish on your blog, and other applications can discover and consume your content.

And because the network isn't controlled by a single application, new ways of discovering and interacting with your content can appear without Writizzy having to build all of them.

Your blog becomes a node in a network.

And your content still lives where it belongs

There is an important detail here.

Connecting Writizzy to the Atmosphere doesn't mean moving your blog to Bluesky or giving up control of your content.

Your Writizzy site remains the place where your content lives.

Your domain is still yours. Your website is still yours. Your articles are still published there.

The Atmosphere is simply another network through which your content can be discovered.

That's important to me because it's also one of the reasons I built Writizzy in the first place.

I don't want to build another platform where your content is locked inside a company.

I want Writizzy to help you build a home for your writing on the web, and then connect that home to the rest of the web.

This is only the beginning

Right now, the first step is making Writizzy blogs available to applications that understand site.standard.

But the possibilities go much further. I’m still thinking about it, so it’s not really a roadmap but here are a few ideas :

• Imagine a blog reader that lets you follow writers from across the Atmosphere.
• A recommendation engine that can surface great articles regardless of where they're hosted.

None of these applications need to be built by Writizzy.

That's precisely the point. The network is bigger than the product.

We can focus on building the best publishing experience we can, while letting an open network handle part of the distribution problem we've been trying to solve from day one.

If you want to connect to the atmosphere, go to Settings → integrations → Channels and add Bluesky channel.

Hugo

Then I started a company, and inside that company I built the engineering team. I wanted us to adopt those same writing habits, because writing pays off in many ways.

First, it is a great way to formalise things, and to explain them simply. As Boileau put it, "Whatever we conceive well we express clearly". Writing a good post forces you to dig into a subject and clarify your own thinking about it.

Then it is excellent documentation "for the record". Code lives alongside documentation that describes it at a given point in time. Blog posts let you trace back where the decisions came from, and why. Why we went with feature flags, with a monorepo, why we picked MongoDB (and why we later decided to drop it). A post is history, not just a technical tutorial.

Finally, it is a showcase for your brand. A blog reflects the culture of the team writing it. Plenty of candidates came to us through our posts, won over by the culture that showed through them, and they started the conversation right there.

It is also an asset for your company's SEO. I have been talking about teams here, mostly engineering ones, but really anyone in your company can use this, along with everything else Writizzy brings: detailed analytics, newsletters tuned for deliverability, SEO audits and more.

So of course, for Writizzy, I wanted team writing to feel first class:

::toc{open="true"} ::

A proper editorial setup

Writizzy comes with several roles, contributor, author and editor, and you can change them at any time. They define who can write, who can review and who can publish. Nice bonus: there is no limit on how many people can join a team.

An optional review cycle

By default, everyone publishes their own posts, just like before. But if you would rather have a second pair of eyes on a post, the author sends it to review in one click. It lands in the "In review" tab, the reviewer gets an email, opens the post, leaves notes, and either publishes it or sends it back to the author.

Discussion threads, built in

No more back and forth in Google Docs. Write and approve your posts in the same place, and leave review notes right inside the post to talk things through with your reviewers.

Version history and conflict handling

You will never lose anything. Nothing is more frustrating than several people editing the same document and one of them silently overwriting the other. Writizzy now detects those conflicts, and keeps a version history so you can roll back easily.

Your own custom domain

You should be building your own brand, not lending your reputation to someone else. It is better for your SEO, and it also makes it easy to move elsewhere later if you ever want to.

What about you?

Want to give it a go? Create an account on Writizzy to try the basics, then pick the "Teams" plan to invite the rest of your team.

And if you already write somewhere else, Medium, Substack, Ghost, WordPress or Beehiiv, your posts come over in a single import, images included.

One last thing: send us your feedback. The product moves forward every day thanks to what its users tell us.

Git is not for everybody. The interface is less convenient, handling images is more painful, but the appeal makes sense to me. It is not the experience an online editor gives you, and I still wanted that way of working to be possible inside Writizzy, through an API.

That is exactly what this article is about. It is one of the rare ones I wrote directly in Markdown, then synced to Writizzy with a GitHub Action. This article lives in a public GitHub repository: hlassiege/demo-writizzy-post.

Let me show you how to do it.

Setting it up

1. Generate a write key. In your blog settings, open Developer API and generate a key with write access. Read keys are for pulling content out (a static site build, for example) and they cannot create or change anything.

2. Store it in GitHub. In your repository settings, add a secret named WRITIZZY_API_KEY, and a variable named WRITIZZY_SUBDOMAIN holding your blog subdomain.

3. Add the workflow. One workflow file, one script, both in the repository above. Copy them and you are done.

The repository layout is deliberately simple:

posts/      your articles, one Markdown file each
assets/     images referenced from your articles
scripts/    the publishing script (Node, no dependencies)

What a post looks like

A post is a Markdown file with a small header. I went with front matter, the format most static site generators already use.

---
title: "Publish to your blog with a git push"
slug: publish-to-writizzy-with-a-git-push
excerpt: "Write in a GitHub repository, push, and it appears on your blog."
tags: [API, Automation]
status: published
---

Some writers do not want a text editor in a browser tab...

Notice that this post is in status: draft. Nothing goes out immediately, so you can reread it in context before anyone else sees it. Switching it to status: published puts it online.

I made sure the script only republishes the article you actually touched. Fix a typo in one article and the other twenty are left alone.

How updates are handled

The slug is the identity of the post. Change it and you get a new post, keep it and you update the same one. Under the hood, it uses the onConflict=UPDATE parameter of the API, so you do not have to store any ID or bookkeeping file in your repository. The slug is what identifies the post.

Publishing is still its own call, and it only makes the post visible. It does not send your newsletter and it does not cross-post anywhere. I decided that this kind of action should not be tied to the publish API.

Watch out for images

Reference an image with a relative path and it gets uploaded to your media library on the way:

![A diagram of the flow](../assets/flow.png)

The script replaces the path with the CDN URL before saving the post, so what readers get is served from the CDN and what you keep in git is the file.

Image handling does come with a limitation. Every push of an article uploads its images again, which recreates the same files. Publishing an article once or twice is no big deal, but it is not optimal. If your content is heavy on images, you probably want to adapt the script so that it sends published versions only rather than every draft, to keep the duplicates down.

That's all

And that is all. Have a look at `publish.mjs`, the script the GitHub Action runs to publish. It is the heart of this demo, and it is what put the article you are reading online.

If you have any questions, ask away.

How do you get your latest article noticed?

That’s the very question that pops up right after clicking "Publish," and it’s one that many of us spend a lot of time trying to figure out.

The most obvious answer is to work on your SEO. We all know SEO is incredibly powerful, but it’s a long-term game. It takes time, patience, and Google’s algorithms can be notoriously fickle.

The other, more immediate option is to go get readers right where they already are: on social media.

There are plenty of benefits to this:

• Boost your SEO with valuable backlinks.
• Get noticed, shared, or quoted by fellow bloggers.
• Reach new readers who can discover your work on Bluesky, LinkedIn, Mastodon, or elsewhere.

The catch? It’s a chore. You have to open four different tabs, adapt the formatting, tweak the teaser for each platform, and make sure you don't mess up the links...

That’s exactly why we built Cross-posting on Writizzy.

From now on, you just write your article, hit publish, and Writizzy handles the rest.

Behind the scenes, you connect your favorite social networks (LinkedIn, Mastodon, Bluesky, Discord) and simply check the boxes. To save you from writer's block, Writizzy automatically generates a tailored summary for each platform to act as the perfect hook.

And this list of integrations is just the beginning—it was designed to scale up easily. If your platform of choice isn't there yet, just let me know! In the meantime, we also support Webhooks, meaning you can hook Writizzy up to tools like Zapier, Make, n8n, or Buffer to send your content absolutely anywhere you want.

Cross-posting is available starting today, right from your dashboard.

::link-button{label="Try it" url="https://writizzy.com/dashboard/settings/integrations"} ::

We can’t wait to see your articles spreading everywhere!

Thanks for being part of the journey,

Thomas & Hugo

I created the second one a long time ago. At this time, the vast majority of the web was in English and let’s be honest, for a long time, English was hard for a lot of people in France :) So I decided to write my blog in French for… french reader.

But over time, I realized I was missing out. Some of my articles could clearly bring value to an English-speaking audience too. After all, I don't just write about pure tech; I talk about building companies, my experience as a CTO, and leadership.

However, going multilingual is far from simple. You can't just stack articles one after another using structures like myblog.com/article1-fr and myblog.com/article1-en. Between duplicate content issues, reader confusion, and SEO penalties, that approach is a recipe for disaster.

In this post, I’ll walk you through the best methods to create a multilingual blog that keeps both your readers and search engines happy.

URL Structures: The Blueprint

The very first decision you need to make is how you want to present and organize your content. Generally speaking, you have two main options:

• Subdirectories: myblog.com/en/ and myblog.com/fr/
• Subdomains: en.myblog.com and fr.myblog.com

The first method (subdirectories) is what you’ll see most often with WordPress setups using plugins like WPML, Polylang, or Weglot. Personally, I’m not a big fan. I find it creates a bit of confusion for the reader since all content lives under the exact same roof. It also complicates the backend: all your posts are mixed together, making it hard to see at a glance which ones have been translated and which haven't.

That being said, this method has one huge SEO advantage: the site is treated as a single, massive block. If your French article gets a high-quality backlink from a major media outlet, that "SEO authority" (PageRank) instantly benefits your English articles too.

The second method (subdomains) has other benefits. It’s much cleaner for the reader and offers better peace of mind when you’re writing. However, search engines view each subdomain as an independent site.

In the end, it’s all about trade-offs.

Whichever structure you choose, you must pay close attention to geographic and linguistic targeting. You need to tell search engines exactly who the content is for, and if an alternative version exists in another language.

This is done using hreflang tags. They allow you to specify for any given page:

• "This page is meant for a French-speaking audience."
• "An alternative version of this exact page exists here for English speakers."

Crucially, this prevents search engines from flagging your translated posts as duplicate content. Because even when translated, Google (and others) are smart enough to know it's the same core content. You absolutely need to feed them the right data.

The Translation Workflow: From Python to AI

The second challenge is the translation process itself. For years, I translated my first articles entirely by hand. It was incredibly time-consuming, and as a non-native speaker, my English wasn't always sharp enough to accurately capture local idioms.

Later on, I switched to DeepL. It was faster, but DeepL used to struggle with the broader context of a technical or philosophical article.

More recently, I’ve been using AI. The game-changing advantage of LLMs is their contextual understanding. They can take a specific French idiom and translate it into its actual English equivalent. For instance, if I want to say a tool is decent but "doesn't break three legs of a duck" (a literal French idiom), the AI knows to translate it as "it’s nothing to write home about." It saves an incredible amount of time.

Still, human proofreading remains mandatory. You always need to replace localized reference links, tweak the tone, and double-check that no mistranslations slipped through.

For a long time, my workflow relied on custom Python scripts. I would write in Google Docs, download the content via a script, and shoot it to the DeepL API. It worked, but managing the whole pipeline was a massive chore.

And that is exactly why I couldn’t wait to solve all these pain points with Writizzy.

The Writizzy Solution

When building Writizzy, my ultimate goal was to streamline the writing workflow as much as humanly possible. And today, the multilingual feature has officially arrived.

I made design choices that prioritize clarity and user experience. From now on, you can leverage our multi-blog feature to run an English blog and a French blog side-by-side (and as many other languages as you want).

Each blog is mapped to its own language, naturally adopting the clean subdomain structure: e.g., hugo.writizzy.com and eventuallymaking.writizzy.com.

Inside the dashboard, I added a translation status indicator to the post list. You can see at a glance if an article is missing a translation, making your content todo-list crystal clear.

When working on a post, Writizzy allows you to either link it to an existing article or automatically translate the entire draft into another language. The time saved is just massive.

And of course, Writizzy handles all the heavy lifting for hreflang tags under the hood, ensuring your SEO remains flawless and protected against duplicate content penalties.

Long story short: you can now seamlessly run a beautiful, SEO-friendly multilingual blog on Writizzy. 😉

Until now, juggling multiple blogging projects could be a logistical headache. Today, we are stripping away that friction. We are excited to announce the launch of Multi-Blog support on Writizzy.

Why Multi-Blog?

I know that forcing everything into a single blog often leads to a messy experience for readers. People who follow you for coding tips might not be interested in your favorite cooking recipes.

Multi-blogging allows to keep your content organized and relevant:

With this update, you can now:

• Switch in one click: Jump from one dashboard to another without the constant dance of logging in and out.
• Centralize your management: A single interface to pilot all your different publications.
• Keep contexts separate: Each blog retains its own settings, unique domain, and specific audience.

Leading by Example

To give you an idea of how much this changes the workflow, I’ve been using this feature daily to manage my own three distinct blogs:

1. eventuallymaking.io: My thoughts on product , tech and engineering leadership (in English).
2. eventuallycoding.com: the same, but in French.
3. blog.writizzy.com: This very blog, where we share the behind-the-scenes and updates of our SaaS platform.

Three domains, two languages, different targets, but one seamless writing experience.

How to Get Started

It couldn’t be simpler. In your dashboard, you will now find a blog selector. You can add a new blog to your account in seconds and start publishing immediately. Whether you are a solo creator or part of a team, the transition is invisible.

So, what will your next blog be?

Log in to your Writizzy dashboard and try the switch today!

Today, we’re excited to announce a feature many of you have been waiting for: Paid Subscriptions. This is a major step for Writizzy. We are now a serious alternative to Substack but without commission.

Premium Content, Simple Setup

We wanted to make monetization as frictionless as the writing experience itself. You can now offer your readers the option to support your work directly through a monthly subscription.

How it works: On every post you write, you now have a simple toggle: Free or Premium.

• Free posts keep building your reach and attracting new readers.
• Premium posts are reserved for your most loyal supporters, allowing you to share deeper insights, exclusive stories, or specialized knowledge.

Your subscribers get a seamless experience, receiving both your public and private updates directly in their inbox or on your blog.

The Writizzy Difference: 0% Commission

This is where we stand apart from the "big" platforms.

Most platforms take a cut of your revenue—usually between 5% and 10%. When you’re just starting out, it feels like a small price to pay. But as you grow, that "tax" on your hard work becomes a massive burden. To be honest, we’ve always found this model unfair.

At Writizzy, we take 0% commission on your subscriptions.

Here is our logic: our effort as a platform isn't proportional to your earnings. Whether you charge $5 or$50 to your readers, our job remains the same.

We don't see why we should tax your success.

If your audience grows, your infrastructure needs might increase (like email volume), and that’s reflected in our transparent subscription tiers. But your actual revenue? That’s the result of your work and your relationship with your readers.

(Note: The only fees you’ll pay are the standard Stripe processing fees—we haven’t found a way to bypass those... )

Why Monetize Now?

Beyond the revenue, it’s about the relationship between you and your audience.

1. Authenticity has a price In a world of "free" platforms, we’ve learned that when the product is free, you (and your readers) are the product. Your data is tracked, sold, and used to feed algorithms. By offering a paid tier, you’re making a different promise. It guarantees your editorial independence because you only answer to the people who value your work.

2. A healthy constraint We don't steal your data. We don't sell ads. This is a commitment, but it’s also a constraint: to keep building this independent space, we (and you) need to make a living from it. Paid subscriptions are the cleanest, most honest way to fund a sustainable project without compromising on ethics.

3. Quality over Noise When you’re paid directly by your readers, you don't need to chase clicks or create "noise" to survive. You can focus on what matters. It’s a shift from quantity to quality.

How to get started

The feature is already live in your dashboard. Just head to your Settings, connect your Stripe account, and set your pricing. You can be up and running in less than 5 minutes.

We can’t wait to see what kind of premium communities you’re going to build.

Hugo & Thomas

At Writizzy, we believe the answer should be in your hands. That’s why we’ve introduced a new feature: the AI Crawler Toggle.

How it works (and what it does)

In your settings, you’ll now find a simple checkbox: "Allow AI bots to crawl your content."

• Disabled by default: Because we respect your privacy, this is turned off from the start. Your content is not an open buffet for AI training unless you say so.
• The robots.txt directive: When disabled, we automatically update your robots.txt file to tell crawlers like GPTBot (OpenAI) or Claude-Web (Anthropic) to stay away.

A quick reality check

It’s important to be transparent: the robots.txt file is indicative. It’s like a "No Trespassing" sign on a fence.

• The "Good Citizens": Major AI companies (Google, OpenAI, Anthropic) generally respect these directives. If you tell them to stop, they usually do.
• The "Outlaws": Some smaller or less ethical bots might ignore the sign and crawl anyway. There is no magic "delete" button for the internet, but using this toggle is currently the most effective standard way to protect your work.

Should you allow it?

Why would someone want to be crawled by AI? There are a few reasons:

• Visibility: Some AI-powered search engines (like Perplexity or Google Search Generative Experience) might use your content to answer queries and provide links back to your blog.
• Reference: If your goal is to be cited as an expert by AI assistants, they need to be able to read you.

Our Philosophy: Consent First

Whether you want to be cited by AI bots or keep your writing strictly for human eyes, it’s your call. Writizzy is just here to provide the "No Trespassing" sign if you need it.

You can find this new option in your Dashboard > Settings > SEO & Indexing.

Hugo & Thomas

Until now, we’ve mostly worked on products centered in Western Europe. But recently, we received a message that made us stop and think:

"Hi there, your product is awesome... However, can you implement a purchasing power parity policy? Your current pricing is too high for me in Indonesia."

This is a real issue for any independent creator. If you’re in Vietnam, Brazil, or Poland, a $10/month subscription doesn't represent the same part of your budget as it does for someone in the US or France.

The Big Mac, the Median Salary, and Fairness

You’ve probably heard of the Big Mac Index. It’s the simplest way to understand Purchasing Power Parity (PPP).

To put it into perspective:

• In the US, the median salary is around $3,800/month. A $10 subscription is 0.3% of that budget.
• In Vietnam, the median salary is around $350/month. That same $10 represents 3% of their budget.

Is it fair? No. If we want to be the home for authentic writing worldwide, we can’t ignore the economic reality of our writers.

Why most SaaS avoid PPP (and why we don't)

Most companies avoid PPP for two reasons: Production costs and VPN "tourists."

1. Production Costs: Our servers cost the same in Euros regardless of where our users are. But as a lean, bootstrapped team, we focus on marginal costs. As long as a user covers the cost they generate (hosting, emails, support), they help the platform grow. Having 5,000 users in Southeast Asia at a fair local price is better for the ecosystem than having zero because we were too rigid.
2. The VPN Problem: Sure, some people might try to use a VPN to pay less. We could spend thousands of dollars on complex verification systems, but we’d rather spend that time building features you actually want.

Our stance? We will trust people. We believe the vast majority of our community values what we’re building and won't spend their energy trying to "cheat" the system for a few dollars.

How it works on Writizzy

We want to keep things simple and human. Instead of an automated, cold algorithm, we’re doing this on-request. If our standard pricing is a barrier for you due to your country’s purchasing power, here is the process:

• Check our documentation: our PPP Docs.
• Send us an email: Reach out at contact@writizzy.com mentioning your country.
• Verification: No passports, no invasive data (we don’t want to store such sensitive information !). Just a link to your public LinkedIn or professional profile is enough.
• Get your code: We’ll send you a personal coupon code to adjust your subscription.

Building a better web, one country at a time

Blogging is the ultimate space for personal expression. We don't want your geography to dictate whether or not you can own your corner of the internet.

Hugo & Thomas

Launching a blogging platform in 2026 might seem like a counter-intuitive bet. Between social media fragmenting our attention and the explosion of AI-generated noise saturating the web, why add one more destination?

The answer is simple: we want to make writing meaningful again.

The end of authenticity?

We see it every day: the web is drowning in "AI slop." It’s becoming impossible to tell if what you’re reading was actually thought out by a human or spat out by a prompt in three seconds.

At Writizzy, we are convinced of one thing: trust and authenticity still matters. This trust isn’t built with three-line "hooks" on X or LinkedIn. It’s built with long-form, thoughtful content where you take the time to share a vision. This is exactly why we wrote our Manifesto: to define what we stand for.

Two paths, one shared frustration

Writizzy was born from the meeting of two "indie makers" who believe in "eating their own dog food":

• Hugo Lassiège: I’ve been blogging since 2001 (the good old days of free.fr). After co-founding Malt, I felt the need to get back to tools that aren't bloated corporate machines. I created Bloggrify and Hakanai to reclaim that freedom.
• Thomas Sanlis: As a designer and the founder of Uneed, I’m obsessed with simplicity. I wanted a tool that is a joy to use every day, without the friction.

We looked at the market and nothing quite fit: Beehiiv is expensive, Medium locks you in, and Substack is pushing more and more towards a 'closed garden' model, prioritizing their own ecosystem over your independence. Most importantly, almost no serious alternative is European. Not out of nationalism, but because we believe it’s healthy to have options outside of the US giants when you entrust a platform with your content.

Powerful, but never bloated

To be clear: we aren't building a "minimalist" tool that lacks power. Writizzy will be a complete platform. We will offer everything a modern author needs: newsletters, analytics, audience management...

The difference? Clarity. At least, that’s what we hope for, and we’ll do everything we can to make it happen.

Our three core pillars:

• No Lock-in: Your content is yours. Reversibility is a first-class citizen: you can import and export your entire blog in a click.
• Zero Commission: We charge a flat subscription fee. If your audience explodes, our take doesn't. Your success belongs to you.
• No AI Factories: You won't find a "Write this article for me" button. If you don't take the time to write it, your readers shouldn't have to take the time to read it.

A Bootstrapped journey

Writizzy is just the two of us. No investors, no insane growth pressure that eventually degrades the product. We want to build a sustainable platform, funded solely by its users.

If enough people find value in what we’re building, we’ll keep refining the tool until it’s perfect.

We’re building Writizzy for ourselves. We hope it’ll be for you, too.

Hugo & Thomas