Show HN: IndiePaper – An easy way to write and sell self-published books
indiepaper.me
indiepaper.me
I would also consider reading through the main copy and fixing any inconsistencies with spelling, capitalization, and wording ("the occasional fraud"?).
English is not my first language, but its still no excuse, I had run it through Grammarly, will check again for mistakes.
I created a course platform Primerlabs (https://primerlabs.io), where learners can generate Personalized Notebooks at the completion of the course. I used the Tufte-Latex template for that purpose. You can checkout my Personalized Python-I course book here: https://book.primerlabs.io/P2i3yuzb8
The goal is that, at the end of the course, people can actually buy their personalized at hands, with the click of a button.
I use Latex on AWS Lambda to compile LaTeX. If you need in compiling LaTeX, feel free to reach out to me. Email is in the profile.
- It would be nice to have a sample book or two featured on the homepage.
- About print-on-demand, where is it printed and shipped from? Perhaps an FAQ page can answer some of these questions.
- A new design is already in the works which shows published books right on the home screen.
- We integrate with a third party print-on-demand service that has printers in almost all major countries, once the order is made the book will be printed nearest to your location and then shipped to you directly.
Also the FAQ is coming, I wanted to get an MVP out fast.
Can you tell the name of the service? I was looking for one.
Indie authors sales these days are almost all ebooks. Actual indie physical book sales are tiny. Do you plan to generate ebooks?
Authors are notorious for sticking to their favorite writing tools. You might want to call out what import options you have.
Generating Ebooks (PDF, EPUB, MOBI and Online Versions) is the main core of the product, we would generate beautiful typeset ebooks from your draft text.
Although now the only import option is copy and paste, we are working on rebuilding the editor and once that is finished we would have import from word document, since that is the most common formats among authors.
This is something even big services often punt on because of the complexity involved.[1] Not only do you have to collect taxes, but you also have to pay it to the appropriate government. You then have to file periodic returns in each jurisdiction.
The simplest solution for the user in such cases is to let the service become the seller/intermediary between them and the customer. That leave them with just one headache to deal with: whether any income tax is due in the country in which the intermediary is resident/incorporated.
[1] Even Stripe Tax doesn't seem to handle GST in India. (https://stripe.com/en-in/tax)
I'm currently self-publishing a series of books about software development & it (https://dev-concepts.dev). As you've mentioned it is indeed quite complex to get up and running and generate beautiful output.
I've chosen to use AsciiDoc and created a template (https://github.com/dsebastien/e-book-template) based on Matt Raible's work for InfoQ books (https://github.com/mraible/infoq-mini-book). It's far from perfect, but it's a good starting point.
My first book was published by Packt, and I also used Asciidoc for the initial draft, but then had to switch to their wordpress-like platform, and it was a real nightmare to use. Being able to use Asciidoc end-to-end feels so much better.
I still haven't decided on what input format I should be using, most authors are familiar with a WYSIWYG style editor, but technical authors are more inclined to markdown like formats.
Authors are more inclined to switch with the writing tools they already own, so I think multiple import options and a single editor representation would be better. Upload a bunch of files of asciidoc or markdown and get it published.
During university, the only notes we had were shabby scans of handwritten notes. I love typefaces and beautifully typeset documents, especially the ones made with LaTeX, so I decided to create a set of beautiful notes tailored to our university syllabus. I wrote a bunch of notes as a collection of markdown files in Vim, used Git for change tracking, Pandoc for conversion and LaTeX for typesetting. I set up a GitHub repo [0] and a CI/CD pipeline which would typeset and publish the notes online for students to download [1].
Fast forward a couple of months and I wanted to write my own book, I found out how hard self-publishing was, especially for non-technical authors. They had to juggle a multitude of tools and people to make a finished book to the hands of their readers. They would write the book in an editor like Word, then either use the PDF export or hire someone to typeset it, then set up a storefront and then spent most of their time handling payments and returns and refunds. Launching a print-on-demand version of the book meant doing all this again. I wanted all the authors to have the simplicity of the workflow I had with my typeset notes. Write your draft, click a button and you would have your own beautiful finished book ready for sale. That is how I came up with the idea of IndiePaper.
I have been working on it seriously for the last four months, and it is a vanilla Elixir Phoenix monolith hosted on Fly. It uses AlpineJS for lightweight client-side interactions and TipTap for the editor. I had shipped an initial version which enabled Authors to upload their already finished books as PDFs we would make it available on print-on-demand, but modifying different PDFs to fit the printing specification was not feasible. So I rewrote it from scratch to have the editor side done, so we have the raw text to typeset to the exact specifications for printing.
Currently, authors can write in the editor, add and rename chapters and when finished with their draft, publish it. A web readable version will be generated which is can be bought by readers and the amount will be transferred to the connected Stripe account of the author. Here is the entire flow with screenshots [2], the generated store front [3] and the online reader [4].
The platform is nowhere finished yet, consider this a first MVP, next on the list is image uploads, rebuilding the editor to make it more stable, typesetting engine, print-on-demand integration and word import. It's my first time building such a platform let alone a company and I'm figuring out a lot of things along the way (it's a whole lot of fun though).
I love books and authors and believe this would make the process of making beautiful self-published books a whole lot simpler, and the process of buying and reading them a lot more fun. What do you guys think? All feedback and questions are welcome :)
[0]: https://github.com/moot-books/moot-KTU
[1]: https://moot-books.github.io/moot-KTU/CSE/S6/CN_CS306.pdf
[2]: https://twitter.com/aswinmohanme/status/1444673276668616707
[3]: https://pbs.twimg.com/media/FAyA76QVkBIe8fS?format=jpg&name=...
[4]: https://pbs.twimg.com/media/FAyBeE3VIAQvggH?format=jpg&name=...
It's in alpha state and can make the book readable online, typesetting and print on demand coming soon, do check it out and and give your suggestions and thoughts. Cheers :D
I like the concept. What binding options are available?
That said, I miss any kind of examples on the site. Let me see a finished ebook, let me try the editor. And because I am a technical writer, I have to ask. Will you support technical books? How will you handle code snippets, highlighting, or line comments?
I really liked your detailed write up on the publishing chain you have used, code is just text in it's essence and because of that programmers have access to superior tools for it's manipulation. But that power is hidden behind a steep learning curve. IndiePaper is just the collection of tools you have specified all integrated and wrapped up as a web app.
Regarding examples, I never thought this would blow up on HN, that's why it doesn't it even have an FAQ, I'm working on a new design that would bring published books of the platform front and center.
Technical books are and will be supported, even though technical authors have the know-how to setup up a publishing toolchain, most would love to write in a completely integrated platform. Since we control the entire editor, we can and will support code snippets, highlighting and comments by adding to the text-editor raw structure and processing it during typesetting phase.
IndiePaper was actually ideated with rich technical books from the start, features like code integration with Github were all thought of from the start. So IndiePaper will have first class support for technical books.
So long as sales are via the publishers website, they can absolutely defraud the author, but such is the case for the sale of any digital good.
I guess you could setup a "registration" scheme (e.g. to sub to errata) whereby readers need to supply their purchase code, which would reveal extra/double sells.
Scary!
The promise, from your home page, is that I can write my first draft on your platform, but the reality is a big "there be dragons here" disclaimer.
Some suggestions:
- Give me a way to export my book, perhaps as a zip file with each chapter as docx or odf.
- Give me a way to upload each chapter.
- Once the typesetting engine is finished you can export the books and sell on your preferred platform.
- Uploading each chapter would be finished when I move the editor page to a SPA. That way we can get a more stable editor and a better authoring experience.
Loosing a few seconds of work isn't that big of a deal. It certainly isn't worth a scary warning.
But, what's more important is to warn when saving isn't working.
“Request failed, you have exceeded maximum number requests. Please try again after 1 hour(s).”
- Text Editors - with the exception of some specialised tools, text editors are seldom made for authors, they are either too much specialised or too little. Building a custom word processor precisely for authoring means we can fine tune the writing experience.
- Exports - Almost all of the default export options suck, they create unreadable messes of typography with zero consideration for making something beautiful. There is a reader on the other end of your books, it is our duty to give them the best reading experience. With our own typesetting engine we can create beautiful looking books at the click of a button.
- Selling - This is where most of the competition lives, you can publish on KDP but need to stay in their price bracket or they take 70% of your book price. Setting up blurb is not easy. Even if all this happens, you would still need to provide support and handle returns and refunds.
I believe Authors, Readers and the entire publishing landscape would benefit from a fully integrated platform, but only time will tell.
Edit: It's live at https://status.indiepaper.me/
This should probably be replaced with:
"We know you'll love it, and your readers will too."
Prose-minded customers might be a little turned off by slightly grammatically incorrect copy.
[EDIT] - Two more things:
- "Heyy" in the page title
- "we know you'll love [IndiePaper]" might be better than "it". Getting your project's name to stick in heads is probably easier with more mentions
Professional author here. It's a major, eye-rolling turn-off to see the grammar and punctuation errors, and to be honest, the breezy response is also a turn-off and screams amateurish effort.
If you are posting this on HN, accepting users, and (presumably) taking payments, then you have already publicly launched, and you should have done this already.
I understand that it's a side project, but if you want to have people take your business seriously -- and a business marketing to writers, of all people -- then you've got to make sure your homepage copy is beyond reproach.
> If you are posting this on HN, accepting users, and (presumably) taking payments, then you have already publicly launched, and you should have done this already.
This seems like an overly stringent requirement for Show HNs. The guidelines say no such thing[0], and in fact they say the opposite:
> A Show HN needn't be complicated or look slick. The community is comfortable with work that's at an early stage.
I thought what drew people to HN in part was the ability to see fun and possibly unfinished/amateur but interesting and thought provoking content.
But what about meeting all three of the conditions I laid out in the sentence you quoted: (1) marketing the site to the public, (2) accepting users, and (3) taking payments.
Arguably, at that point, you have veered out of hobby project territory and have publicly launched a business -- and that's where my criticism lies.
There are a couple of stylistic choices you might want to consider as well. You've got quite a few run on sentences. And most writers use "word processors" not "text editors" (assuming you're going for the average writer, not the HN crowd).
(Just trying to be helpful, please don't take this as criticism. Congrats on your launch!)