Dr.Well-B
Dr.Well-B is a membership platform for doctors, dentists and medical students in Japan, launched publicly in 2023. Rather than solving one task, it brings many services into one portal: verified professional accounts, profile-based advertising, surveys, recruitment and job search, professional content and a reward-point programme — all run by an operations team from a back-office console.
I was the Tech Lead from 2022 to 2024 and also worked directly on the backend: technical direction, system and data-flow design, the Node.js / NestJS API, Firestore, search, background processing and the Google Cloud services around them, code review, and coordination between the Japanese side and the development team in Vietnam.
Why it is a management-system project: every module reads the same member profile and writes to the same action log. A change to how ads are targeted changes points, reports and exports downstream — so the work was as much about workflows, data flow and back-office control as about individual features.
Modules and who uses them
Two groups use the system. Members — doctors, dentists, doctors in training, independent practitioners and medical students — use the member portal. Operators and admins use a separate administration console to review accounts and approvals, manage ads, suppliers, surveys and job postings, and run downloads.
Diagram fitted to its frame
My responsibilities
- Set the technical direction and chose the solution for each large feature, assessing technical risk before it was built.
- Designed the system architecture and how modules exchange data.
- Designed and built backend APIs in Node.js / NestJS.
- Designed the Firestore data model, Elasticsearch search, background processing and the cloud services behind them.
- Reviewed technical designs and pull requests, reviewed security, and unblocked the team on hard problems.
- Set the unit and automation testing strategy (Cypress) for a system with many rules.
- Supported staging and production deployments, and tracked technical progress and risk across the large features.
Membership with professional verification
Registration here is a verification workflow, not an email-and-password form. The platform collects professional data — specialty and sub-specialty, workplace, department, position, graduation year, university, student number, licence number, clinical training — and verification documents such as licence images, student cards, training certificates and CVs.
When the details can be verified, the account is activated straight away. When they cannot, the application moves into an admin approval flow: the member is asked for more documents, an admin reviews them, the decision is recorded in an approval history, and the record is locked once it is approved. Each outcome sends its own email.
Diagram fitted to its frame
Profile-targeted advertising
Ads are not random banners. Each one carries delivery rules: placement and banner size, destination URL, banner or text, tags, target specialties and medical societies, a delivery window, a click limit, a priority and a status. Selection filters every active ad against the member's profile and history, and what a member does with an ad feeds back into the next selection — hiding or refreshing an ad can drop it from that member's candidates or lower its priority for them, while signs of interest keep similar ads coming.
On the console side, operators create, copy and schedule ads, set limits and priority, manage the suppliers behind them, and can download the list of members an ad's tags match.
Diagram fitted to its frame
A configurable survey engine
Admins build surveys without code: title, description, notes, minimum and maximum responses, publish state and a linked ad, then questions with a type, required or optional, answer lists and free input. Questions can depend on each other — "if question 1 is A, show question 2" — which gives conditional branches, sub-questions and embedded questions. Members get a form that changes with their answers, and in some flows a changed answer overwrites the earlier one instead of creating a duplicate submission.
Diagram fitted to its frame
Points and rewards from action logs
Points are not calculated inside the request that earns them. Eligible actions — ad clicks, job actions and configured bookings — are written to action logs, and batches do the rest. The daily batch reads unprocessed logs, checks eligibility, looks up the points for each action, applies the rules (several clicks on the same ad or job in one day count once; points are capped per month), writes a point distribution plan and marks the logs as processed. The monthly batch aggregates points and profiles into distribution results and files. Members redeem their points through a partner points app.
Diagram fitted to its frame
Asynchronous exports and notifications
Survey results, full doctor-profile exports, CSV files and ZIP archives can take far longer than a request should. They run as background work on Cloud Tasks and Cloud Functions; the file lands in Cloud Storage, and Firebase Cloud Messaging tells the admin when it is ready — the console asks for notification permission for exactly this. A download history keeps track of past exports.
Business email covers the rest of the lifecycle: registration complete, licence verified, licence not verified, additional documents requested, and system or operational notices.
Diagram fitted to its frame
Job search on Elasticsearch
The member portal includes recruitment and job search, filtered by free text, employment type and prefecture. Search, filtering and sorting run on Elasticsearch indexes rather than on Firestore, and searches and clicks are logged for points, tracking and analytics.
High-level architecture
Angular applications sign in through Firebase Authentication and call a Node.js / NestJS backend. Firestore holds business data, Cloud Storage holds files, Elasticsearch serves search, and Cloud Run, Cloud Functions and Cloud Tasks carry the background work. BigQuery serves aggregation and reporting, Cloud Logging collects logs, and Firebase Cloud Messaging delivers notifications.
Diagram fitted to its frame
How data moves between modules
Diagram fitted to its frame
What the project covers
| Concern in a large management system | How it shows up in Dr.Well-B |
|---|---|
| Business workflow with approval | Licence verification, admin approval, approval history, locked records |
| Rules configured by operators, not code | Survey engine with question relations; ad delivery rules |
| Personalisation | Ad selection by specialty, society, tags, schedule, limits and behaviour |
| Event and batch processing | Action logs, a daily point batch, then monthly aggregation and files |
| Long-running work | Background exports on Cloud Tasks / Cloud Functions, FCM notification |
| Search at scale | Elasticsearch indexes and sorting, separate from Firestore |
| Reporting | BigQuery aggregation, CSV/ZIP export, download history |
| Keeping many rules from regressing | Cypress automation across services, surveys and mobile browsers |
The diagrams are reconstructed at component level from the project's design documents. They omit internal URLs, identifiers, proprietary code and client data; the screenshots use test accounts and demo data, with internal names blurred.
Image 1 of 5
