A Seven-Day Polish Sprint for a Small Web Work
A day-by-day release plan that improves one core loop, tests real states, tightens the listing, and ships without turning a small work into a platform.
The final week is where small projects acquire large feature lists. A creator notices roughness, mistakes roughness for missing scope, and starts adding accounts, settings, and dashboards. The original loop receives less attention precisely when it needs the most.
This sprint keeps the work small. Every day has one question and one artifact. New features are allowed only when a test shows that the core interaction cannot be understood without them.
Days 1-2: freeze the promise, repair the loop
On day one, write the promise in one sentence and list every visible element that does not support it. Remove or postpone at least one. Record a complete run before editing so later polish can be compared with the starting experience.
Day two belongs to the core action. Tune controls, input constraints, waiting states, result hierarchy, or restart speed. Do not work on the landing copy while the central interaction still feels uncertain.
Days 3-4: recovery and small screens
On day three, trigger empty, invalid, long, slow, and repeated states. Preserve the visitor's work and make every recovery action specific. On day four, complete the same pass with touch and an on-screen keyboard or game controls.
These days often produce fewer screenshots than visual polish, but they are where a demo becomes dependable. Keep a short before-and-after note for each fix so regressions are easier to spot.
| Day | Question | Artifact |
|---|---|---|
| 1 | What is the one promise? | Scope note and baseline recording |
| 2 | Does the core loop feel clear? | One complete improved run |
| 3 | Can the visitor recover? | Failure-state checklist |
| 4 | Does it work with touch? | Mobile pass |
| 5 | Can the page explain itself? | Final listing copy and cover |
| 6 | Does the public build match local? | Signed-out release check |
| 7 | What do real visitors misunderstand? | Small-launch notes |
Days 5-6: edit the public evidence
Day five produces the title, description, cover, sample data, limitation note, and creator context. Every claim should point to something visible in the public work. Day six is deployment: use a fresh session, follow the exact shared URL, and test output or download outside the page.
Do not spend day six adding features because deployment revealed unused time. Keep it available for host differences, caching, environment configuration, and links that worked only on the development machine.
Day 7: launch small and listen literally
Send the work to a handful of people who were not present during the build. Ask what they thought would happen, where they hesitated, and what they believed the result meant. Do not begin by explaining the design.
End the sprint with three lists: fix now, observe, and later. The first list should be short enough to complete without reopening the scope. A launch is a measurement point, not permission for the project to expand indefinitely.