Novelist

Inspiration / The Problem

While writing a novel, an author needs to manage a huge amount of complexity when crafting a story. He needs to reconsider each passage of his work without losing sight of the big picture and how it fits in with the characters, plot, world, story threads, and each nuanced detail surrounding them. An author will often face this common frustration as his notes pile up, making it more and more difficult for him to find and index them. Trying to find the correct note for a specific story thread can easily pull him out of his workflow, slow him down, and cause him to forget important ideas that were top of mind only a moment ago. Novelist was designed to solve this problem.

What I built

When the user signs in, he's presented with a clean manuscript workspace that expands in functionality with his tastes and needs. This keeps the whole manuscript in view, no matter how complex the project becomes. The writer can then draft within a rich text editor while using an auto-generated outline, custom timelines, anchor points, draft backups, a minimap scroller, and real-time cloud sync with WebSockets. Together, these tools allow the app to help the writer keep the whole scope of his story visually in context, paragraph-by-paragraph, without opening and closing multiple notes and multiple files per scene and chapter.

Challenges I faced and what I learned

Novelist was specifically designed to preserve responsiveness across manuscripts hundreds of thousands of words long, even as the project grows in size. It uses extensive caching and a custom document editor built with the HTML Canvas API and a virtualized scroll frame. JavaScript multithreading with Web Workers moves whole-document formatting off the main thread so that it doesn't interrupt the writer's workflow. The editor also responds to live input along performance-sensitive "hot paths" without blocking the main thread.

Getting Codex to preserve these requirements took a bit of effort. It required codifying strict rules in ESLint, Stylelint, Husky pre-commit hooks, pre-deployment checks, AGENTS.md, ADRs, PRDs, and other durable documentation. I also relied heavily on the Chrome DevTools Performance panel, Playwright, the Chrome MCP server, and Codex’s Chrome-control plugin. If I was not careful, Codex could forget important facts about the codebase and reintroduce familiar bugs while trying to improve the architecture. Over time, I learned how to steer it more effectively. When the architectural requirements were explicit and Codex was required to inspect the real interface before delivering its work, it often led me toward stronger design decisions.

How I built it

For Build Week, I replaced a separate review session workflow that Novelist had in an earlier phase of development, with a paragraph-scoped review feature. The overall problem I had with the earlier design was handling merge conflicts between draft revisions. I wanted to avoid forcing writers to wrangle merge conflicts like a developer has to with Git. The solution I came up with was to make revisions granular on a paragraph-by-paragraph level.

That way, the writer can initiate a focused review by paragraph, scene, or chapter instead of reviewing the entire manuscript at once. When the writer is ready, he can accept or reject one small change set without interrupting the surrounding work. This preserves the context of the current revision while reducing merge-conflict management, busywork, and constant context switching.

Built With

• astro
• canvas
• cloudflare
• codex
• css3
• drizzle
• fastcheck
• github
• gpt-5.6
• html5
• indexeddb
• playwright
• pwa
• typescript
• vitest
• workbox
• workers