I'd be really curious to hear your thoughts on our proposed business model since it's based on compensating writers when Readup users read their articles to completion. In short, users pay $10/mo to use Readup, we keep $5 and divide the other $5 among the writers whose articles the user has read to completion during that month.
You keep your own stack and there's nothing you have to do other than verify a Readup account with us so we know who you are and collect any money earned. Readup users can read your articles using our browser extensions or mobile apps (I just did! [2]). You can view the full pitch [3] on YouTube.
[2] https://readup.com/comments/kevin-indig/why-i-left-substack-...
This is such a nitpick, but do the economics work at 40% (or even 49%)?
It seems intuitively wrong to me that your value captured is greater than the content creators.
If the economics don't work, feel free to instruct me to take a long walk on a short pier
We don't want to over-promise on the revenue share at the beginning because we've got 3 key promises that we never want to compromise on but do limit us somewhat financially:
- Absolutely no advertising.
- Absolutely no selling/sharing of user data, even in aggregate or "anonymized".
- Reach profitability ASAP so we don't have to fund raise endlessly and lose control of the company.
I'm not sure if the incentive for creators is there, e.i. why would a creator share revenue for fully read articles?
I think you found a value-add for the demand-side of the market but not the supply-side. That's something I'd iterate on :).
Glad you like the completion filter! I've found myself reading articles just so I could leave a comment about how much I disagreed with the headline only to have my mind changed half way through. Taking the time to read really matters!
Gotcha. So, what's the value I'd get as a creator, i.e. why should I not charge through another platform?
The writer compensation is both a value prop for our users (it's the #1 reason that users say they would want to pay for a Readup subscription) and a growth mechanism for us since some writers will have an incentive to tell their readers to read them on Readup. We think that initially writers who have a non-existent or small subscription base would be most inclined to want to promote Readup to their readers but that should scale up as we grow.
I really appreciate the honest feedback. Also sorry for kind of blowing up this thread with all my replies but I'm pleasantly surprised that some other people were interested in checking it out and asking questions as well!
My first impression is that a 50-50 split doesn't seem very fair to the writers. You created the platform but most of the value comes from the writers.
That doesn't feel great. Telling creators that people are paying you for their work but they have to create an account to get paid feels shady. Do you make it clear when something I read is from a creator who has signed up and therefore will be paid?
If one of your users were to read something I published, would they see it exactly as they would if they visited directly? Same ads, same layout? Will the reader look any different to me as far as my analytics go?
Edit: Also, how do you manage abiding by all the crazy terms and conditions on different sites? For example, on your homepage is a link to an Atlantic article and their terms and conditions prohibit the use of their RSS feed for commercial reasons or selling access to their site. Do you have a deal with the Atlantic? Have they signed up with you?
I get that, but isn't it better than paying for a utility like Pocket or Instapaper that strips ads from writers' articles and doesn't offer them any compensation? Those companies aren't asking writers to opt-in to that. We're trying to do the right thing in a financially sustainable way.
Also just to be clear, writers won't be required to sign up for a paid Readup subscription in order to collect their revenue share. If they don't want to use the platform they can just verify with us via email.
> Do you make it clear when something I read is from a creator who has signed up and therefore will be paid?
Yes! There will absolutely be some sort of "blue checkmark" verification indicator. (To be clear we have not yet started charging users. We're still in the building stage!)
> If one of your users were to read something I published, would they see it exactly as they would if they visited directly? Same ads, same layout? Will the reader look any different to me as far as my analytics go?
On the browser: Initially yes, before activating the extension which will strip ads and enter the "reader mode" layout.
On mobile: No, javascript and stylesheets are not executed while rendering the article.
For your analytics: It depends. If you're looking at server logs then everything will look the same. If you're relying on client-side javascript for analytics then you don't see it at all for our mobile users and the results might be different for browser users depending on how your scripts are interacting with the page.
> Also, how do you manage abiding by all the crazy terms and conditions on different sites? For example, on your homepage is a link to an Atlantic article and their terms and conditions prohibit the use of their RSS feed for commercial reasons or selling access to their site. Do you have a deal with the Atlantic? Have they signed up with you?
We don't crawl any publisher websites or use their RSS feeds. All article curation on our site is crowdsourced from our users - 100% organic human spidering. We just track their reading progress and use that data to rank the articles so that everyone can find the best content. We'd love to eventually partner with publishers but especially larger ones probably won't want to talk to us until we have millions of paying users and can offer them a significant revenue share.
So until then, is the revenue share that you owe to them a permanent liability on your balance sheet?
Lots of questions here, but as I stated in another answer on the topic we're committed to keeping all payments open and transparent. This can only work if everyone has insight into who's getting money for what.
The only way to prevent our users from reading your articles though would be to require some sort of authentication to access them. Same way you block anyone from accessing your content through any web browser or extension.
1. You are taking money directly from customers 2. To serve content that you do not have the right to sell access to.
> If we had paying subscribers that were reading your content and we reached out to you
That sounds like a lot of ifs. It sounds like you're making money directly off access to my content which makes me deeply uncomfortable. If you reach out to me, and you're unsuccessful in contacting me, you're still making money directly off my content whether I chose to monetize it or not.
2. No. We are not serving content. The user's device makes a GET request to your server and you serve the content. Readup just displays the metadata and a link to the article just like reddit or Hacker News.
1. Doesn't work on Safari. Definitely not a great first impression.
2. Sure, let's switch to Chrome (one of the three supported platforms: Chrome, Firefox and iOS). Now all I get is a blocking modal "To read on Readup, add the Chrome extension. Add to Chrome — It's Free". Sorry, not about to install an extension for something that hasn't explained why it needs an extension, let alone demonstrate any value to me, whether it's free or not.
Stalemate.
So let me ask: how do you tell a skim from a read? How do you distinguish a complete read from scrolling down to comment section (maybe even slowly)? Reading speeds vary greatly, and there's no mind-reading web API yet.
1. Safari uses a completely non-standard extension model and right now I'm the only developer so we're Chrome and Firefox only for the time being. Definitely sucks.
2. That's great feedback on that modal. Seriously, it never even crossed my mind that we don't explain why the extension is required before displaying it. Also that the "Add to Chrome" button makes it seem like it will trigger an install instead of bouncing you over to the Chrome store where you can see screenshots and a description of how it works before choosing to install. We really need to fix that ASAP.
Re tracking: When the extension is triggered (limited permissions, it only runs when you click the icon) it runs a script on the web page that tries to identify the primary text of the article. Once identified, we mark the individual words as having been read, starting at the top left of the viewport. Since we keep track of individual words you can scroll around and read out of order and the tracking will still work properly.
This process runs on a timer that allows for a pretty fast reading speed (probably around 500-600 wpm) but doesn't allow a user to just sit on the page for a long time or scroll right to the bottom. As you point out you can cheat it by scrolling very slowly through the entire article. Still waiting on that mind-reading API!
Re extension: I'm not clear on why an extension is needed for reading on readup.com (as opposed to on publishers' sites). Seems to me you can do all the tracking just fine with regular sandboxed JavaScript running on the web page? To be clear, when I'm not logged in or on an unsupported browser, I'm presented with two options: "Read it on Readup" (with a "Get Started" button) and "Continue to publisher's site", the former apparently being the recommended path; when I'm logged in there's only the "To read on Readup, add the Chrome extension" modal, but if I understood what you track correctly, reading on Readup shouldn't require any extra capabilities, whereas reading on publisher's site should. So in theory a user should be able to read everything on readup.com without using an extension, just like they would on instapaper.com or feedly.com (but with some added tracking). Is that not the case simply because you haven't had the time to develop native tracking, or did I miss some fundamental limitations?
Re timer: 500-600 wpm is pretty fast on average but I can certainly beat that when reading information-sparse content (e.g. most digital magazines) or when I consciously try to read fast, and I know people who read way faster than me... Also note that some people can maintain a high comprehension level even at high speed while others struggle to comprehend even when reading word by word. I guess your compromise may be okay, but it's certainly rather crude (not that I have a better idea).
Btw, Safari 14 is adding WebExtension API support.[1] (You're probably already aware of this but doesn't hurt to share.)
[1] https://developer.apple.com/documentation/safariservices/saf... (documentation is crap though, at a glance)
> I guess your compromise may be okay, but it's certainly rather crude (not that I have a better idea).
Haha 100% agree. One day, maybe a reading speed calibration during new user onboarding? As you pointed out though, speed varies even for an individual depending on what kind of content they are reading.
> Btw, Safari 14 is adding WebExtension API support.[1] (You're probably already aware of this but doesn't hurt to share.)
Wow, I was not aware! This is awesome! Thank you for sharing.
Couple questions
1) You mention a paywall, but your video says that users who sign-up before paywall stay in forever. You honoring that (the video was posted 5 days ago)? I see that the median comment count on your site is about 3 so I should hope so
2) How exactly are you paying these authors? We can post articles from anyone and then trust you're able to get in contact with them and hand them their money?
1. Yes, we are honoring that! It's a reward for being an early adopter and it's important to keep the community "starter culture" intact as we move to a paid membership model.
2. We don't want you to have to trust us. That information will be transparent. Check out our current writers leaderboard [1] as a prototype of how that will look. Minutes reading to completion is our basis for payments to writers so you can imagine a pie chart on your account page that shows who your $5 went to for that month in addition to a community-wide distribution that would look similar to the current leaderboards.
As you can imagine there will be cases where we can't get in touch with writers or they're not interested or something like that. We'll probably have to have some sort of time-out period where the uncollected funds might be reallocated to writers who have verified with us or something of that sort. The important thing is that we're committed to making these rules and decisions transparent.
Why is there no tagging or other organization (besides per author)? Skimming through the frontpage I either have no idea what an article is about or it appears to be some lowest-common-denominator politics article. With reddit I can go read my niche subreddits with topics I actually care about (yeah, I know you don't have enough users to replace this quite yet, but still). With no other hooks for following my interests I feel like this is still abusable with clickbait titles.
Could you have like moderator-written abstracts for the AOTDs, at least? Even better would be an abstract for every article (not sure how you would accomplish this)
The only reason is because I'm the only developer and simply haven't had time to build it yet! In fact right now I'm working on a new "Discover" screen that will allow filtering by publisher and topic. We gather "tag" and "description" metadata for articles even though it isn't currently displayed in the UI.
> With no other hooks for following my interests I feel like this is still abusable with clickbait titles.
It's not a perfect filter by any means, but keep in mind that even if an article title looks like clickbait it will only rank highly if users are finishing it so the real garbage usually doesn't float up since people chose to abandon those articles. Again, not perfect by any means but it is something to consider if an article is more than a few minutes long and has a lot of reads on it.
> Could you have like moderator-written abstracts for the AOTDs, at least?
Yes! When the AOTD email goes out (midnight PST every night) it includes the "description" metadata provided by the publisher if present (seems to be available about 90% of the time). We should definitely show that in the UI on the web app too for the AOTD at least (and maybe have some expandable toggle to show it for other articles).
I see you're using React on the frontend. And, you only have an iOS app but not (yet) an Android app. Are you not using React Native? In that case it's fairly easy to target both platforms. I know RN is a bit of a shitshow but not supporting the biggest mobile platform in the world is arguably worse
> We gather "tag" and "description" metadata for articles even though it isn't currently displayed in the UI.
If you're taking this metadata directly from the articles I'm skeptical about the accuracy/completeness. Anyway, it's better than nothing I guess
> It's not a perfect filter by any means, but keep in mind that even if an article title looks like clickbait it will only rank highly if users are finishing it
This is something, but still high-quality articles with clickbait titles will outcompete high-quality articles without clickbait titles. Incentive still being: write clickbait titles. Anyway, if someone is 0.25x as likely to finish a bad article having clicked it, but 10x more likely to click a clickbait article, you still have a major problem beyond "not perfect", imo
I know it's a big ask for you to solve every single problem with online reading/discussion but this one is so tangled with the rest it's kinda hard to ignore.
Today's AOTD: "If Everyone Else is Such an Idiot, How Come You're Not Rich?"
From the past few weeks, some selections:
- "Meet the social media echo chamber that is radicalizing you & your friends. - Alexa Rohn" - "Racism Is Terrible. Blackness Is Not." - "A White Woman, Racism and a Poodle" - "The American Press Is Destroying Itself" - "Dear Fuck Up: How Do I Figure Out What I Want in Life When Every Day Feels the Same?" - "You Should Be Feeling Miserable" - "Tom Cotton: Send In the Military" - "The Sickness in Our Food Supply"
I'm sure some of these are great, but be honest: did the title have anything to do with people clicking through?
> Are you not using React Native?
Not even! Our iOS app just uses WKWebViews for the main UI so yes it would be pretty trivial to do the same thing on Android. Only excuse is that it's in our backlog with 100 other things that we also really want to build.
> If you're taking this metadata directly from the articles I'm skeptical about the accuracy/completeness.
Haha yes, it's an absolute clusterfuck that I'm currently trying to clean up enough to make useful. The descriptions are usually actually pretty solid, but there is so much noise in the tags/topics.
> This is something, but still high-quality articles with clickbait titles will outcompete high-quality articles without clickbait titles.
Yes, yes, yes! I think providing more context in the way of the description could help to cut down on this, but you're very right that there is no easy or complete fix (at least not that I can imagine!). Something else to think about would be looking at the ratio of clicks to completions instead of just the sum of completions alone. That way in your example the 10x likelihood of a click could be cancelled out by the low 0.25x completion rate.
Good idea. In addition to better metadata for boring titles, penalizing articles which have a low completion rate would probably help
Good luck! I'll keep an eye on the progress
Thanks!