Inspiration
Stopping work is easy. Returning often starts with rebuilding a mental picture from notes, open tabs and half-finished drafts. Afterword explores a smaller question: what if you could leave yourself the exact context needed to begin again?
What it does
Afterword is a browser-local notebook for students, writers and makers working on several unfinished projects. Before an interruption, you leave a checkpoint: where you stopped, one concrete next action, and something to watch for. When you return, a three-step sequence brings those notes back in order. Completing the sequence moves the thread into a return archive, where it can be paused again with fresh notes.
The prototype includes editing, search, an optional reference link, and versioned JSON backups. No account or runtime AI service is needed. The notebook stays in your browser unless you export it.
How it was built
Created from a fresh directory during the challenge with Codex, using the Devpost Learn Skill Pack as a guide for scope, product requirements, technical specification, verification and shipping preparation. Idea selection and implementation were delegated to Codex. The repository documents the planning and build process.
The app uses HTML, CSS and JavaScript modules, browser localStorage, and native dialogs. Node's built-in test runner checks the data model, import validation, merging and unsafe URL handling. There are no third-party runtime packages or API credentials.
Challenges encountered
The app needed to preserve a useful stopping point without becoming another task manager. The prototype stays centered on three pieces of context and a deliberate return action. Browser-local data also needs an exit route, so the build includes validated backups, duplicate merging and visible storage errors. Browser testing caught a CSS interaction that could expose hidden optional elements; the hidden-state rule was corrected.
Accomplishments
The implemented proof of concept supports the full loop: create a checkpoint, reload the page, return through context and next action, archive the thread, and pause it again. Its visual direction follows a field notebook: olive cover, warm paper, serif typography, quiet annotations and ruled structure. Seven model tests pass, and desktop and phone layouts were checked in Chrome.
What the build showed
A checkpoint is only reliable if saving succeeds before the interface reports success. Testing also caught a CSS interaction where component display rules exposed hidden optional elements. The resulting changes made persistence errors explicit and hidden states consistent.
What's next
First, use the prototype during real interruptions and assess whether the saved next action is useful on return. Later possibilities include optional browser-extension capture and cross-device synchronization. These are future ideas, not implemented features.
Log in or sign up for Devpost to join the conversation.