hmkoyan

Thank you for your comment. Yes, it is possible to import via ISBN scan. Currently, there are three ways to add a book:

- searching (which uses the Google Books API under the hood)

- manual addition (which nobody wants to do — I completely understand — but is the only option for old books that cannot be found online; I have a lot of these)

- scanning the ISBN (which also uses the Google Books API).

I'll certainly consider the labelling feature and add it to the backlog.

Thank you for your comment and for raising the issues.

When you set the book status to 'Read', an edit pen appears to the right of it (in the same area where you set the status), which you can click to edit the start and finish dates. Please note that when you set the status to 'Read', it's assumed that you've read the whole book, and this is added to the 'Pages read this month' statistic. Conversely, when you set the status to 'DNF' (Did Not Finish), you can set start and end dates again using the edit pen, as well as providing a progress update, i.e. how many pages you read before stopping.

I've been dedicating my time after work to this project for several months already, and I plan to continue doing so for a long time. I'm going to use it a lot personally too, so that's a big part of my motivation, to be honest.

There's actually. Currently there are three methods of adding a book:

- searching (which uses the Google Books API under the hood)

- manual addition (which nobody wants to do — I completely understand — but is the only option for old books that cannot be found online; I have a lot of these)

- scanning the ISBN (which also uses the Google Books API).

Thank you for your comment. The text on the dark mode page at https://app.librari.io/subscription should now be fixed. Thank you for pointing that out.

I plan to suggest a freemium tier and two affordable paid plans. However, as it's still in beta, it's a bit soon to provide any specifics, to be honest — I still need to figure those out, too!

Regarding the bulk import, yes, that's in my backlog and will start working on that soon.

Indeed, librari.io is designed for managing physical books. Moreover, if calibre was intended for managing not only ebooks, I would personally prefer to use google sheets because calibre's outdated UI is sufficient reason for me not to use it, although it may still be functional.

Thank you for your comment. Yes, the ability to extract from a picture is something that many people would also like to see, as well as you. I'll definitely think about this and add it to my backlog.

Thank you very much for this detailed comment — it is indeed very useful to me. The import feature is certainly on my radar and is something that I'll start developing very soon. You're absolutely right that it would make onboarding a large collection really easy. I'll take note of the other features you mentioned too. Thank you again!

Thank you for the comment. librari.io already uses OpenLibrary for metadata enrichment, but I'll definitely check out the others too. I'll definitely check out Colibri — thank you for sharing!

Yes, I can certainly be open and provide a lot of detail. The landing page is a standard Next.js application hosted on Vercel. The web app itself is a React app that uses Shadcn, Tailwind CSS and TanStack/React-Query, and the backend is a Node.js application. I use PostgreSQL and Redis instances to store data in the long and short term, respectively. For deployment, I use Dokploy, which is an excellent way of deploying stuff in containers and making them communicate with each other (and actually this is my first time that I use it). You can self-host it on a VPS, which is what I do. Finally, I use AWS S3 for object storage and backups.

I would definitely use this tech stack again if I were to start again. The only thing that may change in the future, when there's a lot of traffic, is how the app is served and hosted overall. Currently, it's on a VPS, but depending on the traffic volume, it would make sense to switch to AWS infra (e.g. using lambdas etc) at some point in the future.

Thank you for your comment and for explaining your problem in such detail. Currently, you can mark your library as public and share the link with others, but they can only see the books in it. What you're saying actually makes total sense, and I will add this feature to my backlog.

Thank you for your comment. Libib is indeed a well-established player in this industry. Although it suggests a lot of different functionalities/features, it lacks detailed statistics/analytics regarding users' reading activity, libraries and content. It also doesn't allow you to create your own data fields for storing information about books, authors or publishers. Regarding data extraction from photos, I considered this method initially, but then decided to leave it until there is specific feedback regarding this. Apparently, people would actually use it, as another user also pointed this out in a comment.

Thank you for your comment. Currently, there are three methods of adding a book: searching (which uses the Google Books API under the hood), manual addition (which nobody wants to do — I completely understand — but is the only option for old books that cannot be found online; I have a lot of these) and scanning the ISBN (which also uses the Google Books API). I initially thought about adding the method you suggested, where you provide a picture and then extract the information, but I decided it was not the right time to implement that. So, I left it for later, when there is any need or feedback regarding it from users. From your comment, I understand that it's something that users might actually consider using.

Thank you for your questions. The actual app can be used/seen only after signing in. Regarding your questions:

1. This was initially planned as a web-based application, and it still is. However, when it comes to mobile responsiveness, it's not great — something I've pointed out and am currently working on. I'll finish this work during the weekend. Creating native apps will probably make sense in future, too.

2. Yeah, as it's only the beta version at the moment, the pricing doesn't mention anything specific. I believe there will be three different pricing tiers. There will definitely be a freemium version with some limitations, e.g. a limit of one library and 100–200 books in library, and access to basic statistics only. I need to think more about the pricing in more detail, as I've only concentrated on building the product so far. However, in general, I imagine it to be as I've already described above.

3. This is a very good question, to be honest, and one that I haven't thought much about either. I would probably use a locally hosted application if it offered all the features that librari.io offers. However, I can think of some reasons why a user might want to use a web-based solution. Firstly, I assume that syncing across devices would be difficult when the application is hosted on only one device, unless it offers export/import functionality. Backup and reliability are other reasons why a user would opt for a web-based solution. I believe that the ability to share your library with other people or family members using a link, which gives them access from anywhere at any time, is a good reason to opt for a web-based solution.

4. I can outline the three most significant issues I encountered, which eventually led to the development of this app. The first is the outdated UI that most of them suggest (but of course, I'm not saying that librari.io's UI is the best). The second is the lack of library statistics and analytics (e.g. distribution tables of books, authors, etc. or content-wise and reading activity related statistics). The third is the lack of customisation. For example, the ability to add custom book, author and publisher data fields with different types, such as text, date and number, and then attach actual information to those fields when editing those entities.