Back to Projects

Ka-Ho-Sim | Redesigning Youth Subsidy Applications at the Source

Meichu Hackathon 2nd Place GovTech Product Strategy On-Device OCR End-to-End Service Design

I Called the Caseworker Before Writing Any Code

The brief came from the 2026 Meichu Hackathon (Maker Track): reduce the administrative load on Hsinchu City's AI Youth Digital Tool Subsidy Program. Before we started building, I called the person who actually processes these applications, because the brief only described the symptom.

What she told us was worse than the brief suggested. Three people handled the entire program, reading every application by hand. At peak, about 100 came in daily and roughly 72 of them were sent back over document problems.

The reason behind those rejections mattered more than the number. Most applicants had no idea where to find their payment record. Every bank app buries the transaction history somewhere different, so people guessed, and the screenshots they sent rarely matched what the rules required. They were not being careless. Nothing in the process had ever shown them what a valid document looked like.

"That call changed what we decided to build. Speeding up review is worth doing, but if bad documents keep arriving, all you get is faster rejections. Two things had to happen at once: applicants needed to get it right the first time, and those three people needed to read each case faster."

Fixing All Three Ends at Once

1. The applicant side: say what counts, keep the data local

  • Tell people what to submit, step by step: We rebuilt the flow so each step states which document it wants and what a valid one looks like, letting applicants check their own work before they submit.
  • Mask the card number before it ever uploads: Tesseract.js reads the document inside the browser and redacts card numbers and personal details locally, so the raw file never leaves the device. Card formats are checked with the Luhn algorithm, and the design follows PCI DSS v4.0 Requirement 3.4.1.

2. The reviewer side: help three people read faster

  • Highlight the fields that decide the case: Receipts often run several pages. The console pulls them onto one canvas and marks the fields approval actually depends on, the charge amount, the software name, the applicant, so nobody scrolls through pages hunting for them.
  • Decide a tool once, not every time: When someone applies with a tool that is not on the list, a caseworker rules on it once and the system records that decision. The next application for the same software already has an answer, and the list fills itself in over time.

3. LINE Bot: walk people to the screenshot they need

  • Guide people to their transaction record: A chat flow asks which bank they use, then walks them through that specific app, Cathay Cube, E.SUN Wallet and others, to the right screen and the right screenshot. This is the single largest cause of rejection.
  • Push the status instead of taking the call: Connected to the city's official youth account (@youthhsinchu) to send review progress automatically, and when something is missing, to say exactly what and how to fix it. Fewer people need to phone in and ask.

What I Did

  • Found the real problem by asking: Contacted the caseworker at the Youth Development Center and got the numbers the brief left out, 100 applications a day and 72 sent back, along with the reason behind them.
  • Framed the problem and set the scope: Worked with the team to commit to fixing all three ends together, mapped the flow across them, and drew the line on what we could realistically finish during the event.
  • Built the applicant interface and the OCR redaction: Wrote the applicant-facing frontend and implemented the in-browser Tesseract.js recognition, Luhn validation, and masking.

The Hackathon I Lost First

This was my second hackathon. At the first one, a generative AI application event, we did no prep at all and opened the brief for the first time on site. It asked for a lot of modules, and by the time we understood what it wanted, most of our hours were gone. We finished a few features and placed nowhere.

So this time I made the call and mapped the journey before the event began, and walked in with a conclusion instead of a brief. The difference was not that we built more. It was that we knew which direction to build in from the first hour, because we had already decided which problem was worth solving.

Outcome

Ka-Ho-Sim placed 2nd in the Maker Track at the 2026 Meichu Hackathon, out of 12 teams.