At the start of this year I set a personal goal to blog more. I wanted to 1) improve my writing skills, 2) build an audience, and 3) if the stars aligned, start earning a bit of supplemental income via paid posts or subscriptions.
I looked at the existing blogging/newsletter solutions out there, and none of them quite fit what I was looking for. They had paywalls (Medium), features I didn't need (Wordpress), too minimal a design (Buttondown), lacked transparency (Substack), or cost money even when I wasn't earning yet (Ghost).
So, I built my own.
No trackers or tracking cookies are used (beyond Plausible, for privacy-preserving analytics). Speed and minimalism is a big focus: all blogs are rendered as static HTML, using as little JS as possible.
You can write blogposts in markdown, publish them, let your readers subscribe, and (when you're ready) connect your Stripe account to start charging readers for access to paid posts. You also always maintain ownership of your posts, and you can export all data at any time.
Still in the early stages, so any feedback would be great.
Impressively fast (honestly, that's stellar work), slightly buggy in the editor (focus is sometimes hard to determine, triple-click doesn't always select a paragraph, etc) but I assume that'll get cleared up eventually, and it's pretty good looking across the board.
I might actually use this. Simple and effective and not full of crap. It could use a little bit more documentation (inter-post linking how? hardcoding might be fine, but it'd be nice if that link-popup searched your post titles or something) and probably a small bit of extra flexibility... but finding the balancing point between "feature-full" and "simple" is quite tough, as is keeping it fast. I'm pleasantly surprised with it as-is.
Any chance of custom domain support? I assume that would be a paid feature (it always is, I think that's reasonable), but it is nice to have that option. Also RSS.
I invested quite a bit into speed, and thankfully Next.js has a lot of great built-in support to make things fast - incremental static regeneration, link prefetching, image optimization, etc.
For the editor bugs - thanks for highlighting, I filed a bug and definitely hoping to tackle this eventually.
Agreed on the documentation as well - it's on my radar to improve.
For custom domain support and RSS - both features on the roadmap! Likely RSS first, as that's quite a bit easier to implement, and custom domain support shortly after that. (Custom domain support is probably the #1 feature request at the moment).
I've been procrastinating self-hosting, partially due to being unable to choose a platform and knowingly committing to it for the long term (maintenance, upgrades, etc.).
This will happily fill the gap and let me get something 'out there' and find my niche while continuing to be indecisive about self-hosting.
Pretty darn frictionless setup, nice clean look and feel. I like it so far.
This looks nicely implemented. Can you give some examples of a successful blog(s) on the platform (with the permission of the author of course)?
One thing I would say is that your top navigation bar (for example clicking on 'Why Papyrus?') doesn't appear to work without JS. I hope the rest of the website experience is not hindered by the need to run JS.
And thanks for the tip about the JS issues - I'm absolutely focused on making the entire site accessible without JS, so this is important to me. I'll take a look at shortly.
I doubt that flat 5% from subscriptions would be enough to sustain free users. You will either have to draw in some established bloggers with loyal, paying audience from another platform, or find another source of revenue.
1. I originally registered https://papyrus.dev, with the original idea being a newsletter aimed at developers. I pivoted to be more broader, and with that, changed the TLD to .so. I haven't gotten around to setting up mail on the new TLD yet, so still using the old one for everything.
2. I'm not sure yet. One of the selling points is no third-party trackers, so I'm not sure how readers will feel if some of their blogs started tracking them.
3. Thanks for the feedback, and I appreciate the mockup! Agreed that section can be clearer - I've added this to the backlog.
If you ever want to use a ccTLD, I recommend starting by looking at the registration restrictions in the infobox in the ccTLD’s Wikipedia article, e.g. https://en.wikipedia.org/wiki/.so says “Limited to institutions and organizations in Somalia, residents of Somalia, others who have a legitimate, clear and provable connection to Somalia”. Also consider whether you trust the country in question to operate its registry well, not to have hostile takeovers that mess up the entire thing, &c.
Generally speaking, I recommend avoiding using ccTLDs in this way. Even new gTLDs are mostly safer. One possibility there is papyrus.pub (“pub” being nominally short for public houses, the eating places and such, but also definitely being used for publishing).
I have seen about three other .so domains, notion.so being by far the best-known; and Notion has definitely had trouble at least once either with their registration or with the operation of the registry.
Just circling back here - I launched custom domain support today. For a one-time fee of $50, you can unlock custom domains permanently for your blog. Thanks!
React & a framework on top can be called minimal for a blogging platform? A blog entry[0] requires the transfer of 3.29MB (2.09MB of images with most which don't look web-optimised).
OP says “as little JS as possible”. I’m seeing 830KB of JavaScript (254KB over the wire) on that page (plus another 14KB of JSON inside the HTML, of __NEXT_DATA__ bloat), spread across more than 20 files, when the only effects I can see are the scroll progress bar in the header (<1KB of value), the subscribe button (perhaps just barely 1KB of value), and SPA loading of other links; and loading /@PapyrusBlog and / via such SPA links fetches another 156KB (48KB wire) of JavaScript.
These figures are in no way light (even if they’re lighter than far too many sites). Given the positioning and the statement “as little JS as possible”, I was definitely expecting less than 5KB of JavaScript, perhaps even nothing beyond Plausible; having seen SPA functionality I’d be willing to increase that expectation to 25KB.
I’m with topicseed: Svelte would be a much more sensible starting point when seeking to use such a framework; SvelteKit can give you the same style of SPA stuff.
One last batch of remarks: most of the stuff in the “optimise images” step of that article is counterproductive. General content should not attempt to use lazy loading, it tends to make the experience worse, especially for distant visitors with higher latency but normally it doesn’t even help things for low-latency viewers. (next/image is wrong and foolish to enable lazy loading by default.) In the case of the logo specifically, if that’s the quill, that looks like it should be SVG—smaller and faster. And <code node="[object Object]">…</code> as the translation of the Markdown `…` is probably a bug.
it's a pity I can't get paid, because Stripe is not available in my country. Maybe add some other options, such as Paddle, to those of us who are located in Africa where Stripe is not available yet.
Nice work, this looks nice. I signed up and was writing a post. I was nearly finished and switched to the tutorial post (which I had archived). I clicked the hamburger and clicked "permanently delete" to remove the tutorial post. However, nothing happened. I then clicked on "All posts" to go back to the post I was working on and it had deleted that. Any way to recover that? I don't see a help email.
Yes, there's a chance I can recover this. Can you shoot me an email (hello@papyrus.dev) with the email you signed up with, and the name of the post you were working on? Happy to look into this.
This is a little off topic but I don't want to read a lot of text-heavy blogs that all look the same. Give me a little variety and some nice pictures to look at. By the way this looks nice and I'm going to check it out, too bad my Tumblr has 2500 poasts and no readers.
I'm stoked for you OP - I wish there was a service that you could subscribe to when a SaaS product has existed and run okay for 2 years. Right now when I hear about something I use, I just set a calendar reminder for 18-24 months away.
Maybe you should provide more links to existing blogs somewhere? (e.g. something like https://read.write.as which aggregates public posts from blogs on write.as)
Yes, I've been meaning to do this - I haven't prioritized it yet because we have not had enough quality blogs on the platform to showcase, but after all the HN traffic I think this will change :)
Have been looking for options to move away from Medium.com and this looks promising. Would appreciate functionality to automatically import existing posts from other platforms (like medium has).
This is something I'm actively working on. I've already begun to implement functionality to import subscribers from Substack (you can test it out in the /settings/blog page).
After I finish Substack, I'll begin adding support for importing posts/subscribers from other platforms.
The editor is currently markdown combined with a rich text UI-based editor. I haven't explored supporting other types of editors (beyond extending the UI), but I'd be open to it.
Features I’ve used::
* Tables: more features and is standard instead of specific to some Markdown “flavors”
* Admonitions: better than ad hoc emoji + bold *NOTE* usage as it then becomes styleable
* Titles for blocks: better than putting "######" for an <h6> when you want a caption
* Display block images
* Ability to add [.css-class-name] to arbitrary blocks
* Ability to add arbitrary attributes to images and links (title, rel, ARIA, etc.)
What I’ll often see however in Markdown is a lot of handwritten HTML to accomplish this stuff which kinda defeats the point of a lightweight markup language. There’s also a big list of typographic substitutions which is nice for authors that prefer to type in ASCII but want proper quotes, dashes, arrows, etc. These are all things I would want if writing technical content where I am in control of styles and demand good typography.
The TL;DR is that Substack has allegedly paid large sums of money to bring writers onto their platform. The writers they've paid have historically been on one end of the ideological spectrum, and Substack has not been transparent about who is being paid, nor how much.
Well, on the 'visitor' side, uMatrix isn't showing any third party links at all, which is an absolute breath of fresh air. There are a couple on the 'publisher' side.
Obviously can't speak to the back-end since it's not open source so there's no way to know what metadata it's recording, but there's no email verification required so as long as you can remember your login details, it won't necessarily link back to you - pending IP addresses etc.
For my own curiosity -- would you blog more often if someone offered you cheap(er than ghost.org) hosted ghost instance from which you're free to take your data any time?
[EDIT] - To make it more concrete, let's say someone gave you a ghost blog that was free with a soft-capped at 100 visits/day (and $5/month after)
The (seemingly) hard scarcity limit on users is where Ghost loses me.
By capping your tiers at number of users you are losing a lot of people who might otherwise use your platform, imo.
Here's my reasoning:
You need to get lots of users to market to so that you can convert those users to paying subscribers. Getting people to sign up for notifications is one thing, getting them to pay money is a whole other proposition. The former is pretty easy and the latter is not. Forcing people to try and do it all in one fell swoop for fear of reaching an arbitrary "user limit" is not reasonable.
The hardest part anyone trying to do this from scratch is going to go through is getting off the ground from a handful of users to a few thousand users. Once they've gotten to that point, and can convert a few hundred of their few thousand users into paying subs, they're getting closer to seeing light at the end of the tunnel. The most feasible way for them to do so is market to their free subscribers / free followers with premium content, engagement with paying subs that they're missing out on, etc.
Ghost chops the legs out from under them when they get to the first hurdle with the 10,000 user limit.
I understand that database costs and email / SMS sending are the expensive part of hosting and have built content distribution backends before, so I get it. I understand the reasoning of putting the limit on pricing tiers there, but it would seem that a more flexible way is in order in Ghost's case. If we presume that you can convert 1% of free accounts to paying accounts, Ghost's pricing page tells its prospective users that they are going to be stuck in a $500.00 / month hobbyist income tier forever.
This is a good point — how would you change their pricing model then? The difficulty of supporting creators will grow with users, would a tiered model that starts charging earlier (but charges less) be better?
Maybe it's better to just do a single no-bullshit price and run unlimited ghost instances for people -- and once you know the scale that a particular instance can take, different tiers for the very large instances. Maybe one price (let's say $10) + custom? But at this point you'll be overwhelmed by users with very large followings which generate tons of traffic.
And if you go by a strictly bandwidth model, then people are vulnerable to overages...
Absent native phone apps, the only way to reliably send notifications to people is SMS and email. This is the world that was wrought when we let ourselves be duped into handing over the whole internet to two cell phone dealers (Google and Apple), and letting them tax real time communication worldwide via their app stores. And the cost of sending email is not just the AWS SES cost per 10,000 mails but the cost to render the template for each email, too. It's not hard to get into a situation where one server relaying mail for just a handful of domains can't keep up with its own queue in any given day.
I think if you're trying to cater to paid tier users, segmenting users by free/paid and only serving free tier users the cache without any sort of interactivity features is the first thing (no comment posting, no upvoting / downvoting, etc).
Finally, yes, I think the scaling cost has to be passed on to the site owner, I don't think you can shoehorn a very elastic service in terms of hardware / network demand into a fixed monthly price, without subsidizing successful users on the backs of those previously mentioned hobbyists.
Lastly, on a more philosophical level, I think media producers / publishers need to get together and stop nipping at the heels of Facebook, Twitter, Google, Amazon, and Apple like puppies following their masters around. I mean, the whole newspaper industry let itself be duped into poor staffing decisions by Facebook lies about video metrics. Which is funny considering Facebook's whole business model is taking other media businesses' ad revenue and keeping it for themselves. I guess media execs never heard the one about grandma and the big bad wolf in their MBA programs...
At the start of this year I set a personal goal to blog more. I wanted to 1) improve my writing skills, 2) build an audience, and 3) if the stars aligned, start earning a bit of supplemental income via paid posts or subscriptions.
I looked at the existing blogging/newsletter solutions out there, and none of them quite fit what I was looking for. They had paywalls (Medium), features I didn't need (Wordpress), too minimal a design (Buttondown), lacked transparency (Substack), or cost money even when I wasn't earning yet (Ghost).
So, I built my own.
No trackers or tracking cookies are used (beyond Plausible, for privacy-preserving analytics). Speed and minimalism is a big focus: all blogs are rendered as static HTML, using as little JS as possible.
You can write blogposts in markdown, publish them, let your readers subscribe, and (when you're ready) connect your Stripe account to start charging readers for access to paid posts. You also always maintain ownership of your posts, and you can export all data at any time.
Still in the early stages, so any feedback would be great.
Thanks!