First-ever unforgettable hackathon

Sanghyeon Han — Sat, 31 Oct 2026 23:17:20 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

My teammate Bibash Chaudhary and I built MathWise in 24 hours at HackGB 2026. You write your own Precalc, Calc I or Calc II solution by hand with a stylus, one step per line, and MathWise finds the first line that went wrong. Then it gives you only as much help as you asked for.

Why we built it

We're both in Calc II, and like a lot of students we check homework by pasting it into a chatbot. That works until it doesn't. When we gave Gemini my handwritten solution to

\int sin^{3} x d x

it got the final answer right, but it blamed a line that was actually correct. My real mistake was somewhere else. If I had trusted it, I would have "fixed" the part that was fine.

The other problem is that a chatbot just hands you the full solution. At midnight before a quiz I don't want the answer. I want to know where I went wrong, and sometimes only whether I went wrong.

What it does

Write on a ruled canvas in the browser. Pen and mouse draw; touch is ignored, so you can rest your palm on the screen like on paper. Bibash built this part, and it works on both Android and iOS with no native app.
Pick a help level before you check (the five levels are in the table below).
Press Check. Gemini reads each line exactly as written and then finds the first wrong line. Lines that follow correctly from an earlier mistake aren't flagged, like "error carried forward" credit on an exam.
SymPy checks the final answer with math, not AI. If your antiderivative is wrong, it differentiates it and shows you an x where it doesn't match the integrand.
Stuck? Take a hint. Each hint steps down one level (Check → Nudge → Pinpoint → Walkthrough). Hints make no new AI call: the server keeps the one analysis it already has, and plain code decides which fields each level may show. If you're still stuck at Walkthrough, you can reveal a full worked solution after a confirmation.
Every mistake links to the matching section of a free OpenStax textbook.

The five help levels:

Level	Name	What you get
1	Walkthrough	Which line is wrong, why, and how to fix it
2	Pinpoint	Which line is wrong and why; you fix it
3	Nudge	One guiding question, no verdict
4	Check	Only correct or incorrect
5	Exam	Nothing until you submit; then a full review, and the problem locks

I did the backend: the help levels, the Gemini prompts and calls, the SymPy checker and the Modal deployment. Bibash did the whole frontend: the canvas with palm rejection, the tools, the help-level dial, History and themes.

What I learned

Mocked tests aren't enough with an AI API. We ended with 106 backend tests, all with Gemini mocked, and the very first real call failed with a bug none of them could see (more on that below).
Reading handwriting and judging math are two different problems. Splitting them into two calls made each one easier to test and to fix.
AI is good at explaining and bad at being sure. Anything that has to be right (what a help level reveals, model fallbacks, whether the final answer is correct) ended up as ordinary code or real math, not a prompt.

Demo

Live app: https://mathwise.ink
Backup URL (if your network blocks the new domain): https://shan119660--mathwise-web.us-east.modal.run
No stylus? Add ?mock to the URL for a canned example with no AI calls.

The first check after the app has been idle takes a few extra seconds while the server starts.

Walkthrough

You pick a help level on the dial before checking. Hints step down from there.

Here's an integration by parts problem, ∫x sin x dx. Each handwritten line shows the LaTeX that Gemini read next to it, mistake included. Line 2 says v = cos x, which is wrong (the antiderivative of sin x is −cos x), and that's the line that lights up. Lines 3 and 4 follow correctly from it, so they aren't flagged.

At Walkthrough you get the why and the fix. Underneath, SymPy has checked the final answer on its own: "The derivative of your final answer is not the integrand: at x = −2.737 they differ: −1.0774 vs 1.0774." There's also a link to OpenStax Calculus Volume 2, section 3.1 Integration by Parts.

Partner Technologies

We used two MLH partner technologies: the Gemini API and a GoDaddy Registry domain. Gemini is the core of the app, so most of this section is about it.

Gemini API

We call Gemini through the google-genai Python SDK. The primary model is gemini-3.8-flash, and a normal check makes two separate calls.

Call 1: transcription, literally

The canvas crops each ruled row into its own image. The backend sends all rows in one request, each image preceded by a text label ([0], [1], ...), so the model can't lose track of which line is which.

The most important line in the transcription prompt is this one:

Transcribe EXACTLY what is written. NEVER fix mistakes.

Vision models love to "help." If a student writes v = cos x where it should be −cos x, a model that reads for meaning will quietly write the correct version, and the mistake we're supposed to find disappears before the checker ever sees it. So the prompt tells Gemini to keep every sign, constant and exponent as written, and calls out the things it tends to smooth over: minus signs, + C, what's inside an exponent (e^{x^2/2 + C} vs e^{x^2/2} + C), dx and parentheses. Each row also gets an unclear flag when the model isn't confident about a symbol, so the app can tell you instead of guessing silently.

Call 2: analysis, as structured output

