TheiA Super App

The existing treatment-room screen let doctors and nursing assistants check and update a patient's treatment status, but it was limited to a PC-based web environment.

In a clinical setting where staff move frequently, it was difficult to record status immediately before or after treatment, creating a gap between when the work happened and when it was entered into the system.

I extended the treatment-room workflow to mobile devices so status could be recorded where treatment takes place.

Rather than putting every function into one app, I designed a mini-app structure that separates permissions and workflows by role.

Structured the role-based apps to be managed in a single monorepo.

Owned the planning and development of the Interaction App, and designed the Figma drafts and UX flows for the other apps, such as the anaesthesia and treatment apps.

Treatment workflows naturally include waiting periods, such as the time required for anaesthesia to take effect. Rather than leaving that time as passive waiting, I saw an opportunity to present DERMA:CODE results and clinic guidance in a way that helps patients feel actively cared for.

To record states such as anaesthesia start and end, clinicians had to dig through several levels of screens to find the patient every time, which added time spent on work outside treatment.

I judged that one tablet placed in the treatment room could improve the patient's wait and shorten the clinicians' recording path at the same time.

I split role-based (patient / clinician) screens inside one app to meet the floor's mixed needs in one go.

Patient view: during waits such as anaesthesia, patients can open their own DERMA:CODE skin analysis results or check useful nearby information such as pharmacies and transport.

Clinician view: kept the existing work rules from the PC and the treatment mini app (step transitions, admin authentication and so on), and designed screens so doctors and nursing assistants can record status events on the spot in the treatment room.

Went beyond implementing requirements and led the whole project, from UX planning and coordinating design assets to the actual build.

With no hands-on Flutter experience, I made heavy use of AI coding tools, ran feature definition and verification myself, and finished an MVP at a release-ready level in two months.

Every time a record photo was taken, the face's position and angle differed slightly. One shot did not take long, but the framing had to be redone every time, and a returning patient's before-and-after photos were taken under different conditions.

It happened on every shot, yet it never came up as an improvement request and no related feature was in the brief.

Decided that a problem which recurs and affects later work should be fixed first, brief or no brief.

Showing an alignment reference on the camera screen was cheap to build, so instead of a separate feature I put the reference into the capture process itself.

Overlaid an alignment guideline on the camera screen for positioning and angling the face.

Users line the face up inside the guide and then take the shot.

Clinicians and the CEO responded well, and it became the fixture that keeps record photos framed consistently.

It was not in the brief, but observing a repeated task led to an improvement that also accounts for comparing a returning patient's photos.

The patient tablet's guide content (video, images, maps and text in five languages) lived as files inside the app bundle. Fixing one line of copy meant shipping a new build, and because it was hardcoded for one clinic, there was no flexible way to add another.

I first handed off the requirements as a planning brief, but the first builds stopped at moving image URLs or porting the existing file layout to an API. My initial handoff did not communicate the development intent clearly enough to the backend team.

So that nothing could be read two ways, I rewrote it as a spec at the level of an interface contract rather than a list of requirements: DB schema, API, validation rules and error codes, admin screens, app rendering rules, and seed data for the existing clinic, all in one document.

I split what can be edited into three kinds. Existing items can be edited and hidden but never deleted. Per-clinic differences are handled by operators adding their own items. Menus that display patient treatment data aren't content, so only their order and visibility can be set.

Storage is one document per clinic. Splitting menus, tabs and blocks into tables would mean a migration every time a block type is added. Instead the server validates against a schema and sends the app only the finished document, with languages and image URLs already resolved.

The backend engineer shipped the implementation across three repositories the day I handed off the spec, and I then finished the operator editor and the app side.

The app caches the document for the session and, when a screen opens, only asks via ETag whether it changed. If it hasn't, a 304 ends the request.

Content changes and new clinics no longer need an app release. The only thing that does is a new block type.