A multilingual hospital platform

• Frontend Developer · SaaS projects (owned the website builder and booking system)
• GitHub Issues/Projects, two-week sprints, team wiki documentation, Slack

• Next.js
• React
• TypeScript
• SWR
• React Hook Form
• Framer Motion
• Tailwind CSS
• next-auth
• Storybook

• SaaS: a website builder that gives each hospital its own domain site. Owner
• Admin: internal tool for hospitals, doctors, bookings, and content. Legacy migration
• iCH: the main site for hospital search and booking. SEO improvements

Tailwind direction classes like pl and mr don't flip in RTL, so dir ternaries were spreading through the code. I documented rules for switching to CSS logical properties (ps, pe, start, end) and the responsive priority pitfalls in the wiki and shared them with the team. Translation for all 40+ languages was automated with GPTs.

I refined the booking screens with Framer Motion interactions and designed walk-in booking, cancellation, and refund flows with the backend at the API level. I owned booking development while clients grew from about 50 to over 1,000.

Pages that needed search visibility but were rendered client-side moved to SSR and SSG, and rarely changing SSR pages moved to SSG with On-Demand Revalidation.

Sequential server-side API calls were parallelized with Promise.all, or Promise.allSettled where the page must render even if some fail, cutting initial HTML load from 1.79s to 1.2s (~33%). I also fixed the Azure Search based sitemap generation to recover ~5% of missing pages and added per-language alternate links.

SWR stores data using the full API URL as its key. Admin URLs carried search params like ?page=1&limit=10, so reusing data another component had already fetched meant passing the same params down through props.

I set a rule to name data when fetching it and built a hook that finds the key in the SWR cache by that name and reads the data, removing the prop drilling. It was used in 18 admin files, and I documented why and how in the team wiki. (2023.04-05)

// Parent: name the data when fetching it
getArticleContributorsSWR(searchOption, 'getArticleContributors')

// Child: read it by name, without the search params
const { data } = useSWRGetCacheData('getArticleContributors')

// Revalidating by name is also built into SWR 2.0
mutate(key => typeof key === 'string'
  && key.includes('getArticleContributors'))

I also built revalidation by name, which SWR 2.0's mutate filter function could already do. Today I'd use array keys with a fixed name prefix and a custom hook that reads search params from the URL, removing the need to search the cache at all.

Clicking save quickly stored the same data twice. Routing inside the SWR mutation's onSuccess meant React Hook Form's isSubmitting didn't wait for that promise, so the button re-enabled too early.

• await the upsert inside the function passed to handleSubmit
• disabled={isSubmitting} on the submit button
• await router.push outside onSuccess
• Type the upsert prop as returning a Promise

Shared in the team wiki and on my blog. Duplicate delete requests were fixed the same way

a-hospital.icloudhospital.com ─┐
b-clinic.icloudhospital.com  ──┼─▶ Application Gateway
…                            ──┘          │
                                          ▼
                             App Service ×1 (SaaS, CSR)
                                          │
                                          ▼
                          hospitalSlug → metadata API

Over five sessions I took over ArgoCD, Prometheus monitoring, domain purchase and delegation, and the AKS deployment flow.

Registering redirect URLs in the Google and Facebook consoles by hand for every new hospital subdomain was automated with a Selenium script.

Legacy migration without onboarding, bundle size optimization, proposing React Hook Form over Formik, and taking over the SaaS project.

Supporting RTL with logical properties in Tailwind, and what to watch out for.

Why isSubmitting releases early, and the four rules I shared with the team.