Backplan

For students with more deadlines than days: paste your list, see what to start today, what won't fit, and the smallest change that saves your week. No account, no AI at runtime.

Comment

Try it in 30 seconds: open backplan.sites.tab.bot. There's no sign-up. A sample week is already planned: a made-up student with five deadlines, and 2 of them won't fit. Under "Ask for 2 more days", tap Plan as if granted and the whole week fits. Then tap ✓ Did it on today's block, and hit Clear it and paste yours to try your own list.

Inspiration

Most students keep deadlines in a notes app: "essay oct 20", "lab 10/14", "ch 6-8 reading". The list stores the dates, but it never adds up the hours. So the moment you find out the week doesn't fit is usually the night before something is due, when it's too late to fix.

Planners can show you that you're behind. I wanted one that answers the next question too: what is the smallest thing I can change so I'm not?

What it does

Backplan is one page. You paste your deadlines the way you'd write them, one per line (Essay — Oct 20 — 6h, 10/14 lab report 4 hours, read ch 6-8, 90m, friday), say how many hours a day you have, and it plans backwards from every due date.

  • Today, first. The top of the plan is the answer to "what do I do now?": today's blocks, with hours.
  • The truth, early. Each deadline is on track, tight or won't fit (short by N hours), and the verdict says it in one line: "2 of 5 won't fit. Short 2.5 hours in all. First miss: lab report, due Oct 14 (2h short)."
  • Rescue: the smallest change that saves the week. When the week doesn't fit, Backplan shows up to four fixes, each a single change:
    • Ask for time: the smallest extension on one deadline ("Ask for 2 more days on lab report"), with a short, polite request you can copy and edit, and "Plan as if granted";
    • Do less: the smallest half-hour cut to one task ("Cut lab report from 8h to 6h");
    • Work weekends, if they're off and that's enough;
    • Work longer: the smallest step up in hours a day ("4 h a day instead of 3").

Every option is found by re-running the planner, so every fix shown is a fix that works. One tap applies it to your list.

  • It keeps up with your week (new in Round 3). A deadline week is lived day by day, so the plan is too:
    • ✓ Did it. Each of today's blocks has a button. One tap writes the hours onto that task's own line (lab report 8h, 3h done), takes them off today's time, and re-plans only what's left. Undo is one tap. Typing 3h done, done: 1.5h or a ✓ works too. When today's work is all ticked: "Done for today."
    • Night off? Answered by re-planning without today: "Yes. Everything still fits; you'd finish Oct 23 instead of Oct 22" (one tap takes the day off), or "Not for free: lab report would end up 3h short."
    • Slack. When everything fits, the verdict says how many days you could take off and still make every deadline: "Slack: 4 spare days."
  • The backwards ribbon. Each deadline is a flag; its work bar grows backwards from the flag to the day you start. Work that lands past the flag is drawn in red.
  • Reads messy lists. Dates like Oct 20, 10/20, tomorrow, friday; hours like 6h, 90m, 2h30m. No hours? It assumes 2h and says so. A line it can't read is listed, never silently dropped.
  • Exports a .ics for any calendar app, the plan as text, or a share link.
  • Private by design. No account, no server, no AI at runtime. Nothing leaves your browser, it's instant, and every number can be explained.

Who it's for

Students, and anyone juggling a handful of dated deliverables who finds out they're behind too late. It turns a pasted list into a plan, and a "won't fit" into a decision, in about ten seconds.

How I built it

With the Devpost Learn skill pack and a coding agent, following the pack's steps in order. The documents are in the repo under devpost/:

  1. scope.md: the kernel (honest back-planning from a pasted list), who it's for, and what's cut (no accounts, no AI parsing, no notifications).
  2. prd.md: every behaviour: the date and hour forms the parser reads, the scheduler rules (due = end of the due day; work that won't fit is still placed, never hidden), statuses, the verdict sentence, actions and states.
  3. spec.md: plain-language architecture, stack (plain HTML/CSS/JS modules; Node only for tests and a tiny static server), data model, failure modes.
  4. checklist.md: seven small slices, each built, tested and committed on its own. The git history is the checklist.

Round 2 added the rescue. It got its own section in the PRD and the spec, a new module (src/rescue.js) and 9 new tests, including one that applies every option the panel offers and checks that the plan really fits. It also brought a visual identity of its own: paper and ink, a serif face (Fraunces, self-hosted), one tomato-red accent used only for deadlines and the smallest fix, and a mark that is a flag with a backwards arrow.

Round 3 (Oct 19) made the plan a living one: progress on the line, "Did it", "Night off?" and slack. Same process: PRD and spec sections first, then slices, a new module (src/progress.js) and 13 new tests. Progress is plain text on the student's own line, not hidden state, so it stays visible, editable and shareable.

Round 4 (Oct 25) came from Devpost's "Will It Ship?" live review checklist. Judges should get in without an account, which Backplan never needed. And the first screen should say what the app does and who it's for. Ours showed a tagline and an empty box. Now the header says who it's for, and a first visit opens on a labelled sample week that's already planned, so the product is working before you type anything. Same process again: PRD and spec sections first, then the code, then 11 new browser checks.

Quality: 36 unit tests; 43 end-to-end checks in a real browser (11 of them new for Round 4), run against both the local build and the live site; axe-core accessibility checks with 0 violations. No dependencies, no build step, MIT licence.

Challenges I ran into

  • Making "rescue" trustworthy. An estimated fix ("you need about 2 more hours") can be wrong in subtle ways. Brute force solved it: try each single change in small steps and keep the smallest one the planner accepts. A student list is 3–15 lines, so that's a few thousand planner runs of microseconds each.
  • Editing the user's own words. "Apply" rewrites the date or hours inside the line the student typed and leaves the rest alone, so the list stays the one source of truth.
  • Lenient parsing without a model: find and remove the date and the hours first, then treat what's left as the name, and make sure "ch 6-8" isn't read as 6 hours.
  • A bug the new tests caught. The "N h/day would fit everything" line searched by re-planning, and every re-plan that was still late started the same search again. On a list no number of hours can save (a 30-hour task due today), that was exponential and froze the page. Inner re-plans now never search, and when nothing fits the sentence is simply left out instead of claiming "24 h/day". There's a regression test for it.
  • .ics details: all-day events end on the next day, lines are CRLF and folded at 75 bytes, and stable UIDs make re-imports update instead of duplicate.

Accomplishments that I'm proud of

The moment in the demo when "2 of 5 won't fit" becomes "Ask for 2 more days on the lab report", with the request already written, and one tap later "Everything fits." That's the whole product in one line, and it works on every list, not just the demo.

What I learned

The best features came from asking what a person does one second after reading the plan: after "won't fit", it's "what's the smallest fix?"; on Wednesday night, it's "I did three hours, can I stop?". "Won't fit" is honest; "here's the smallest change that fixes it" is useful. And writing the rules down first (scope, PRD, spec) kept every part of the code explainable, which is the skill pack's answer to "cognitive debt".

What's next for Backplan

Fixed commitments per day (class times, shifts) instead of one hours-per-day number; picking specific busy days ahead of time (Round 3 can already take today off); a minimum block size so an essay isn't split into crumbs; reading a syllabus from a photo.

Built with the Devpost Learn skill pack and a coding agent (AI-assisted planning and code, reviewed and tested). The demo video's narration is AI text-to-speech. No AI runs inside the app.

Built With

Share this project:

Updates

Submission history