BooksShark / Raamatuhai

A bookstore asked us whether customers who could trade unused rewards could also trade the books on their shelves. We had been working on loyalty programmes, but this gave us a concrete use for the marketplace technology. ISBNs let us find catalogue information for an existing book and use it to prepare a listing.

We wanted sellers to spend less time entering information and deciding on a price. Buyers needed to compare offers for the same title, including the condition of each copy and delivery costs. Publishers could add new books alongside used ones and learn more about demand on the resale market.

We also wanted to put Perxify to use ourselves. I had spent plenty of time discussing what the infrastructure could do with prospective clients. Running Raamatuhai meant we had to connect that work to a completed purchase and deal with whatever happened along the way. We initially expected technology sales into other sectors to help finance it.

As we developed the marketplace, we explored publisher royalties on eligible resales and recurring referral income for reading communities. We also considered how to separate the software, marketplace operations and physical fulfilment. These ideas needed their own business models and further work; we did not launch them as a group of businesses.

We developed barcode and ISBN-based listing, then added photo recognition, OCR and price suggestions. The software prepared the listing, while the seller confirmed the information and described the particular copy. We grouped offers for the same title so buyers could compare sellers without working through duplicate product pages.

By the December 2025 launch, BooksShark ran on our own Perxify infrastructure. AI catalogue enrichment, deduplication and exception handling were already part of live commerce, alongside Stripe Connected Accounts and DPD. We had to connect the catalogue record to the offer, payment and shipment so that the information stayed consistent through the purchase.

We added wishlists, grouped books from the same seller into one shipment and generated shipping QR codes. Sellers could request withdrawals and see their statistics. We also built customer-service support, dispute and return modules, and a browser extension that showed our offers while people browsed other bookshops.

Buyer-side AI was still an MVP being tested internally during the early launch period. Wider European shipping and a cart spanning multiple sellers needed further development. We also explored digital ownership records through Perxify, but the seller still had to describe the condition of the physical book.

By October 2026, all marketplace processes were automated except withdrawals. The quality of the catalogue data still mattered. We could recognise a book in a photo and produce a poor listing if its ESTER record was wrong, so checking the match and correcting the information remained part of making the product dependable.

We reached more than 500 users, over 2,000 listed books and over 100 sales in total, with zero marketing spend. People were using the listing tools and buying books from each other. I was pleased to see that happen after spending so much time building the underlying technology.

We signed four publisher letters of intent in early 2026 and later brought our first publishers onto the marketplace. That added new books alongside the second-hand selection. The letters and the onboarding were separate steps; we still had work to do on demand and repeat purchasing.

The funding problem had started before Raamatuhai. In September 2024, investors asked us to come back with two clients. We worked on finding them, but the final large prospect cancelled in spring 2025 because of limited funds. We then built Raamatuhai ourselves and resumed fundraising in January 2026 after the launch.

After eight months, we had secured no financing. Of three potential leads, one cancelled, another lost the available funds through bad investments and the third postponed until 2027. We had been bootstrapping since 2024. To commit to customers, we needed external financing that would cover at least six months of work, and we could not keep relying on money that might arrive later. In October 2026, we closed the marketplace in its existing form and paused active development.

I learned to give catalogue quality the same attention as the listing interface. Recognising a title does not establish the edition or the condition of a used copy. I would make responsibility for correcting the source data clear from the start and include those corrections in the product work.

I also let the scope grow faster than our resources. Customer conversations gave us useful ideas, but each addition took engineering time and money. Software, a marketplace and physical inventory have different costs and operating needs. I would work through those separately before asking a small team to take them all on.

I waited too long for the funding to resolve. Investor interest encouraged us to keep working, while the cash available to us stayed the same. I would now agree a point at which we reassess the work and reduce it to what we can actually finance. A delayed round needs to change the delivery plan when it starts affecting what the team can support.

I now use a complete order when reviewing a commerce product. I follow the product information into the listing, check how the price is confirmed and continue through payment and delivery. Raamatuhai made it much harder for me to overlook an unresolved step just because the screens before it worked well.

I also keep user numbers, listed products and completed sales separate when assessing progress. Our early figures were encouraging, and they grew, but they did not tell us how we would fund the next six months. I want the operating plan to show both the customer activity and the money available to keep serving those customers.