I am pretty sure this is the case. I have worked with small and large teams. Large teams usually have a lot more abstraction in terms of their architecture. So there is most likely a "backend" app that is just an API and you consume it in your "frontend" (node, rails, etc) whatever that may be.
Frontend in this context is just another server that is communicating with backend APIs using RPC. When small teams think of frontend, they usually think about a framework like React, etc and pair it with a backend like Rails.
We've put a lot of effort into making the UX as seamless as possible, trying to mirror the in-app purchase experience of native apps. We're also signed up for Stripe's Apple Pay on the web which should make the process even smoother.
I guess doing so wasn't necessary and it was probably better not to give those who would complain a toehold. Anyway, it's not like the "apply Hn" is a feature.
Hi! We decided to take a proper stab at this problem space and are currently at the stage where we would love some feedback from the HN community.
The best way for getting a feel for how it works is going to our demo publication and browse some articles: http://www.getexplorerr.com/
If you decide to sign up through the publication and then go back to our site, you will be automatically logged in to your profile: https://www.scriber.io
We've put a lot of effort into the integration with publications and making the user experience of signing up and purchasing articles as seamless as possible, upping conversion by removing as many hoops the users have to jump through as we can.
Please let us know what you think, any feedback is greatly appreciated!
It's an interesting take on the problem, tracking who has bought what - and for how much - through block-chains, opposed to having it stored in a database.
I think it would be a bit hard to use for your average user though with the current state of block-chains, we're working really hard to make the sign up and transactional steps as easy and painless as possible. And it would have to be managed through a platform somehow.
But we'll definitely keep an eye on how they get along with Mycelia, thanks a lot for pointing it out!
Our approach is different than Blendle's and we believe that both of us can happily co-exists.
To read articles using Blendle you have to do so through their app, where they act as a curator. They offer a select number of articles that they think you will like. If you want to read an article you have to pay a small fee that is split between Blendle and the newspaper that the article originated from. Some readers really like this approach since everything is gathered in one place, and Blendle's execution is top-notch.
We believe however that many readers would like to be their own curators. Many already frequent aggregate sites - like Hacker News - to find content they think they will like. And we would like to give the publishers of that content the ability to offer it through seamless micropayments, using their own apps or websites. They will then be in control of the entire reader experience, not having to outsource it to a third party.
So we believe Blendle and Scriber can happily co-exist since we basically cater to different audiences.
The payment gateway will probably be Stripe. They support "auth and capture", which is necessary with our plan to gather a user's micropayments into one combined monthly bill. We might also include PayPal if there is demand for it.
We've been discussing when we want to ask the users for their payment information. We want the sign up process to be as fast and painless as possible, so we might give the first article away for free, and only ask for payment information if the reader decides to buy a second article.
Once a user has saved a payment method to their profile, they won't be bothered about that aspect ever again when buying articles, we just charge them once at the end of the month for all the articles they've purchased that month.
So you plan to bundle all the payments into a monthly bill to avoid fees on each transaction? Doesn't this assume each user will be purchasing enough content to make the fees negligible?
It's partly to lessen the fees being paid for processing each charge, but also part convenience for the user. We actually implemented a prototype top-up system to see how the user experience would be, and everyone who tried it agreed it was fairly cumbersome so we quickly scrapped that idea. And bundling the payments makes for a cleaner card statement, although that aspect is fairly individual.
As for the volume we would have to do; Stripe for instance charges 30 cents plus 2.9% for each charge, so the first article a user buys per month pretty much covers the flat fee, after that the percentage acts the same regardless of volume.
Great feedback though! Keep up with the questions.
I was working on a similar service using Bitcoin so the idea was mostly centered around maintaining control of your money and negligible fees. Our main issue was lack of a market to pitch to, but this idea is definitely something that I would hope becomes a reality.
We looked into using Bitcoin as well, but it proved a bit too hard to use for the average user. We did some user testing with a few prototypes, and it was really hard to make it work as seamlessly as we want the process to be.
As for the market, luckily we're based in London which is home to many of the most reputable news outlets in the world. We're already in talks with some of them, but it is indeed a hard industry to try to disrupt.
I'm going to go out on a limb here and guess that you don't work in a large team with other developers, maintaining a common codebase.