I built 치과동행 around the two sides of a dental visit

PRODUCTS & SYSTEMS · MAY–JULY 2026 · RELEASED

Two notes, one visit

Before an appointment, the useful details include where the pain is, when it began, what makes it worse, current medication, allergies, and questions for the dentist. Afterwards, the problem changes. The user needs somewhere to put remembered explanations, precautions, and things to check next. I gave those moments separate paths rather than forcing them into one generic note.

The pre-visit screen breaks a symptom note into practical fields such as side, location, onset and pain level. Missing fields remain visible, and the completed form becomes a short summary that can be shown before treatment. The post-visit screen stores what the user remembers and makes the note available for later reading or speech output.

A separate instruction-sheet flow accepts a camera image or an item from the photo library, recognises the text, and presents a simpler version for the user to check against the original. I also added a dental glossary and a calendar-style visit record. These pieces came from the same design question: what will someone need to find again when the appointment is no longer fresh?

More than one way to operate the app

The interface includes large-text and high-contrast settings, voice input, text-to-speech, and haptic feedback. A user can work through the app directly or use a caregiver mode. The app also lists the national centre and nine regional dental-care centres for people with disabilities, with a route back to the official government source because addresses and contact details can change.

Those features describe what I implemented; they are not evidence that the app is accessible in practice. I have not completed a usability study with blind users, people with cognitive disabilities, or their caregivers.

치과동행 does not diagnose a condition or choose treatment. Its job is to organise what a user wants to say and what they were told.

Making the browser interface behave like an Android app

I built the interface in React and Vite, then used Capacitor to package it for Android. Speech recognition, text-to-speech, camera access and haptics each needed a bridge to the phone. The release also required an application ID, permissions, launcher and splash assets, signed builds, store copy and screenshots.

One failure only appeared on a physical device: the Android back button was not reaching the web layer, so the exit path silently stopped working. I traced the hand-off between the JavaScript event handler and Android’s native back dispatcher, added a direct native-to-web event route, rebuilt the application and tested the flow again on the device.

Text assistance can connect to an external AI provider selected by the user. A limited keyword-based mode remains available when no key is present. The central product decision was the order in which someone would need the information during a dental visit.

What made it into the public record

The Korean Copyright Commission record gives a creation date of 4 May 2026 and a registration date of 13 May for 치과동행 (Chikwa Donghaeng). I have not reproduced the certificate because the original contains private address and birth-date information.

The Google Play page carries the app description, developer name, six product screenshots, and an update dated 30 July 2026. On 4 September, it displayed the 10+ downloads band. The exact install count is unavailable; the listing confirms that the app moved beyond a local build into public distribution.

Where the evidence stops

The public release and the minimum download band are verified. Monthly active users, retention, real-world usability, communication during an appointment, institutional adoption, and revenue are not. There is also no clinical-outcome claim to make: this is an information-organising tool, not a medical device or treatment system.

The next useful test would be smaller than another feature release. I would ask people to prepare a visit note and recover a post-visit instruction on their own phones and assistive-technology setups, then watch where the flow breaks. That evidence would say more about the app than another list of functions.

---

Project record
Period: May–July 2026
Role: problem definition, product design, React/Vite implementation, Android packaging, accessibility options, device debugging, and Google Play release
Administrative record: computer-program registration (created 4 May 2026; registered 13 May 2026)
Externally verified: public Google Play listing, 10+ download band, and 30 July 2026 update
Not established: active use, usability or accessibility outcomes, clinical impact, institutional adoption, or revenue
Store status checked: 4 September 2026

한국어로 읽기