Early 2026
Where it started
I started teaching Computer Science ATAR this year and could see the mountains ahead. One of the first things I had to mark was a Year 10 SQL test. Sitting there working through the same questions for every student, I thought: there must be a faster way to do this.
So I built one. A static HTML marking interface, hardwired specifically for that one test. It had per-criterion scoring, strength and weakness bubbles, AI-generated comments in three tones, PDF export. It worked. I actually enjoyed building it.
Then I dreaded the thought of rebuilding something like it for every assessment, every term, for the rest of my career.
That's when the real question hit me: what if I built something that built it for me every time?
Early 2026
The problem I was actually trying to solve
I'd heard colleagues complain about marking for years. It's the part of teaching most people dread. I understood why — not because the judgment is hard, but because so much of it is repetitive. The same questions. The same answers. The same feedback written twenty times over.
What bothered me more was the feedback side. I genuinely care about giving students useful, specific comments. But doing that well for a whole class, multiple times a term, isn't sustainable. You end up choosing between speed and quality, and students lose either way.
I'd used AI to help with marking before. It was promising but clunky — it lost context, didn't handle big classes well, and turned into a lot of back and forth. And I could never bring myself to just let the AI mark and leave it at that. It didn't feel like it showed my students I'd actually looked at their work.
I also spent years helping staff navigate software designed by developers who'd never taught. Tools that required training to use. Workflows that fought against the way teachers actually think. I wanted to build something different — something a teacher would intuitively know how to use, because it was built by someone who feels the same pain.
The idea I kept coming back to: AI does the heavy lifting, but every mark still passes through the teacher. Not bulk approval. Not "accept all." Every single one. The teacher stays in the loop, the feedback is real, and the overhead drops dramatically.
I called it Markflow and started building it. I built it with help from AI tools — Claude for architecture and design decisions, GitHub Copilot for code. I'm a teacher, not a developer.
15 March 2026
First commit
Login page. Global styles. A layout. Nothing works yet. But it exists.
March – April 2026
The design comes first
Before wiring anything to a real database, I built the entire product as mockups. Home page, dashboard, the exam setup flow, the marking interface, the project marking interface, the report screens. Every screen, designed deliberately before a line of real code was written.
The design language I landed on: dark, minimal, fast. No clutter. The marking interface in particular had to feel like a focused instrument, not a form. A teacher using this for an hour straight marking 19 students across 20 questions needed it to feel good, not draining.
26 April 2026
A real backend
Supabase wired in. Google SSO. A real schema. Auth middleware. The product stopped being mockups and became something you could actually log into.
Late May – Early June 2026
The pipeline comes alive
The rubric interpretation pipeline shipped first — upload a marking key PDF, and Claude reads it and builds a structured rubric line by line, live on screen. Watching a real marking key being pulled from a PDF and generating on the UI in real time was genuinely one of the best moments of the whole build. Something that had been static wiring was suddenly alive.
The exam marking pipeline followed shortly after. Upload student submissions, hit mark, and watch AI-suggested marks and reasoning appear for each student, each question. Confidence scores. Criteria ticking. The core loop of Markflow working for the first time.
8–11 June 2026
Reports, multiple choice, the full picture
PDF report generation. Per-student feedback. Criterion breakdowns. Multiple choice support. The product started to look like something you could actually hand to a student.
Mid June 2026
The hardest stretch
OCR nearly broke everything.
For Markflow to work with real handwritten exam booklets — the kind Australian students actually sit — the product needed to read handwriting. Google Vision API for OCR, a WASM-based PDF renderer to replace ImageMagick (which doesn't run on Vercel — a painful discovery made after the fact). And then a bug: the AI was quietly outputting the human-readable question label instead of its database ID, silently breaking the link between marks and questions.
There was a period where none of it worked and I couldn't figure out why. OCR is load-bearing for the whole business model — without it, the AI costs per run make the product too expensive for teachers to use, and too expensive to justify putting out there. I'd put months of spare time into this. The thought that it might not be fixable was soul-crushing.
It did work. Eventually. But it was the closest I came to giving up.
June 2026
The first real run
Used Markflow on my own Year 9 SQL class. 19 students. 20 questions. The full pipeline — OCR, parallel marking, teacher validation, report generation. It worked.
The parallel pipeline had been a significant piece of work: instead of marking students one at a time (which took around 30 minutes for a class), everything runs simultaneously — all OCR at once, then all marking at once. The same class now marks in 3–4 minutes.
June 2026
Showing people
The first person I showed was my wife. Then my dad. Then an IT friend. The first teachers were Amy, Morgan, and Daniel. Morgan has been the most enthusiastic — he's actively using it and giving genuinely useful feedback. Watching another teacher actually use something you built alone in your spare time is a different feeling entirely.