Markdown Notes Web App Scoped for Two Weeks

`scopes/markdown-notes-q3-2024.md` is drafted with placeholder bullet points for your two-week solo build of a local-first markdown note taking tool with list, edit, and save functionality, no external sharing features.

The broken line

The broken line refers to the specific gap between your existing static HTML prototype and the minimum viable version of the tool you can use for your own daily note taking. Right now, the prototype has a plain textarea that renders markdown input to a side pane on keyup, but it does not persist content between page reloads, does not support tab indentation for code blocks in the editor, and does not let you switch between multiple saved notes. This gap is the only work you address in this two-week sprint, with no scope creep beyond closing that specific set of gaps. You are not building a product for other users, only a tool that fits your personal note taking workflow, so you do not need to survey potential users or add features that do not directly solve your own pain points with the existing prototype.

What you leave alone

You leave all existing tested code in the repo untouched to avoid unnecessary bug fixes that eat into your sprint timeline. The existing markdown rendering library you pulled in last month, marked.js v9.0.0, stays as-is, no version updates, no custom plugin installations, no adjustments to its default rendering rules. The existing CSS theme with a one-click dark mode toggle, which you already tested across desktop Chrome, Firefox, and Safari, stays untouched, with only minor spacing adjustments allowed if they are strictly required to fit the new note list pane. The local storage wrapper utility you built for your last todo app project, which you imported into this repo last week, stays exactly as written, no modifications to its read, write, or delete methods. You also leave all planned cross-device sync and collaborative editing features parked for a future scope, only revisiting them if this build works reliably for your daily use for at least 30 days post-launch.

Core edit workflows

You build the following 5 core workflows for this version, no additional functionality added outside of this list:

1. Open the app to a fixed three-pane layout: left 20% width note list, center 50% width markdown editor with basic syntax highlighting for headers, bold, italic, and code blocks, right 30% width live rendered preview, all panes fixed in place with no resizing support for this build to cut down on complex CSS testing.
2. Click any note title in the left pane to load its full raw markdown content into the editor, with the rendered preview updating in real time as you type, no delay, no manual save required for preview updates.
3. Press `Cmd/Ctrl + S` at any time to write the current editor content to local storage, with a 1-second unobtrusive “Saved” toast in the top right corner of the viewport, no auto-save enabled to avoid accidental overwrites of intentional changes you may decide to roll back.
4. Click the “New Note” button at the top of the note list pane to create a blank new note, auto-populate the title as “Untitled Note [number]” based on the count of existing notes in storage, and set focus directly to the editor so you can start typing immediately without extra clicks.
5. Right click any note title in the list to open a single-option context menu to delete the note, with a confirmation prompt that requires you to type the full note title to confirm deletion before it is permanently removed from local storage, to avoid accidental deletions.

Where the file goes

This completed scope file lives in the root `scopes/` directory of your markdown notes repo, and you link it directly to the repo’s README.md so you can reference it at any point during the sprint if you question whether a task is in scope. You also export a PDF copy of the final scope to your personal project archive folder, so you can compare the final build against the original scope once the two weeks are complete to measure your estimation accuracy. You do not share this file with any collaborators, as this is a solo build with no external stakeholders, so the only person who needs access to this scope is you. This scope structure aligns with Build Next Stack guidance for small, time-boxed solo projects that solve a specific personal pain point.

Non-in scope features

You explicitly do not add any of the following features to this build, even if they seem trivial to implement, to keep the scope contained to the two-week timeline: no sharing functionality at all, no public links, no export to markdown or PDF files, no send via email or messaging, nothing that moves notes outside of your local browser storage for this build. No image embedding support, even if the markdown renderer supports it, you block all image tags in the preview pane to avoid having to handle local file uploads or external image link validation. No tag filtering, no folder organization for notes, the note list is sorted alphabetically by title only, no custom sorting options. No mobile responsive layout, this build is only for desktop browser use, you don’t test it on mobile or adjust any styles for small viewports. No password protection, no encryption for local storage, since this is for your personal use on a device only you access, you don’t need to add extra security layers for this version. Illustrative example: 12 total engineering hours are allocated to building the local save functionality, no backend integration required, so any feature that would require connecting to a hosted server is explicitly out of scope.

Next time you open this scope document

You open this file again on the final day of the two-week sprint, right before you test the final build for the first time. You go line by line through every requirement listed, checking off each feature that works as intended, and noting any gaps that you did not have time to complete. You do not add new requirements to this file when you open it next; if you want to add features like mobile support or image embedding, you create a new scope document for a follow-up sprint, rather than modifying this existing time-boxed scope. You also add a final section to the end of the file after your review, noting how many hours you actually spent on the build, any unexpected blockers you encountered, and which parts of the original scope you adjusted (if any) to fit the two-week timeline. You save that updated version to the repo and your personal archive, so you can reference it when you plan your next solo build to improve your estimation accuracy for future time-boxed projects.