Skip to content
View case studies
Welfare SaaS2026Japan

SHINY

Scheduling and operations for Japanese welfare providers, on the web and in the hand.

Role
Full Stack Product Engineer
Industry
Welfare SaaS
Client
Product Company
Market
Japan
Duration
Ongoing
Status
Live
SHINY on desktop
SHINY on iOS
Overview

What it is

A multi-tenant platform for Japanese non-profits running disability services, mobility transport, recreation and daycare. Bookings, staff rostering, vehicles, venues, attendance, incidents, daily contact books, compliance documents, live trip tracking and subscription billing sit in one system, with a web dashboard for coordinators and an Expo app for the staff, guardians and participants who are out in the field.

Problem

What was going wrong

Welfare providers were running the day on paper and phone calls: a booking agreed by phone, a driver assigned on a whiteboard, a contact book filled in by hand and handed over at pickup. Nothing reconciled, guardians had no way to know whether the van was coming, and the compliance record only existed if someone remembered to write it down.

  • Run bookings, staffing, vehicles and venues from one schedule
  • Give guardians and field staff a phone app, not a cut-down website
  • Let a guardian see the van is on its way without exposing a staff member's movements
  • Bill in yen through Stripe with compliant Japanese invoices
  • Ship the whole product in English and Japanese, not English with a translation bolted on
Solution

How it was built

One Express and Prisma API over PostgreSQL serves three clients: a React dashboard for admins and coordinators, and an Expo app for staff, guardians and participants. Roles are ranked, so an actor can never act on someone who outranks them. Live position is stored on the assignment row and nowhere else, consent is checked twice before a fix is kept, and every guardian-reachable booking read goes through one relation that deliberately omits the live coordinates. Stripe handles hosted checkout in yen, including konbini and bank transfer, and a single daily cron does the reminders, the sweeps and the weekly digest.

Challenges

The parts that were hard

01

A guardian should see the van, not track the driver

WhyGuardians need to know their transport is on its way. Staff need not to be followed around all day. Those two requirements pull in opposite directions, and getting it wrong turns a helpful feature into surveillance of an employee.

FixThere is no ping-history table at all — position lives on the assignment row and is wiped when the trip ends, leaving a single 'ended here' point rather than a trail. Two consents are required before any fix is stored, and a guardian's view is snapped to a roughly 110 metre grid while dispatch keeps the exact fix. A source-level test asserts that every guardian-reachable booking read uses the relation that omits the live pair, because the blur only means anything if no path skips it.

02

A confidently wrong pin sends a driver to the wrong city

WhyFree geocoding matches a whole address string or nothing, so real Japanese and Indian addresses often returned no result. The instinct is to retry with looser fragments, but a bare street name resolves to a different city entirely.

FixLookups are anchored to the organisation's own city and country, capped at two or three candidates with a deliberate gap, and never fall back to a bare fragment. No pin beats a wrong pin, so the mobile navigation screen degrades to the address and an 'open in Maps' action instead of showing a plausible but wrong marker.

03

Maps that crashed the Android build with no way to catch it

WhyThe native maps library hard-crashes a standalone Android build without a Maps key in the manifest, and a native crash cannot be caught by a React error boundary — the app just dies.

FixMaps moved to Leaflet inside a WebView, which removes the native dependency entirely and let map provider become a per-organisation setting: OpenStreetMap by default so a new org costs nothing, Google only when an org supplies its own key and the platform verifies it before saving.

Outcome

What changed

  • Bookings, staffing, vehicles and compliance records moved off paper into one schedule
  • Guardians can see a trip is under way without a staff movement trail ever being stored
  • New organisations onboard with zero map configuration and zero map cost
  • Billing, invoices and consumption tax handled in-product rather than by hand
Takeaway

What I'd carry forward

The privacy model was the architecture, not a setting on top of it. Deciding early that no movement history would exist made every later feature simpler, because there was never a table to accidentally expose.

Screens

Every screen, end to end.

Click a screen to open it full size
SHINY screen 1 of 11
01 / 11

All 11 desktop screens

Laid out in full
SHINY screen 1
SHINY screen 2
SHINY screen 3
SHINY screen 4
SHINY screen 5
SHINY screen 6
SHINY screen 7
SHINY screen 8
SHINY screen 9
SHINY screen 10
SHINY screen 11
The app

The same system, in the hand of whoever is doing the work.

Shipped on iOS. 15 screens captured from the running build.

SHINY app screen 1

Guardian home

SHINY app screen 2

Pickup navigation

SHINY app screen 3

Staff task, in Japanese

SHINY app screen 4

Daily contact book

SHINY app screen 5

Guardian home, in Japanese

SHINY app screen 6

Profile and language

SHINY app screen 7
SHINY app screen 8
SHINY app screen 9
SHINY app screen 10
SHINY app screen 11
SHINY app screen 12
SHINY app screen 13
SHINY app screen 14
SHINY app screen 15
Start here

Have a product idea, or one that stalled?

Tell me what you’re building and who it’s for. If I’m the wrong fit I’ll say so on the first call and point you somewhere better.

Based in Jaipur, India (GMT+5:30). Replies within one business day.