ja contact

00technology / measured 2026.10.03

Technology

buildpassingframeworknonetrackers0cookies0fontsself-hostedapi/api/v1a11yreduced-motion

We build our own software and change it every day. Every number and chart on this page is measured directly from our internal repository.

changes to our software

6,500+

Changes merged into our software since 2026.03.20. Each one passed review before going into production.

2026.03.20 — 2026.10.03

fig.1 changes / monthChanges per month
05001,0001,5002,0002,500maraprmayjunjulaugsep
fig.2 every day since 2026.03.20 — 1 cell = 1 dayThe days we changed our software (1 cell = 1 day)
monwedfrisun2026.03.202026.03.212026.03.222026.03.232026.03.242026.03.252026.03.262026.03.272026.03.282026.03.292026.03.302026.03.312026.04.012026.04.022026.04.032026.04.042026.04.05apr2026.04.062026.04.072026.04.082026.04.092026.04.102026.04.112026.04.122026.04.132026.04.142026.04.152026.04.162026.04.172026.04.182026.04.192026.04.202026.04.212026.04.222026.04.232026.04.242026.04.252026.04.262026.04.272026.04.282026.04.292026.04.302026.05.012026.05.022026.05.03may2026.05.042026.05.052026.05.062026.05.072026.05.082026.05.092026.05.102026.05.112026.05.122026.05.132026.05.142026.05.152026.05.162026.05.172026.05.182026.05.192026.05.202026.05.212026.05.222026.05.232026.05.242026.05.252026.05.262026.05.272026.05.282026.05.292026.05.302026.05.31jun2026.06.012026.06.022026.06.032026.06.042026.06.052026.06.062026.06.072026.06.082026.06.092026.06.102026.06.112026.06.122026.06.132026.06.142026.06.152026.06.162026.06.172026.06.182026.06.192026.06.202026.06.212026.06.222026.06.232026.06.242026.06.252026.06.262026.06.272026.06.282026.06.292026.06.302026.07.012026.07.022026.07.032026.07.042026.07.05jul2026.07.062026.07.072026.07.082026.07.092026.07.102026.07.112026.07.122026.07.132026.07.142026.07.152026.07.162026.07.172026.07.182026.07.192026.07.202026.07.212026.07.222026.07.232026.07.242026.07.252026.07.262026.07.272026.07.282026.07.292026.07.302026.07.312026.08.012026.08.02aug2026.08.032026.08.042026.08.052026.08.062026.08.072026.08.082026.08.092026.08.102026.08.112026.08.122026.08.132026.08.142026.08.152026.08.162026.08.172026.08.182026.08.192026.08.202026.08.212026.08.222026.08.232026.08.242026.08.252026.08.262026.08.272026.08.282026.08.292026.08.302026.08.312026.09.012026.09.022026.09.032026.09.042026.09.052026.09.06sep2026.09.072026.09.082026.09.092026.09.102026.09.112026.09.122026.09.132026.09.142026.09.152026.09.162026.09.172026.09.182026.09.192026.09.202026.09.212026.09.222026.09.232026.09.242026.09.252026.09.262026.09.272026.09.282026.09.292026.09.302026.10.012026.10.02

as of 2026.10.03 · source: internal repository · automated changes excluded

fig.3 latest merges — number, date, kindLatest merged changes (titles withheld because they include internal details)

~/clinic-os (main) $ git log --merges -n 40

  1. #12610docs2026-10-03merged into main
  2. #12609feat2026-10-03merged into main
  3. #12607fix2026-10-03merged into main
  4. #12606docs2026-10-03merged into main
  5. #12604chore2026-10-03merged into main
  6. #12602docs2026-10-03merged into main
  7. #12601feat2026-10-03merged into main
  8. #12600fix2026-10-03merged into main
  9. #12595docs2026-10-03merged into main
  10. #12593fix2026-10-03merged into main
  11. #12591chore2026-10-03merged into main
  12. #12589feat2026-10-03merged into main
  13. #12588chore2026-10-03merged into main
  14. #12587docs2026-10-03merged into main
  15. #12583feat2026-10-03merged into main
  16. #12581feat2026-10-03merged into main
  17. #12577feat2026-10-03merged into main
  18. #12575feat2026-10-03merged into main
  19. #12574feat2026-10-03merged into main
  20. #12573feat2026-10-03merged into main
  21. #12571feat2026-10-03merged into main
  22. #12568feat2026-10-03merged into main
  23. #12567feat2026-10-03merged into main
  24. #12565feat2026-10-03merged into main
  25. #12564feat2026-10-03merged into main
  26. #12561fix2026-10-03merged into main
  27. #12560feat2026-10-03merged into main
  28. #12556feat2026-10-03merged into main
  29. #12555feat2026-10-03merged into main
  30. #12554feat2026-10-03merged into main
  31. #12553chore2026-10-03merged into main
  32. #12550docs2026-10-03merged into main
  33. #12546fix2026-10-03merged into main
  34. #12543docs2026-10-03merged into main
  35. #12542fix2026-10-03merged into main
  36. #12541feat2026-10-03merged into main
  37. #12539fix2026-10-03merged into main
  38. #12537feat2026-10-03merged into main
  39. #12536chore2026-10-03merged into main
  40. #12534docs2026-10-03merged into main

