In my last post, I shared why I built my own ebook metadata editor and how it came together. Deciding to publish it earlier than expected, on a whim, proved to be a crash course on what to consider before going public.
While the main functionality seemed up and running, and with New Year’s Eve approaching, I decided to drop a message to the selfh.st newsletter, which according to their website has over 20,000 subscribers. Things moved faster than I expected. Ethan replied the same day that it would be on the new software list in the next newsletter. Fast forward to the next day, and Self-Host Weekly #152: Wrapped landed in my inbox, and reality hit me.
I panicked, and in a last-minute decision, I shared a live demo of the webapp hosted on my server. Frantically, I also iterated the releases from v1.0.0 to v1.0.1 and v1.0.2 in rapid succession, fixing basic bugs to make sure the demo would actually work for the unexpected spike of users.
Of course, in the grand scheme of software, my little ebook editor isn’t exactly changing the world. But for me, seeing it live, even for a handful of curious users, was thrilling. It’s a reminder that excitement isn’t about scale, it’s about stepping into new territory, making something tangible, and sharing it, however modestly.
Late that night, I realized I had no way to track traffic on the subdomain hosting the demo (I normally use GoatCounter on my main site). As a quick fix, I set up Caddy to log visits for the first few days, before routing them to a standard logging path. And boy, was I glad I did.
Quick stats: 22 unique countries visited the demo in the first five days. Many users made multiple requests, showing they were actively testing the editor’s features.
Most importantly, this sudden exposure revealed real errors I would never have uncovered on my own. Logs showed HTTP 413 (Payload Too Large), HTTP 502 (Bad Gateway), and HTTP 500 (Internal Server Error). These were the issues I needed to tackle, but the biggest lesson was yet to come.
The most interesting was the “Payload Too Large” error. Demo testers were uploading ebook files far larger than any I had tried. Debugging revealed that Fastify, my server framework, limited file upload sizes by default. This was a critical oversight, one I wouldn’t have caught without real users pushing the limits. Luckily, the fix was simple, and v1.0.3 rolled out within the same day.
The second takeaway was performance: handling books over 30 MB was slow. While it worked, it highlighted the need for a loading indicator. That feature has since been added to the roadmap for a future release.
The live demo can (temporarily) be found at Demo – EPUB Bookprep.
The demo is intended for light, manual testing. Files are processed in memory and not stored, and uptime is not guaranteed. For regular use, self-hosting via Docker is recommended.
If you want to host it yourself, the source code and Docker image are available at my GitHub repository.
Comments