-
-
Every book is complete before it publishes. Heat level and chapter count up front, and nothing ever ends in a coin prompt.
-
One membership unlocks the whole library. No coins, no credits, no cliffhanger paywalls.
-
19 original novels at launch across 12 pen names, most in three heat levels: Sweet, Warm, and Steamy.
-
App logo
Inspiration
We kept noticing the same thing about romance readers: they are the most voracious audience in publishing and nobody can feed them fast enough.
A committed romance reader finishes a novel in two or three days. They do not want one book. They want the next one, in the exact trope they are in the mood for, at the exact heat level they like, right now. Traditional publishing answers that on an eighteen month cycle. By the time a trend reaches a shelf, the readers who started it have moved on twice.
The apps that own this space noticed the same gap and solved it with economics instead of supply. They meter. You buy a stack of coins, you burn it on a few chapters, you hit a wall in the middle of a scene, and you buy more. Read the reviews on any of them and the same sentence comes up over and over: I love the story, I hate being nickel and dimed inside it.
We wanted to attack the supply side instead. A catalog deep enough that a reader never runs out, responsive enough to chase a trend in weeks rather than years, and sold honestly: complete books, one membership, no coins.
That is an easy sentence to write and a very hard thing to build, because it all rests on one thing. You have to be able to produce a novel that a real reader will actually finish. Not a chapter. A novel. Forty odd thousand words across twenty to thirty chapters, which is far past the point where you can hand a model a premise and get back something anyone will stay with.
Blush Books is a reading app sitting on top of a writing system, and the writing system is where almost all of the work went.
What it does
At launch the library holds 19 complete novels under 12 pen names, 1,342 chapters in total. Every book is finished before it is published. Nothing ends in a coin prompt.
Most of them exist at three heat levels of the same story, Sweet, Warm and Steamy, 49 published variants in all. Same characters, same plot, same ending. Only the intimacy changes. A reader can switch heat level on a book they are already reading, and their place and bookmarks follow them across the switch. Highlights stay anchored to the exact text of the edition they were made in, on purpose: silently re-anchoring a highlight into different prose would pin it to words the reader never marked.
That last part is the feature we are most attached to, because it fixes something the genre has always handled badly. Romance readers disagree sharply about heat, and every other app makes you pick a lane and hope the book matches you. Here the reader draws their own line, per book, and can move it.
Underneath it is a real reading app: a paginated or scrolling reader with adjustable type, spacing, margins and themes, highlighting with notes, bookmarks, offline downloads, reading streaks, and cross device sync.
One membership, weekly or annual, unlocks the entire library. It is a hard paywall and we are not shy about it: no coins, no credits, no metering, no bait chapters engineered to stop mid scene. You subscribe, you read everything.
How we built it
React Native and Expo on the front end. The reader itself renders inside a WebView, because pagination, text selection geometry, and highlight anchoring behave the way a book should there and fight you inside a scroll view. Supabase is the backend: Postgres, Row Level Security, storage, and edge functions.
RevenueCat runs monetization. Its SDK ties each customer to our backend identity, entitlements are verified server side, and access to paid content is enforced at the data layer rather than left to the app. Paywalls are RevenueCat's dashboard paywalls, so we can change pricing, copy and presentation without shipping an App Store release, which matters enormously for a small team that cannot afford a review cycle every time we want to test a price.
The catalog comes from a separate publishing system. Producing a book there is a pipeline, not a prompt: planning, drafting, memory extraction, a deterministic audit, a panel of specialist critics, targeted repair passes, and a final gate. Every stage can be re-run, and nothing is trusted until the last scan agrees with the text actually on disk. A book reaches the store only when it clears that gate, and the gate has no override.
Challenges we ran into
Holding a whole novel in one piece. This was problem number one and it took the longest. Our first instinct was to solve it with a bigger context window. That does not work. A model handed everything written so far will still lose a promise made in chapter four, quietly rename a minor character, or resolve a thread it already resolved two chapters ago. Readers catch every one of those, and one of them is enough to break the spell.
What worked was giving up on asking any single call to remember a book. Instead the system maintains structured state about the story outside the model: what is still open, what has already been paid off, what is settled fact, where the relationship actually stands. Each chapter is written against a scoped view of that state rather than against the whole manuscript. Getting the scoping right took several painful iterations, including one memorable bug where knowledge from the end of the book leaked backwards into an early chapter and the foreshadowing went from clever to nonsensical.
Crutch words are what make a book feel machine written. Not plot holes. Not grammar. Repetition.
And the repetitions that matter are not the ones you would think to search for. They are loops: the same handful of physical gestures carrying every moment of attraction, the same abstract idea recycled as the book's only theme, the same sentence shape opening chapter after chapter, one character's verbal tic slowly becoming every character's voice. Every one of those can look completely fine chapter by chapter and be unreadable across a whole book. You only see it if you measure the manuscript as a whole, which is exactly what a model reviewing one chapter at a time will never do for you.
So the system measures the finished book, not the pieces, and it does it with counted budgets rather than opinions. Getting those budgets right, and honest, was most of the fight.
Every repair pass breaks something else. This one reshaped the whole pipeline. An AI line edit that fixes repetition will happily flatten a love scene, swap one banned phrase for another, or spoil a reveal by using a word the reader is not supposed to have yet. So repairs are not trusted on their own. Fixes are proposed narrowly and are thrown out automatically unless they survive mechanical checks against the rest of the book. Plenty of proposed edits get discarded. That is the point.
Graders inflate. A model asked to score prose gives it a four or a five almost every time, which makes it worthless as a gate. Fixing that meant anchoring the scale to published work rather than to other AI drafts, rotating reviewers across different model providers so nothing grades its own output, and then running the identical panel blind over novels that readers had already validated with their wallets. Those came back around three out of five. That is the bar, and it is a lot lower than our egos wanted it to be.
Accomplishments that we're proud of
Shipping a finished product instead of a demo. 19 complete novels, a real reader, subscriptions enforced by the database, and App Store approval, with every line of the engineering carried by one of us alongside a full time job.
Building a supply engine rather than a book. The first novel took months, and almost none of that time went into the novel. It went into the system. That system is the actual asset, and it is why the catalog can now grow on a schedule instead of on inspiration.
And the gate holding. A book ships only if the deterministic audit comes back clean, the reader naturalness checks pass, and the review panel clears the bar, with all three results stamped against the current version of the text so a stale green from before the last edit cannot sneak anything through.
What we learned
Context is a data structure problem, not a context window problem. Every time we tried to solve continuity by giving a model more text, it got more expensive and no more reliable. Keeping the state outside the model was slower to build and is the only thing that worked.
Measure the failure or you will not fix it. "This feels AI written" is not actionable. A count against a budget is. Almost every quality jump in this project came from turning a vague complaint into a number, and the numbers only mean anything because they were calibrated against books that people actually bought and finished.
What's next for Blush Books
More books through the same gate, faster, which is the whole thesis. The catalog is the product.
Narrated audiobooks with read along text that highlights as it plays. The pipeline is built, and the feature ships gated behind a coming soon state until every chapter of a book is recorded, because a half narrated audiobook is worse than none.
Beyond that: a web reader, per author narration voices, and closing the loop between what readers actually say about a finished book and the standards the next one has to clear.
Built With
- expo.io
- ios
- node.js
- postgresql
- posthog
- react-native
- revenuecat
- sentry
- supabase
- typescript
- webview
Log in or sign up for Devpost to join the conversation.