01process

With AI, the people who build and the people who use become the same team.

Until now, the companies that built healthcare software and the medical institutions that used it were separate. Builders had to prioritize features common to many institutions, and users who asked for specific changes often waited a long time to see them.

AI has sharply reduced the cost and time of building software, so the people who know the front line can now build systems around how they actually work. At PreMed, every member of staff is an FDE (Forward Deployed Engineer). We develop as a small team working with AI agents, and what we notice when test-booking ourselves, or what doctors say after looking at a screen, usually reaches the staging environment the same day.

fig.4 from feedback to productionHow feedback becomes part of the system
01Feedbackfeedback02Changepull request03Checks + reviewchecks + review04Stagingstaging05Productionproduction

02one os, not point solutions

Some things point-solution SaaS cannot reach.

Booking, intake questionnaires, medical records, patient messaging, acquisition metrics — the work of a medical facility is connected, yet most systems so far have covered only one slice of it. PreMed builds all of these as a single OS, in the same team as the front line. clinic os, built for clinics, runs in the group's clinics, and hospital os, built for hospitals, is in development.

fig.5 point solutions vs. one osPoint-solution SaaS and a single OS
point solutionsPoint solutionsBookingsystem AIntakesystem BRecordssystem CMessagingsystem Dacquisition datasystem Epeople copy by handcopy & paste between systemsrequests wait months for a releasefeature requests wait for the roadmapnumbers live on separate screensdata stays in silosone osOne os (clinic os)The clinic floor (staff · patients)the floor — where we work every dayfeedback ships the same dayBookingIntakeRecordsMessagingacquisition dataone data model · one set of numbersbuilders and users are one team · updated dailybuilders and users are the same team
point solutionsPoint solutionsBookingsys.aIntakesys.bRecordssys.cMessagingsys.dacquisition datasys.epeople copy by handmanual copy between systemsrequests wait months for a releaserequests wait for a roadmapnumbers live on separate screensdata stays in silosone osOne os (clinic os)The clinic floor (staff · patients)the floorfeedback ships the same dayfeedback → release, same dayclinic osBookingIntakeRecordsMessagingacquisition dataone data model · one set of numbersbuilders and users are one team · updated dailybuilders and users are the same team
  1. 01

    No manual work left at the seams

    When systems are separate, copying and checking data between them remains a human job. With a single OS, the seams themselves disappear.

  2. 02

    Fitted to our operations, not to the average

    Products built for many institutions have to prioritize common features. We build around how the group's clinics work, and can fix things the same day.

  3. 03

    One continuous view of the numbers

    From the first point of patient acquisition through booking to the visit itself, everything sits on the same data — so "invest in acquisition, or add booking slots?" can be decided on a single screen.

  4. 04

    The more clinics, the better the OS

    Clinics that join through succession and newly opened clinics all run on the same OS. An improvement found at one clinic reaches every clinic.

  5. 05

    Updated daily, and embedded on the front line

    The front line changes every day. Updating once every few months is, in our view, already too slow. We update our software every day (6,500+ changes since 2026.03.20). What matters is building an organization that can embed each change on the front line, and the execution to see it through.

03galapagos

Galapagos, our booking system

Galapagos is scheduled to go into production at Kids Clinic Marumaru, opening in November 2026, and will then be rolled out step by step to the group's other clinics.

