Case 02
Everything was in a different file
Curriculum plans in one folder, lesson plans in another, schemes of work in a third, student trackers in a spreadsheet somebody owned personally. Teachers were opening a dozen documents across scattered Drive locations and three different pieces of software to answer one question about their own course.
The problem
Nothing was broken, exactly. Every individual document worked. The cost was in the gaps between them — the same information retyped into four places, no way to see whether a plan and its scheme of work still agreed with each other, and no shared view for anyone trying to collaborate.
Planning time is the scarcest thing a teaching team has. Every decision on this project was measured against one question: does this give someone an hour back, or does it cost them one?
Key decisions
Follow the workflow instead of specifying it
Every part of the process I fixed revealed the next one that needed fixing. Solving curriculum planning surfaced the lesson planning problem; solving that surfaced the scheme of work; that led to student trackers, and then to tracking student work itself. I built each piece only once the previous one was in real use and the next gap was obvious.
A single up-front specification would have been faster to write and would have described a workflow nobody actually has. Building along the chain meant every feature was answering a problem someone had that week.
Match the existing paperwork exactly, rather than improve it
The learning plan export produces a document identical to the template the college already requires — same layout, same column widths, same logo, correct academic calendar with holidays skipped. It would have been easier to export something cleaner of my own design.
But a better document that still needs reformatting before submission saves nobody anything. Matching the existing template exactly is what turned an afternoon of formatting into one click.
No framework, no build step
Vanilla JavaScript on Cloudflare Pages with Supabase behind it. No build pipeline, no dependency tree to keep patched, nothing that stops working in eighteen months because a package moved on.
For a tool that has to keep running inside a department without a development team, boring and durable beats modern and brittle.
How it grew
Curriculum planning
The starting point — mapping a course across the academic year.
Lesson planning
Plans attached to the weeks they belong to, not a separate document.
Schemes of work
Generated from the plans already written, rather than retyped.
Student trackers
Progress against criteria, visible to the team rather than owned by one person.
Tracking student work
Marking and grade records exported in the format the college requires.
Outcome
A whole department now plans in one place, with other departments in line to adopt it. The documents the college requires come out of the tool already in the right format.
This project handles student data, so screenshots and detail are limited by data protection requirements. Happy to talk through the architecture and the decisions behind it directly.
What I'd do differently
I'd have modelled the data properly before building the lesson planning screens. An early version was missing a field that seemed unnecessary at the time, and the result was lesson content quietly duplicating itself across weeks — plausible-looking output that was wrong. It took longer to notice than a crash would have, and longer to unpick.
Now I sketch the data model against the real workflow before writing any interface, specifically looking for the case where two things that look identical need to stay separate.
Next case