The second call gets only text: the problem plus the transcribed steps, numbered. It returns structured JSON, and I let the SDK enforce the shape by passing a Pydantic model as the response_schema:

class Analysis(BaseModel):
    verdict: Literal["correct", "incorrect"]
    wrong_step: StrictInt | None
    mistake_type: MistakeType | None   # sign_error, chain_rule, ibp_setup, ...
    why: str
    fix: str | None
    hint_question: str
    # The problem and the final answer in SymPy syntax, for the math check
    cas_kind: CasKind | None = None
    cas_expr: str | None = None
    cas_lower: str | None = None
    cas_upper: str | None = None
    cas_answer: str | None = None

types.GenerateContentConfig(
    response_mime_type="application/json",
    response_schema=Analysis,
    system_instruction=SYSTEM_PROMPT,
    ...
)

Structured output is what makes the help levels possible. Gemini analyzes the solution once, the server stores the whole Analysis for up to an hour, and a plain lookup table decides which fields each level may see. Level 4 only gets verdict. Level 3 only gets hint_question. A hint just moves you one row down the table. That's why the levels are consistent and hints cost nothing: asking the model five different ways would have given five slightly different stories.

I still don't fully trust the schema, so the backend validates the response again. A wrong_step outside the submitted lines, or a transcription with the wrong number of rows or out-of-order indexes, counts as unusable and gets one retry.

A few prompt rules came from real failures:

why must never contain the fix, because Pinpoint shows why but hides fix.
The guiding question must look the same whether the solution is right or wrong. Otherwise Nudge would leak the verdict through its tone.
No line numbers in the feedback text. Gemini numbers rows from 0, the app shows them from 1, so "line 3" in the text would point at the wrong line. Now the prompt says to quote the math instead ("where you wrote sin³/3") and the app does the highlighting.
Copy the final answer into SymPy syntax exactly as written, never corrected. That's the cas_* fields. If Gemini fixed the answer while translating it, the math check would verify the wrong thing.

Bug 1: every live call failed with a 400

All my request models used ConfigDict(extra="forbid"), which is a good habit for an API. So I added it to the response models too. When you pass such a model as response_schema, the generated JSON schema includes additionalProperties: false, and Gemini's response_schema rejects it with a 400. Every single live call failed.

My tests mocked Gemini, so all of them passed. Only a real call found it. The fix was one line, plus a docstring on Analysis so nobody puts it back:

No extra="forbid" on models used as Gemini response schemas: it adds additionalProperties, which Gemini's response_schema rejects.

Bug 2: one check took over 3 minutes

During the event Gemini was busy, and we started getting 503 "high demand" and 429 rate-limit errors. Worse, one check took over 3 minutes. The app wasn't stuck: the SDK was quietly retrying up to 5 times with backoff on 503 and 429, and we couldn't see any of it.

The fix had three parts:

Turn off the SDK's retries, so a failure comes back right away:

   "http_options": types.HttpOptions(
       timeout=int(timeout_s * 1000),
       retry_options=types.HttpRetryOptions(attempts=1),
   ),

A time limit per model: 20 seconds each for reading and for checking. In normal times reading takes about 4 s and checking about 5 s, so 20 s means something is wrong.
Fall back across Gemini models instead of retrying the same overloaded one. If a model returns a 5xx, a 408 or a 429, or times out, generate() moves to the next one:

   CHECK_FALLBACKS = ["gemini-3.7-flash", "gemini-3.6-flash", "gemini-3.5-flash", "gemini-3.5-flash-lite"]
   TRANSCRIBE_FALLBACKS = ["gemini-3.5-flash-lite"]

The order matters. Flash-Lite is last for checking, because in an early test it blamed the wrong row (it missed a quotient-rule error). For transcription it read rows the same as Flash, so it's a fine fallback there. Each model also had its own free-tier quota, so trying more full Flash models first kept answers accurate when one model was rate limited.

After this, a slow check finishes in seconds instead of minutes.

Bug 3: reading six lines took 41 seconds

Transcription at the model's default thinking level took about 41 s for six rows. Reading handwriting doesn't need much reasoning, so I set the thinking level for transcription only to "low":

TRANSCRIBE_THINKING_LEVEL = os.getenv("GEMINI_TRANSCRIBE_THINKING_LEVEL", "low")

That brought it down to about 4 s, with the same output. Checking keeps the model's default thinking, because finding the wrong step is the part that actually needs it.

Not trusting the AI: SymPy

Even a strong model doesn't always find the first wrong line. Benchmarks like ProcessBench show that, and so did our own sin³x story. So Gemini's last job is translation, not judgment: it writes the problem and the final answer in SymPy syntax, and plain Python decides if the answer is right. It differentiates an antiderivative and compares it with the integrand at random points, integrates definite integrals numerically, takes two-sided limits, substitutes solutions back in (and checks none is missing), and plugs solutions into differential equations.

