While talking with several potential Writizzy users, I realized that one of their main concerns when choosing a blogging platform—or any platform for photos, videos, etc.—is longevity.
Will the platform shut down in a year or two? What happens if it does? Do I lose my data?
And what if it evolves, but in the wrong direction? (I’m looking at you Twitter...)
Some quotes from users:
$ echo>I don't really intend to use a platform. One of the reasons I built my own engine is stability.
$ echo>Before using Substack, I was using Twitter's solution that did pretty much the same thing. They shut it down overnight, and I couldn't recover my content.
This is a legitimate concern: will the effort I put into maintaining a blog be wiped out tomorrow?
I need to answer this question. How do I preserve the effort of people who might use Writizzy? Here are some of my answers. But this isn't just about Writizzy. Whether you're choosing a platform or building one, here's a framework for thinking about longevity.
Plan for reversibility
The first priority, in my view, is to always remain in control of what you produce. You need to provide a simple way to export your data.
The import/export function must be easy to find, and the format must be usable.
On Writizzy, I chose a JSON format similar to Ghost's. All posts are included in markdown format. The newsletter subscriber list is also included.
There's no data lock-in, and it would be easy for any user to migrate to another platform if needed.
The second factor of reversibility is giving everyone the option to use their own domain name. For example, I use eventuallymaking.io. If Writizzy shuts down tomorrow, I could keep that domain and rebuild my blog from my data. The content isn't buried inside a platform (like Medium, for instance), so I retain full control over how I can retrieve and distribute it.
On the topic of reversibility, I could also mention interoperability: how to ensure content isn't exclusive to Writizzy, how to make it work elsewhere. Solutions like RSS feeds and newsletters already exist. But I'm also looking into ActivityPub, AtProto, and anything that could enable better content decentralization if viable solutions emerge.
Prevent enshittification
Yes, that's a strange title.
Most consumer products tend to age poorly—becoming too complex, too expensive. This is often the result of two pressures: shareholders seeking to maximize profits, and internal teams who need to constantly evolve the product to justify their existence.
Cory Doctorow popularized this term, but mainly in reference to the first cause—investor pressure. I tend to think the second is just as problematic.
Writizzy is built differently. And I believe most new companies being created in this post-AI, bootstrapped era will share this same discipline. I'll make sure to build only what's necessary and evolve the product only when needed. I won't take external investors and I don't plan to sell this project. And I don't plan to hire hundreds of people.
I think it's possible—and actually healthy—to build "slowly but surely" for this type of project.
Be economically viable
Longevity requires that the product isn't a financial black hole. The first answer was given in the previous section: I have no investors, I won't hire people to burn through a budget I don't have, and I know what it takes to build a product—I've done it several times. I know how to develop lean.
On Hakanai.io (another product I created), I'm not making thousands of euros, but the product brings in more than it costs. Writizzy is only a month and a half old, and that's already the case too. Because it's simple today to create products with limited resources.
Obviously, I might not be able to live off it, but I'm not counting on that for now—and neither is Thomas, who builds this product with me. I'll work toward making it happen, if only to prove I can, but I have the luxury of being patient.
Use durable technology
This is the hardest part to achieve, because no technology is truly durable. All languages, all frameworks require regular updates—for security patches, OS compatibility, and so on.
That said, there are some best practices to follow: avoid technical lock-in, don't rely heavily on a platform you couldn't do without (avoid big cloud vendors, Datadog, etc.). Always have alternatives, backup plans in case a tool becomes too expensive or dies.
Writizzy runs on a standard stack (Kotlin, Nuxt) with a PAAS tool that would be easy to swap (Coolify with Traefik), on a straightforward VPS at Hetzner.
You might ask: why not make it open source? It seems like the ultimate guarantee of longevity. I say "seems," because history has shown that open source projects can be co-opted by their creators (see WordPress and its various dramas).
The question isn't necessarily open source vs. not open source, but rather: what are the creators' intentions?
There are many examples of openwashing—projects that use the "open source" label as an acquisition channel or marketing argument, without it being a deep conviction.
In any case, open source comes with constraints. Today Writizzy is three separate applications, which isn't exactly the standard for what people like to deploy as open source. It's also designed as a platform, not a product meant for personal use only. Finally, there's the matter of commercial exploitation—I don't want others to profit from my work for free and resell what I've built.
I might revisit this topic in the future depending on how the product evolves. But for now, this option is off the table.
However, if Thomas and I decide to stop or if something happens to us, that would trigger a switch to open source—and I'm going to set up mechanisms to make that happen automatically.
Be your own first user (dogfooding)
Finally, I've been blogging for 20 years. I'm currently the most prolific user on Writizzy with over 80 articles already published (though I cheated—I migrated my old posts ^^). I'm building this tool because I use it. I think it's much easier to build a product you understand because you're a user yourself.
And that's also a factor for longevity.
No comments yet. Be the first to comment!