Education · Product systems
Working prototypeTutor Collaboration Mini App
A WeChat prototype for tutoring, after-school-care collaboration, and student part-time services. Built around explicit roles and business rules.
The starting point
Problem & product concept
A friend doing part-time tutoring in Shaoxing described an opportunity to refer families to after-school-care providers. Yi Zhou began exploring how to organize requirements, referrals, and cooperation in a small software product. This origin is his account, not evidence of platform revenue.
Institution services
Parents or students express tutoring or after-school-care needs; participating providers would coordinate their own services and contact teachers as appropriate.
Current scope. Own Parent requests and Institution applications are implemented. Institutional access to leads, assignment, and collaborative confirmation remain planned. A separate student role is not established.
Student part-time services
A separate service area for university and graduate students. Its opportunities are not automatically assigned by institutions.
Current scope. Tutor profiles and example demand browsing exist. A complete independent part-time marketplace is not established.
These are two independent business areas within one Mini Program. Parent, Tutor, and Institution are roles; they do not make every student opportunity institution-assigned.
Yi Zhou’s contribution
Yi Zhou reports defining the product direction, recognizing that the initial Tutor-only implementation missed Parent and Institution needs, and requesting the additional roles. He operated the Mini Program in WeChat Developer Tools, reported errors, and identified an unreasonable commission-status flow during testing.
Working with AI
Yi Zhou supplied and refined requirements with ChatGPT. Codex implemented much of the JavaScript, WXML, WXSS, cloud logic, and test code. Yi Zhou reports operating the application, examining behavior, and requesting revisions. This is AI-assisted product development; it is not a claim that he manually wrote every line.
A specific challenge
Owning a commission should not mean approving it
What surfaced
Yi Zhou reports that repeated confirmations in an earlier test advanced a Tutor's own commission through pending_confirmation, pending_settlement, and paid while its amount was null. No actual payment occurred. The original vulnerable handler was not located in the available history.
The response
The inspected current server denies Tutor financial advancement with FORBIDDEN before looking up the target commission. New candidates begin pending_verification with an unknown amount and settlement date. The Tutor interface is read-only; independent Platform/Admin approval and actual payout are still unimplemented.
What this illustrates
The case illustrates why a successful button action or a passing test is not enough: the product must define who has authority to change each business state.
Technical lesson drawn from the evidence. Yi Zhou’s personal reflection is being documented in his own words.
How the system is organized
A native WeChat client uses a shared Cloud Development identity entry. Server-side account, role, ownership, and membership checks determine access. Selecting a role in the interface does not grant that role's server permissions.
Parent requirement lifecycle
- Draft
- Submitted
- Editable
- Cancelled · read-only
Commission boundary
- Enrollment reported
- Candidate · unverified
- Tutor · read-only
- Tutor
- Own profile and referrals, with read-only commission records.
- Parent
- Own profile and requirements, including drafts, submission, edits, and cancellation.
- Institution
- Own application and review state, subject to account and membership checks.
Decisions that shape the work
- Keep the roles in one Mini Program with a shared identity foundation.
- Separate resource ownership from authority to approve financial states.
- Label unknown amounts and historical test states without treating them as confirmed earnings.
Evidence & verification
Source inspection, local interface observations, historical reports, and applicant-supplied accounts establish different things. The labels below keep those boundaries visible.
Current defensive implementation
The commission handler rejects financial advancement before target access. Parent ownership checks, institution membership checks, and ordinary-role boundaries are present in source.
Existing regression assertions
Test source covers direct financial calls, spoofed inputs, cross-account reads, and future financial actions. These tests were inspected, not rerun for this portfolio.
Historical device acceptance
Project records contain owner-reported deployment and device checks. Those reports are separate from current source inspection and the newly supplied phone image.
An honest boundary
Current maturity & limitations
- Prototype and experience-version evidence do not establish a completed public commercial release.
- No verified revenue, active-user count, real payment, wallet, or withdrawal is claimed.
- Institution leads, assignments, independent Parent confirmation, and Platform/Admin financial approvals remain incomplete.
- Historical records include a deferred legacy-account check and an unrepaired test commission. They are not evidence that all migration cases passed.
- Phone recordings show selected interface behavior; they do not independently certify the deployed server or complete authorization coverage.