overview

WeBundle.It is the brain-child of a well-known science fiction writer, and it was his dream to be able to sell digital media online (ebooks, music, games) in a unique way: bundles. You may have heard of HumbleBundle or similar sites, which package a collection of curated content in a name-your-price fashion.

This offers consumers amazing deals on amazing content, leading to more sales and therefore a high potential for revenue by royalties to the authors. Bundling is attractive to publishers, authors, and readers alike.

Most bundle sites curate their own content, which is fine, but it leaves little room for other people to make suggestions about the content they’d actually like to see, or for other authors or publishers to suggest content that the curator would otherwise be unaware of. If lesser-known authors have content bundled with “hotter” authors, they also benefit because, being sold as a bundle, the revenue is split up evenly among the authors.

The twist is that WeBundleIt is a type of social network, connecting authors, publishers, and readers in a way that lets anyone curate bundles, but they would have different scopes. For example, you might wish to curate a bundle for your mother-in-law consisting books and music that she likes, and she would be able to enjoy the content (in bulk) for pennies on the dollar. Authors and publishers could curate bundles that would go through a sort of review process, ultimately deciding what the next “public” bundle would be.

The publishing company for which this author worked agreed to fund the initial development of this platform. A company that I owned at the time was selected to design and develop the system.

requirements

While I’m not formally under any NDA, I will omit details about the social aspect of this platform. Those details are considered proprietary.

  • Content creators must be able to log in, upload and organize content, and content should be converted between formats (EPUB, MOBI, PDF) if all files are not uploaded by the author
  • Artwork is to be scaled and linked to its respective content, and basic editing tools should be provided
  • Curators should be able to draft bundles, selecting works and setting bundle parameters
  • publishers need to be able to create “homepages” which would feature works that they have rights to, and other promotional information
  • Authors will have biography pages
  • Payment should be painless (PayPal to start, credit cards and alternative methods down the road)

solution

Pricing. I can’t go into details about this, but there is a traditional pricing/royalties model that publishing companies use when authors sign with them. When books are sold, some of the money goes to the author, some to the publisher, some to marketing, etc. Everything trickles down. In our case, however, the contract that the publisher had already negotiated with its authors would only leave us 0.05% of net revenue. This would be fine if we could gross a million dollars in sales each month, enough to cover the cost of two developers and finish the product.

Miscommunication. The intermediary handling negotiations between us and the publisher stated that he had negotiated for 8% of net sales. What he actually negotiated was 8% of the 1.5% of net sales that was allocated to advertising. This was catastrophic: when the publishing company found out about the miscommunication (entirely the fault of the negotiator), they let him go, were outraged at the fact that the system would cost multiples more than they had budgeted for, and my team found out that we would be earning multiples less than originally agreed.

Negotiation. After a week of long discussion, I managed to restructure their model in such a way that authors received a more competitive percentage, the publisher made more, and that my company would receive a whopping 15% of net revenue (after charities and the publisher were paid), which would go cover development, hosting, maintenance, and support. All around, the new model was fair and all parties were really happy with it. Now that we had cleared up how the money was being split up, we could begin development.

Scalability. Digital books aren’t necessarily very large, but that doesn’t mean it’s a trivial amount of bandwidth if enough people download the content. And what about music, games, etc.? We need to think big, but start small. The challenge becomes scalability, at least in terms of media distribution. The main website and payment section are not a big deal; they can handle dozens (hundreds?) of transactions each second. Down the road, if we’re selling 50,000 copies of a bundle which could average 100-500MB, that’s potentially 25TB of bandwidth every week. No problem for even a dedicated gigabit line. It would make sense to employ a distributed CDN for media delivery. Ultimately, we didn’t need to go to Amazon or some other CDN (more on that later).

Platform. At the time, it made sense to use PHP/MySQL with appropriate replication and redundancy. We ended up using Facebook’s HHVM as a drop-in replacement for Zend’s PHP because of performance, but it really wasn’t necessary at such a small scale (a few hundred sales per day).

Delays. One of the biggest issues we faced was delays between authors and the publisher, and the publisher to us. Each author was supposed to sign a contract allowing the publisher to use their works on our platform under certain terms. If an author did not sign this in time, then their works could not be included in the bundle, and the system was not (yet) designed to handle this, so bundles that were not complete had to be hand-packaged and uploaded to the server. Another problem was with the text (book descriptions and author bios) that the publisher provided; there were spelling and typographical errors all over (yes, from a publishing company), and since I refuse to put out any work that is anything less than my best, I spent a lot of time cleaning up some of this copy.

features

Many of the features that were to be implemented were finished and tested. Everything short of the proprietary social networking aspect of the platform was completed and working, but in the end development stalled because there simply was no money. See the following section for more information.

results

WeBundle.It was off to a rough start. The publishing company agreed to take care of all advertising and promotional efforts, which they had difficulties doing. Trying to market digital content unlike anything they were used to, and so the first bundle performed much worse than even our lowest estimates. Because of this, and our contract with the publishing company, we were paid our initial deposit for “get-it-to-market” development, but there was no money to continue development.

I took on the project, personally, in good faith and continued development for several more months, but sales for the five successive bundles were consistently low, and even the authors were starting to complain about not receiving any money.

At some point, one of the authors must have reached out to a lawyer because I received a cease-and-desist letter about having unauthorized copyrighted content still on display on the website (the book cover and its description). I immediately suspended the site and have since stopped working on it. And that’s where it stands.

Many lessons have been learned from this endeavor.

Feel free to check out an archived snapshot of the site.

screenshots

Homepage…

WeBundle.It

Author / Curator / Publisher login page (to access back-end). Because this project was never completed, much of the back-end is basic Bootstrap. Additional styling/branding would have been done after the functionality was in-place.

Login Page

Navigation menu of back-end. The details of this are protected by a strict NDA. I can say that all of the functionality for authors and curators to upload books and organize bundles was implemented. The Customers tab allowed lookup of any particular customer, or to group customers by one of many criteria. The Royalties, News, and Settings tabs were not completed. Instead, author and curator royalties were calculated by hand at the conclusion of every bundle.

Control Panel