The Galapagos logo with the tagline "A booking system born from clinical practice", shown with the LINE booking screen and the admin screen
  1. 01

    Patients book entirely within a LINE chat

    Booking, rescheduling, cancelling, joining a waitlist, adding family members and filling in the questionnaire can all be done without leaving LINE. When a patient makes a request in free text, AI checks availability and suggests options; a booking is confirmed only when the patient presses the button themselves.

  2. 02

    AI handles first response; only unanswered inquiries reach staff

    AI answers within the information the clinic has prepared. It never answers symptom questions on its own judgement, and when it detects urgent wording it directs the patient to call 119 or the clinic.

  3. 03

    AI agents carry out detailed admin settings

    Most settings — opening hours, booking slots, services, questionnaire items — can be changed by asking an AI agent. What each user can do is governed by role-based permissions, and every change is logged with who made it.

  4. 04

    Bookings and questionnaires sync automatically with the claims system and EMR

    New patients are registered in the claims system as soon as their booking is confirmed, and questionnaire answers flow into the electronic medical record. Reception and consultation rooms no longer need to copy the same information by hand.

  5. 05

    Automated messages before and after each appointment

    Each message checks that the booking is still valid just before sending, so patients who have cancelled never receive a reminder the day before.

  6. 06

    Features built for pediatric practice

    Services shown by the child's age in months or years, last-minute slots for sudden symptoms, combined bookings for siblings or parent and child, vaccine stock linked to bookings, and more.

  7. 07

    Acquisition tracked all the way to the visit

    For each entry point — ads, website and others — it records how far each patient got through booking and whether they actually visited, in one continuous record. "Invest in acquisition, or add booking slots?" can be decided on the numbers.

  8. 08

    A foundation for any specialty

    Services, consultation durations, questionnaires and notices are set per clinic, and specialty-specific features can be switched off by clinics that don't use them.

fig.6 how a message flowsHow inquiries and bookings flow
Patient (LINE chat)patient on lineinAI first responseai first responseChecks slots, suggests timessuggests open slotsPatient presses to confirmpatient confirmsBillingbillingEMRemrSynced automatically, no re-typing↑ only when AI cannot answerStaff inboxstaff inboxDirects to 119 or the clinicurgent wordsAI never answers symptoms on its own judgementDay-before reminderreminderschecks the booking is still valid before sending
Screens in a LINE chat from choosing a time to a confirmed booking
01Booking completed entirely in a LINE chat
Admin screen listing only the inquiries AI could not answer
02Staff see only the inquiries AI could not answer
Screen where an AI agent is asked to close the afternoon session
03Booking slots and questionnaires can be changed by asking an AI agent
Fever chart drawn from temperatures entered in the questionnaire
06Temperatures entered in the questionnaire become a fever chart
Growth curve drawn from height and weight records
06Growth curves drawn from height and weight records
Screen showing patient numbers continuously from ads and website through LINE and booking to the visit
07One continuous view from ad to visit

* Screens show fictitious demo data (images from the press release).

Inquiries about adoption and partnership →

04toki — generative ui

TOKI, an EMR for fertility care

The electronic medical record used every day in the group's fertility care. Its defining feature is generative UI: the data stays as one, while each doctor can arrange the screen in their own way.

  1. 01

    One set of data, a screen for each doctor

    The same patient data is laid out differently for each doctor. Doctors used to a long-familiar layout keep it; doctors joining fresh get a clear standard screen. For each doctor, we preserve both "knowing where everything is" and "seeing it all on one screen".

  2. 02

    AI drafts the screen; the doctor approves and locks it

    AI drafts each screen definition, and only what the doctor has checked and approved is locked in for use. AI never rebuilds the screen on the fly during a consultation. For a medical record, consistency comes first: the same patient looks the same every time.

  3. 03

    Fix it in one place

    A screen is just a layout definition, so fields and data are corrected in one place only. Content never drifts out of sync between screens.

  4. 04

    Front-line feedback goes straight to development

    A button at the bottom right of the screen lets users send "it would be nice if…" on the spot. Each request is registered directly as a development issue.

fig.7 one data, many layoutsOne set of data, a screen for each doctor
Patient data (one model)one data modeldatascreen definitionAI draftsai draftsDoctor approvesdoctor approvesLocked for uselockedStandard viewstandard viewPer-doctor viewper-doctor viewAI never rearranges the screen during a consultation
Standard screen showing a patient's course of treatment in a single column
01The standard screen: the course of treatment at a glance
Doctor's screen arranging the same patient data densely across three panes
02The same data in the layout the doctor knows, all on one screen

* Screens show fictitious demo data.