Scenes and Chapters

Building a collaborative content editor for fiction writers forced me to confront a problem I hadn't thought much about: how do you model creative structure in a database without the model becoming a cage? Fiction has chapters and scenes, but writers don't think in database rows. They think in narrative arcs, character threads, thematic beats. The data model needs to support the technical reality (ordered content blocks with metadata) while staying invisible enough that a writer never feels like they're filling out a form.

The scene/chapter architecture ended up as a tree: a project contains chapters, chapters contain scenes, scenes contain content blocks. Each level carries its own metadata -- chapter summaries, scene-level notes, character tags, status flags. The ordering is explicit rather than implicit, using fractional indexing so reordering scenes never requires updating every sibling's position. Writers rearrange constantly -- moving a scene from chapter 3 to chapter 7 should be a single operation, not a cascade of position updates across dozens of rows.

CRDTs handle the real-time collaboration. Two writers editing different scenes in the same chapter see each other's changes without conflicts. The hard case is concurrent edits to the same scene, where CRDT merge semantics can produce technically correct but narratively nonsensical results. A sentence inserted by one writer and a deletion by another might merge into something neither intended. The solution was granular conflict detection at the paragraph level with manual resolution for true conflicts, rather than silent auto-merging that corrupts the text. Writers would rather see "Alice and Bob both edited this paragraph" than discover their prose was silently mangled.

The deeper insight is that creative tools need structured flexibility -- enough structure to enable features like reordering, filtering, and status tracking, but enough flexibility that the structure doesn't prescribe a workflow. Some writers outline every scene before writing. Others discover the structure as they draft. The data model supports both: you can create empty scene placeholders and fill them in, or you can write continuous prose and split it into scenes later. The technical challenge is making both workflows feel equally natural, which mostly means keeping the UI focused on the content and hiding the data model entirely.