Kawan

A multilingual kiosk concept that helps older residents describe a need, find a relevant agency or community resource, and pass complex cases to local volunteers with useful context.

Role: Full-stack product developer · The Good Hack 2026 team
Period: 8 – 10 May 2026
State: Hackathon winner · prototype

Problem

The problem

Requests from older residents often begin as open-ended conversations rather than a known service category, making it difficult to choose the right agency or community channel.

Outcome

Shipped a working prototype in three days and won “Ah Gong, Ah Ma’s Favourite,” the audience-voted award at The Good Hack 2026.

Contribution

Ownership boundary

I worked across the kiosk interface and the backend workflow that moved voice-led requests into guided recommendations and structured escalation context. This page describes that boundary without claiming sole authorship of the team prototype.

Designed for a Housing & Development Board void-deck kiosk context in Singapore.
Complex cases could be escalated to Member of Parliament or Residents’ Committee volunteers with structured context.
The prototype was built for a three-day hackathon and is not presented as a deployed public-service system.

Under the hood

Tools & responsibilities

Next.js + TypeScript: Supported rapid product iteration across the kiosk interface and request flow.
Cloudflare Workers: Kept the prototype backend close to the rest of the Cloudflare delivery stack.
Workers AI + SEALion: Supported multilingual interpretation and guided response generation in the prototype.
D1, R2, and KV: Covered structured records, object storage, and fast key-value state during the build.

System view

From conversation to a usable next step

The workflow narrows an open-ended spoken request into an actionable recommendation or a context-rich human handoff.

Spoken request
Multilingual interpretation
Need classification
Agency or local resource
Human escalation when needed

Engineering judgment

Engineering decisions

The constraints, alternatives, and trade-offs behind the implementation.

Start with conversation, not a form

Constraint: A resident may know the problem but not the service vocabulary or agency responsible for it.
Options: Present a long category menu, require typed search, or accept a spoken description and progressively narrow it.
Decision: Use a voice-first multilingual flow with guided follow-up prompts.
Result: The prototype could begin from the resident’s own description instead of expecting prior knowledge of the service map.

Keep difficult cases human-readable

Constraint: Not every request can be resolved safely by a fixed recommendation or generated response.
Options: Return a generic failure, invent an answer, or package the conversation into a structured handoff.
Decision: Create an escalation path that preserves the request and relevant context for local volunteers.
Result: The prototype demonstrated a graceful boundary between automated signposting and human support.

Reliability approach

When things go wrong

The team tested the complete prototype flow during the hackathon and presented it in the final demonstration.
The public repository and hosted prototype provide inspectable implementation evidence.

Limits and next evidence

Limitations & next steps

This is a hackathon prototype, not a validated or deployed government service.
Team size and authored contribution links remain omitted until they are verified.
Additional photos and the pitch deck remain hidden until public-safe optimized files are supplied.

Next case study

PeerPrep

Delivered the collaboration layer for synchronized editing, presence, authenticated room access, reconnect recovery, and persisted attempt history.

Want to discuss the implementation boundary or trade-offs? Julius Gwee is available for software engineering opportunities.