BayonHub
Cambodia-first opportunity platform for tech students
What this proves
I can execute a product pivot without pretending the previous prototype is the current product, rebuild the domain model around real user roles, and define data-integrity and offline boundaries before expanding the feature surface.
Problem
Cambodian tech students often discover internships, freelance work, jobs, and portfolio opportunities through fragmented social posts and personal networks. Employers also lack a focused path to early-career talent across AI, data, cybersecurity, and software engineering.
My role
I own the product direction, domain redesign, frontend and backend implementation, repository workflow, verification strategy, and the public/private evidence boundary.
What I built
- — A bilingual opportunity-platform shell with separate student and employer entry paths.
- — Role-aware authentication and onboarding foundations for students, employers, and admins.
- — Student profile, company, opportunity, saved-opportunity, and application data foundations.
- — Administrative security controls and a documented production launch boundary.
- — An AI-agent workflow that records verification, migration risk, human gates, and rollback in every pull request.
Architecture
BayonHub keeps the React client and Express API as separate workspaces with an explicit product boundary between preview behavior and real writes. Phase 0 replaced the old classifieds domain with student, employer, company, opportunity, saved-opportunity, and application concepts. The key integrity decision is that an application stores historical snapshots, while the key trust decision is that an offline demo can never pretend a consequential application was delivered.
Build the product in reviewable phases: establish role-aware identity and durable application data first, add opportunity discovery and application APIs second, then ship the student-facing workflow only after focused tests and human verification.
Backend / deployment
- Status
- Planned
- Frontend
- React 19 + Vite bilingual product shell
- Backend
- Express 5 + TypeScript API with role-aware auth and admin controls
- Database
- PostgreSQL via Prisma, with Redis and R2 planned for the hosted stack
- Hosting
- Static preview direction only; production services are not launched
Private product build. Phase 0 is merged and verified; the student opportunity and application experience is still a reviewed draft, and no production launch is claimed.
Backend-adjacent proof
- — Email/password authentication with role-specific registration and account surfaces.
- — Transactional creation of student and employer domain records during sign-up.
- — Application snapshots preserve the submitted student and opportunity context instead of depending on mutable live records.
- — Admin access includes email-delivered 2FA, IP allowlisting, rate limiting, CSRF protection, secure cookies, and structured request logging.
- — Repository verification covers both workspaces, dependency audits, focused browser tests, lint, and production builds.
Stack
Constraints
- — The active startup source and unreleased product strategy must remain private.
- — Khmer and English are first-class interface languages, with native-speaker review required for learner-facing Khmer copy.
- — An offline or static preview must never report a successful application when no backend can deliver it.
- — Employer and opportunity verification cannot be claimed without an auditable human process.
Tradeoffs
- — Kept the old prototype in Git history as learning evidence but removed it from the current product story.
- — Chose a staged launch over exposing a broad but unverified marketplace surface.
- — Allowed synthetic read-only preview data while making real application writes backend-dependent.
- — Kept repositories private while publishing enough architecture evidence for recruiters and collaborators to evaluate the work.
What It Demonstrates
- The Phase 0 pivot was merged through a reviewed pull request with green repository, frontend, backend, audit, and browser checks.
- The public portfolio now matches the active product direction and no longer links to obsolete public repositories or demos.
- Phase 1 remains a green draft until the student UI, focused coverage, and human product checks are complete.
What I learned
- — A real pivot requires replacing the public story and domain model, not only changing the headline.
- — Historical snapshots are important when an application must remain understandable after related records change.
- — Offline resilience is useful only when the interface stays honest about which actions were actually delivered.
- — Security controls and claim discipline should be designed before production traffic, not added after launch.
Next backend step
Complete and review the opportunity and application API foundation, then connect it to a student-facing UI against approved PostgreSQL, Redis, R2, and email services.
Next steps
- — Finish the student opportunity browsing, saving, and application interface.
- — Run native-speaker review for Khmer product copy.
- — Verify student and employer flows against an approved staging environment before any launch claim.
Visual archive
Current Phase 0 direction: separate entry paths for students and employers, shown with synthetic public content
Working on something similar?
Let's talk →