The product we built
Romance AI was a startup product delivered as a Flutter mobile application. It generated personalized romantic and soft-erotic stories, supported reader preferences, and stored purchased stories on the customer’s side. The backend used Google Cloud and Firestore.
Readers could calibrate the experience around several fandom-style directions and personal preferences. Story generation used schemas created through our research, user testing, and guidance from domain experts. Those schemas provided a structure for original serialized stories instead of asking a model to improvise every element from a short instruction.
This form of adaptive serialized fiction needed to preserve the state of the story between generated chapters. Serialized fiction fails quickly when a new scene ignores earlier motivations, relationships, or unresolved events.
The application also generated a small number of non-erotic images for chapters and story differentiation. Stable Diffusion produced artwork aligned with the details of a story, a sense of mystery, and the product’s visual branding.
Why prose required different prompting
General-purpose models tended to write vague, compressed prose. In our testing, they could cover in two or three paragraphs material that a professional author might develop across five to ten book pages. That behavior may be acceptable for summaries, marketing copy, or documentation, but it weakened pacing, atmosphere, characterization, and narrative continuity in fiction.
We responded with extensive narrative instructions and examples. At the time, this became one of the longest system prompts we had built. The system prompt accounted for more than 70% of the available context window. That allocation was necessary to constrain pacing, scene construction, character behavior, tone, and the relationships between story elements.
The prompt was only one layer. Structured story schemas represented characters, setting, relationship state, events, and unresolved threads. Reader preferences and chapter choices could then influence the story without treating each new chapter as an isolated generation task.
Sensitive content and model constraints
The romantic-plus direction introduced a practical model-selection problem. Most available models or providers could not reliably support the permitted soft-erotic content under their usage constraints. Models that could produce text also varied in their ability to maintain quality and follow the narrative structure over time.
We evaluated available models against the product’s writing requirements rather than selecting one from a generic benchmark. The relevant questions were whether a model could follow the schema, preserve tone, avoid vague compression, and produce the intended category of content consistently.
The application supported several preference directions, but this case study does not claim rights to named third-party fictional properties. The delivered story schemas were used to construct original stories with domain-expert input and user-test feedback.
Privacy, access, and payments
Stories and related data were end-to-end encrypted. Access to the application was protected so another person with physical access to the phone could not easily open the private library. This mattered because the content and preferences could be sensitive even when they did not contain conventional identity data.
The commercial model used one-time payments for stories. Purchased stories were then stored on the customer’s side. The case study does not claim a particular encryption certification, payment volume, or regulatory status because those details were not supplied.
The mobile product combined Flutter with Google Cloud and Firestore. Stable Diffusion handled dynamic non-erotic artwork. This stack is relevant because the delivery covered the mobile experience, data storage, private access, generative text workflows, and story-specific media.
Why development stopped
We stopped the product as newer model generations became harder to use for this category with predictable quality. At the same time, general tools such as ChatGPT and Claude made it easier for people to create stories themselves, changing the value of a separate application. The combination increased maintenance effort and weakened the product’s differentiation.
With current technology, we would consider rebuilding the capability as a skill, plugin, or MCP server that people could use inside an existing assistant. That is a retrospective product direction, not a feature of the delivered mobile application. It would also need careful onboarding because the original audience was not highly technical.
Supported outcome and limits
The supported outcome is a delivered Flutter application with encrypted access, one-time story purchases, customer-held storage, narrative schemas, personalization, user testing, and dynamically generated chapter artwork. The project also produced practical knowledge about long-context narrative prompting and the limits imposed by model policies and changing model behavior.
This case study does not claim current availability, active users, revenue, quantified reader engagement, guaranteed narrative quality, or rights to third-party fandoms. The application was stopped for the maintenance and market reasons described above.
For a related adaptive-content product, the starting point is the content policy, narrative schema, privacy model, and evaluation method. The related agentic-systems overview explains how structured state can support multi-step generation.