The whole product is built on trust. We're not going to undermine that by hiding our open problems. Here's what's in the box today, what's planned, and — most importantly — the five gaps a school IT department will ask about the moment they read the spec.
These are the five issues an outside reviewer flagged in the spec. Each one matters for real-world deployment. None are pretended to be solved.
The problem. In the US, schools dealing with student data must comply with FERPA (Family Educational Rights and Privacy Act). In Taiwan, there's PDPA (Personal Data Protection Act). The app itself claims to collect nothing — but the code distribution step requires the school to handle a list of eligible voters. That list is personal data.
The open questions.
Why it matters. This is the first thing any school IT department will ask. Without a clear answer, the procurement conversation ends before it begins.
Next step: We need to write a "Data Handling" section into the spec that names a retention period, a deletion process, and an audit log.
The problem. The spec says results are shown after the poll closes. It never says what happens after that.
The open questions.
Why it matters. Schools need audit trails and need to comply with data retention policies. Both, simultaneously. The current "store everything indefinitely" default doesn't satisfy either.
Next step: We need to answer this in the spec. A reasonable default would be: results stored for 2 years, exportable on demand, permanently deletable by the operator at any time.
The problem. If voting is anonymous and codes are single-use, what stops a student from giving their code to a friend? The spec acknowledges this as "the biggest unsolved challenge" and lists possible mitigations — but commits to none.
The strongest proposed solution (from the reviewer). Codes are delivered through the school's existing authentication system (school portal or LMS). The student logs into their school account, receives the code there, and the code expires within a short window. This doesn't make sharing impossible — it makes it inconvenient enough that most students won't bother.
Other mitigations.
Why it matters. If a school reads this and sees no committed solution, they'll see it as a hole. The mitigation needs to be explicit and defended.
Next step: We need to commit to one solution. The school-portal route is the strongest candidate.
The reviewer's concern. The team is based in Hsinchu. Schools there operate in Mandarin, and many are bilingual. If this tool only works in English, it immediately loses most of the local market.
The current state. The app is already deployed in both English and Traditional Chinese (繁體中文). Every page has a language toggle. Translations live in a single JSON file, so adding more languages later is straightforward.
Status: This is the one gap from the reviewer that's already solved.
The problem. The spec doesn't say how a school actually starts using the app.
The open questions.
Why it matters. Without a Getting Started section, the spec feels incomplete. Schools can't say yes to something they can't picture deploying.
Next step: We need to write a one-paragraph "Getting Started" section: who signs up, what they need, what the first 30 days look like, and how to train operators.
Every feature in the spec, with honest status. No marketing pretending unbuilt things are shipped.
| Feature | From spec section | Status |
|---|---|---|
| Admin creates a poll with title/description/options | §13 | Built |
| One-time code generation | §7 | Built |
| Code-vote separation (anonymity) | §6 | Built |
| Code locked after single use | §7 | Built |
| Results after close (never live) | §10 | Built |
| Yes/No & single choice questions | §5 | Built |
| Multiple choice questions | §5 | Built |
| Ranking questions | §5 | Built |
| Rating Scale (1–5) questions | §5 | Built |
| "I choose not to vote" with 3 reasons | §4 | Built |
| Three visibility settings (Private / Shared / Public) | §10 | Built |
| English + 繁體中文 | Reviewer §4 | Built |
| QR codes per voter | — | Built |
| Auto PDF / XLSX / JSON exports | — | Built |
| Scheduled close at deadline | §9 | Built |
| Written / open-text feedback responses | §3 | Planned |
| Verifiable anonymity (confirmation hash) | §6 | Planned |
| Code resend & invalidation flow | §7 | Planned |
| Minimum participation threshold | §10 | Planned |
| Written response moderation | §10 | Planned |
| Operator dashboard (multiple polls) | §13 | Planned |
| Safety escalation banner / training | §11 | Planned |
| Data retention & deletion policy | Reviewer §2 | Open problem |
| FERPA / PDPA compliance documentation | Reviewer §1 | Open problem |
| Code-sharing prevention | §7 / Reviewer §3 | Open problem |
| "Getting Started" onboarding flow | Reviewer §5 | Open problem |
Minimum version first. Everything else layered on top, in priority order.
Every product website overstates a little. We try not to, but here are the places where you should read carefully.
The app stores no identity with the vote. But the school still holds the eligible-voter list. A bad actor with access to both the school's list and the app's vote pool, plus timing data outside the app, could narrow things down in small populations. For a 12-person teacher survey, true anonymity is harder than for a 500-person student election.
If someone with power over a voter (a parent, a teacher, a senior student) demands to watch them vote, the anonymity guarantee doesn't help. The system can't tell the difference between a free vote and a watched one. We can only say: anonymity defends against retaliation after the vote, not pressure during it.
If a poll is socially fraught, voters might pick "I choose not to vote" rather than express their real opinion. The non-participation data is still useful — but it's not a substitute for a culture where honest disagreement is safe.
The reviewer's verdict: "The product is strong enough. The challenge is distribution, not the product itself." Schools have year-long procurement cycles. A 9th-grader emailing a principal gets ignored. The realistic path is through student council advisors and sympathetic teachers — and it will be slow.
The outside reviewer's verdict on when this can actually make money.
Deploy free at the pilot school. Get 200+ real student council votes. Document everything.
Turn results into a case study. Pitch 2–3 other Hsinchu schools.
Once 3–4 schools are using it, start charging. School-wide $200–500/year plans.
Sustained growth via word-of-mouth between schools. The "I choose not to vote" feature is the headline that no competitor has.
The reviewer's conclusion: "The product is strong enough. The challenge is distribution, not the product itself."