Creative products · 2 min read
Story Platform: Bitterness of War
I built Story Platform around Bitterness of War, a novel project. The application gives readers a public chapter experience and gives me a private workspace for chapters, characters, timelines, world notes, and versions.
- My role
- Personal project and writing
- Project scope
- Reader and writer studio · private source
The main responsibilities in this workflow.
- Private writer studio
- Express API
- JSON content and versions
- Published-content projection
- Public chapter reader
The story gives the software a purpose
The draft follows Ario Amin, a traumatized delivery boy in a world dominated by Lighten Company. Its central concern is what survival demands of someone when conflict repeatedly pressures them to abandon other people.
That premise creates material beyond the chapter text: characters, events, world details, and private planning notes. The application brings those pieces into one workspace while allowing the public reader to see only material intended for publication.
Publishing is an explicit boundary
The public projection filters chapters by their published flag, sorts them into reading order, and returns chapter metadata such as word count and estimated reading time. Character, timeline, and world entries have their own public flags.
Tests check that unpublished chapters and private entries stay out of the public projection. This is an important distinction from building a frontend that merely hides draft controls: the data returned to the reader has to respect the publishing boundary.
A writing studio needs continuity
The data model includes chapters, characters, timeline entries, world notes, general notes, and versions. Statistics distinguish manuscript words from published words and count draft and published chapters separately. Markdown export provides a path out of the application.
That separation supports a useful editing workflow. A larger manuscript does not automatically mean more public content, and saving a draft does not mean publishing it. The product keeps those actions conceptually distinct.
File storage is a deliberate scope limit
The Express API persists JSON files. That makes the current personal workspace straightforward to inspect and operate, but the read-modify-write path is not a multi-writer transactional database.
If the product needed concurrent editors or stronger write coordination, that persistence boundary would need further work. The portfolio presents the current implementation as a personal reader/writer application, not as a scalable collaborative publishing service.
Project notes
Novel remains a draft project. File-based persistence is suited to the current personal scope; concurrent-edit safety is not claimed. No unpublished manuscript excerpts are reproduced here.