Sort your launch list into blockers and comfort, then ship the blockers
Serial starter giving web novels a voice in the reader's browser
When Andrei laid out two more sprints before leaving beta, gamification, an unnamed button, tooltip polish, a permissions audit, the room applied a single filter to every item: will a new user hit this in their first ten minutes? A confusing permissions dialog fails that test, because it kills the install itself; a not-yet-gamified Discord and an imperfect tooltip do not, because nobody churns over them in week one. Everything that fails the test is a launch blocker; everything else is comfort work that can ship in the sprint after launch, informed by what real users actually stumble on. The audience's push to launch immediately was not recklessness but sequencing: a beta that runs long defers the only feedback that matters, strangers using the product without you in the room. Sort the list, ship the blockers, and let the comfort work compete for priority against real user complaints, a competition it usually loses.
Related advice
Know whether you are a starter, and stop designing companies for a finisher
Andrei's resume looks fragmented, Java to C# to Ruby on Rails, four years teaching at the Politehnica, an abandoned PhD, an outsourcing firm, a fantasy novel, until you apply his own reframe: he is a starter, energized by taking projects from zero to first results and drained by the long steady middle. Instead of fighting that, he now designs for it, picking products that can reach a self-sustaining state quickly and planning early for automation and helpers to carry the marathon stretch. The standard startup script quietly assumes a finisher, someone who wants to run the same company for fifteen years, and a starter who signs up for that script abandons it at year two and calls himself undisciplined. Temperament is an input to company design just like market size. Figure out which kind of founder you are from the evidence of your own history, then choose the product shape, exit points, and delegation plan that fit the person who will actually be running it.
Build inside the platform instead of pulling its readers away
The existing text-to-speech tools all make the same move: extract the story from the platform and play it in their own app. That works until you notice whose lunch it eats, because web novel platforms live on ads, comments, and community, and a tool that siphons readers off the page is a traffic devourer they have every incentive to fight, in court if necessary. Naramine is an extension precisely so it can stay on the page: it reads the chapter where it is published, follows the pagination, and leaves every pageview, comment, and vote where the platform can count it. That shape is what lets Andrei position it as an accessibility layer platforms could tolerate or even endorse, rather than a parasite they must kill. When your product feeds on someone else's content, the architecture is also the legal strategy: pick the shape that adds to the host's metrics instead of draining them, and you convert a future plaintiff into a future partner.
Make the first audio chunk tiny so playback starts before the file exists
A chapter of a web novel runs around ten thousand characters, and synthesizing all of it before playing would mean a long silent spinner. Naramine instead generates a very small first chunk so the play button responds within seconds, then produces progressively larger chunks until the pipeline reaches normal flow, pre-buffering ahead of the listener and preprocessing the next chapter in the background before the current one ends. Minutes of compute still happen, but they hide behind consumption time the listener was going to spend anyway. This is the streaming insight applied to generative products: what users feel is latency to first value, not total processing time, and the two can be decoupled almost completely. Whatever your product generates, slice the work so the first slice is nearly free, ship it the moment it exists, and let the rest of the job run behind the experience instead of in front of it.
Store generated content in the user's browser, not on your servers
Every minute of audio Naramine generates is cached in IndexedDB on the listener's own machine, sometimes tens or hundreds of megabytes of it, with a clear-data control and a download option for the user. Andrei's servers never store the stories or the audio derived from them, and that decision does double duty. Economically, his storage bill is zero and stays zero as usage grows, which matters enormously for a solo founder with an 80 percent margin target. Legally, it keeps him a tool rather than a distributor: a service that hosts copies of authors' copyrighted stories, or audio derived from them, has built a library it must defend, while audio generated on demand and held only on the reader's device looks like the reader's own personal-use copy. When your product transforms content you do not own, ask where the transformed bytes live, because that answer decides both your infrastructure costs and which side of a copyright argument you are standing on.
