Why I built it
We interviewed ten instructors who teach intro university STEM, and they all described grading the same way. The judgement takes seconds. The rest is mechanical: open the submission, find which page they answered question three on, walk down the rubric, then type the same comment about the same sign error for the twentieth time that evening.
There were three of us. I was the only backend and infrastructure engineer, and a co-founder on the front end. We went through Create-X, Georgia Tech's startup accelerator, in the Summer 2026 batch.
What it does
You point it at a batch of handwritten or typed PDF submissions and it hands them back graded against your rubric, with the annotations placed and the rubric items ticked on Gradescope, where instructors already grade. On average it grades with 95% accuracy.
How it works
How a batch of exams gets graded
- 1
The Chrome extension pulls the submissions off Gradescope.
The platform has no API, so the extension finds the controls in the DOM and clicks through its pages.
Chrome extensionJavaScript
- 2
OCR reads every page.
Handwritten and typed work both come back as text.
Document AI
- 3
Each answer is matched to its question.
Students answer out of order, so the matching cannot assume page order.
Python
- 4
The backend grades each answer against the rubric.
Questions are packed into batches and spread across 15 parallel workers.
FastAPIGemini
- 5
Grades are saved and written back onto the platform.
The extension places annotations and clicks the rubric items.
SupabaseChrome extension
Grading. The backend scores each rubric and answer pair using semantic similarity from a language model. A grader will not wait ten minutes for a batch, so a batching engine packs questions up to a token budget and uses connected components to put every part of a multi-part question in one call. The batches fan out to 15 parallel workers.
Where it runs. Docker containers, first on Azure OCR and Azure Container Apps, later moved over to Google Document AI and Gemini on AWS ECS.
The hard parts
One disputed question, and we reprocessed the whole exam
A student says question three was marked wrong. The first version ran the entire submission through the model again: every page, every question, to answer one complaint.
The regrade path now hands a worker one page and the rubric context for one question. Inference on a regrade fell about 80%.
All fifteen workers retried at once
Fifteen parallel workers hit the rate limit at the same time, back off by the same amount, and retry at the same time. A forty-second batch took five minutes.
Jittered backoff scatters the retries across a window so they stop landing on top of each other. Packing questions to a token budget before dispatch helps from the other side, since each worker carries a full load and there are fewer calls to collide in the first place.
Demoing without real student work
Real student submissions carry names and student IDs, and FERPA governs what you are allowed to do with them. So we could not demo on real coursework, which is exactly what an instructor wants to see before trusting it with a class.
I built a redaction step that blacked out identifying information before anything left for the API. It caught names in the top corner of the page. It missed a student who had written theirs halfway down a page, so we kept real submissions out of every demo.
So we demoed on Gradescope's dummy exams and on exams we wrote ourselves. On those it applied detailed rubrics more accurately than manual grading did.