Because that SymPy text comes from an AI, and SymPy's parser evaluates Python, the parser only accepts a whitelist of math names and plain operators. It rejects huge constants like 9**9**9 before evaluating them, and every check stops after 12 seconds. SymPy checks the final answer only. It can't tell you which line is wrong, and a right final answer can still hide a wrong step.

The optional full worked solution is a third Gemini call, and SymPy checks its final answer too. If the check fails, we return "not available" instead of a guess.

What working with Gemini was like

Structured output was the best part. Getting typed, validated JSON straight into a Pydantic model meant the rest of the backend could be normal, testable code. The hard part was everything around reliability during a busy event: overload, rate limits, silent retries and latency. None of it shows up in mocked tests.

We also had a practical constraint. The cloud credits we were promised didn't work, so we built the whole thing on the Gemini free tier, which is part of why falling back across models mattered so much. For the final app we moved to a small paid key. Under the Gemini API terms, Google doesn't use paid-tier data to improve its products, which matters when the input is students' handwriting.

Repeat checks of the same work are cached (a SHA-256 of the problem, steps and images), so they come back instantly, give the same answer and use no quota.

GoDaddy Registry: mathwise.ink

Our domain is mathwise.ink. We picked .ink because MathWise is stylus-first: you write your work in ink. It's also short enough to say out loud at the end of a demo.

We pointed it at the app on Modal. The surprise came at the venue: the campus Wi-Fi blocked the new domain, and it still doesn't load on campus Wi-Fi to this day. It works fine everywhere else. So at the event we used the Modal URL directly and shared it with a QR code.

Other tech (not MLH partners)

Modal runs the FastAPI backend and the built React frontend as one HTTPS web app. It's pinned to one container on purpose: hints read the stored analysis from memory, and containers don't share memory. It stays up 20 minutes after the last request, then scales to zero. The Gemini key is a Modal secret.
Frontend: React, TypeScript, Vite, Tailwind CSS, KaTeX for math.
Backend: FastAPI, Pydantic, SymPy, mpmath, pytest.
AI coding assistants: we used Codex and Claude Code to help write and review code. Gemini is the only AI in the running app.

Hackathon Experience

HackGB 2026 was the first-ever HackGB, a 24-hour hackathon at UW-Green Bay. It ran from Saturday, October 17 at 12 PM to Sunday, October 18 at 12 PM, mostly in the Brown County STEM Innovation Center. It was also our first hackathon: Bibash and I were a team of two.

We split the work cleanly: Bibash on the frontend, me on the backend, with the API contract written down in a shared doc so we could build in parallel. That worked better than I expected. The stressful parts were all on the infrastructure side: free-tier quotas, Gemini overloading while lots of teams hit the same models, and a domain the campus Wi-Fi wouldn't load.

Since it was my first hackathon, I honestly didn't know what to expect. I was curious what everyone else was building, but what struck me most was how hard every team in the room was pushing toward the same goal: winning. We came to win too, so we gave it everything we had. I remember it being past 2 AM, my head foggy, looking around at other teams still coding through the night, and knowing we couldn't give up either.

The other teams were amazing. Some formed their team right there at the event and still got in sync, which impressed me a lot. I also got to swap stories with students from other schools about their college life and their past hackathons.

The mentors were just as impressive. We'd worried that our idea was too cliché, but they showed us how to make use of exactly that and where to improve it. I already knew some of the organizers, and spending a whole weekend at their event let me get to know them better. It was a place to learn a lot.

The sponsors were a highlight too. I talked with ATS, FTI, Bay Tek, MLH and others, and learned something from each of them. Meeting Bay Tek made me really happy, because I've always been into arcades. And ATS turned out to be where a friend I'd met through a completely different path works, so that unexpected connection was a nice surprise.

What I'll remember most is the building itself. The idea came from Bibash, my friend and teammate, and it could easily have stayed just another familiar idea. I turned it into a system, we each took our own part, and we kept pushing it further. That process was fun and intense, and it's the part I'll keep.

We entered the Education track and Best Beginner Hack, Best UI/UX Hack, Best Use of Gemini API, Best Use of Modal and Best Domain Name from GoDaddy Registry. Honestly, part of me still wishes we'd taken first place overall. But we won Best Education Hack, and I'm really happy about it. For a first hackathon I would have been glad to leave with just the experience, so winning a prize on top of that means a lot.

My biggest takeaway: in 24 hours, the AI part was the easy part to get working and the hard part to trust. Most of what makes MathWise useful is the plain code around the model: the level table, the fallbacks, the literal transcription, and SymPy saying "here's an x where you're wrong."

This was my first hackathon, but definitely not my last. I'm already looking forward to the next one.

Try it at mathwise.ink. Ink, because you write your work in ink.

DEV Community: Sanghyeon Han