From the firstconversationto a live release.

01

Reports were arriving late, or not at all.

Intern doctors at Cheikh Khalifa and Mohammed VI took notes on paper or in phone notes, then transcribed them twice at the end of the day: into an Excel report and into an outdated hospital ERP. Everyone used their own format, so reports were incomplete and inconsistent.

Professors complained. Residents spent their time fixing errors. Sometimes a report took three days and a confrontation to arrive.

Users could only react to something real, and I had no access to the hospital ERP. So I skipped mockups. I shipped MedNotes, a single-user tool for the first resident, in two weeks. Once the team adopted it, they named it SituaTrack, because it tracks and reports the day’s situation. Field feedback drove everything after that.

02

Three jobs, one record.

Interns need to log consistently, with less double entry. Residents, the middle managers, want fewer errors to fix and faster onboarding. Professors want clean, consistent reports and usable data for research.

I spent a week in long interviews with a resident, who described the pressure from both sides. Quick, informal conversations with interns and professors continued through the build and became my feedback loop. 10+ doctors. 248 patients. One week of discovery, three months of iteration. I was the product designer and the developer.

03

I expected fewer clicks. I was wrong.

My marketing reflex said stressed doctors need minimal input. They wanted thoroughness over speed. Printing and research were core needs, not extras.

Status and presentation mattered. I wrote 364 rules to auto-style medical terms so reports read well, and a daily “Hello Doctor / Professor” greeting delighted users more than most features.

04

Morning: the situation du jour.

Login, and export the situation du jour as a PDF, printed for rounds.

05

The round happens on a phone.

During rounds, notes are taken on the phone, and patients are flagged “À discuter” for the team brief. At the end of the day, the entries are checked on phone or laptop and the report goes out in one click.

06

The list is ordered the way memory works.

Diagnosis first, name second. Doctors often forget a patient’s name but never the diagnosis, so the cards lead with it. I kept the detailed forms and made them faster to complete.

With no ERP or barcode access, an OCR JavaScript library auto-fills patient data from tags. It is less accurate than a vision model, and it keeps entry fast. “À discuter” lets the team prioritise cases for briefs and meetings.

One-click copy sends the record back to the hospital. The app generates a full profile in a predefined text structure, ready to paste into the legacy software. This removes the worst part of the double entry.

07

After month one, the ward asked for more.

V1 covered note-taking and PDF export. After month one, doctors asked for appointments, a calendar and research. It started as simple appointment management and became a calendar for professor visits, team meetings, patient appointments and scheduled operations.

The desktop menu grew from 4 to 8 sections. On mobile, secondary features moved behind a header menu, keeping Patients, Add and Appointments in the bottom bar, with all 4 main pages always on display. A professor who only follows oncology patients can create that filter and reuse it. The most important information moved into the main row, after the doctors asked for it there.

08

A wrong deletion cannot be the end of a record.

Admins can roll back any user action in one click, so deleting the wrong patient is never permanent. Residents are the admins. Only they approve new accounts, with a notification on connection and a smartphone push when the email is confirmed, so the list cannot be spammed.

My developer account only sees anonymised names and images, so I never access identifying or distressing content. Each profile sees a specific set of pages, with different access roles and strict row-level security.

09

Time came back, and the arguments stopped.

Estimated from the team’s own accounts: 1 hour a day for each intern on reporting. 15 to 30 minutes for residents who no longer fix reports. 15 minutes for professors when errors used to surface.

Reports now arrive daily with one click. The unit dynamic changed too: less tension, no more arguments over who fixes what, clean reports for professors, and data ready for research. Staff from other services have asked about the tool.

A resident, after month one: “I stopped filling out the forms, now it’s all the interns’ job, I’m so relieved. Everyone is thrilled.” An intern: “The site is incredible.” A professor, on the research feature: “Plus j’y pense plus je trouve que ça a un potentiel de fou.”

10

What I took out of it.

My 3-click rule was the wrong heuristic for this audience. I now ask what “good” means to the users before designing. Building directly gave fast feedback but left no design artifacts. Next time I would sketch flows first and keep a decision log.

Status and protocol are part of usability for hierarchical professions.

01

Be first, and be sure they are French.

The fund wanted to be first to contact early-stage French founders the moment they signalled on LinkedIn. Being a French fund was its advantage, so every lead had to be French, with no exceptions.

I worked alongside the COO to create an automated qualified lead finder. We built Scout over 2 months, starting with a local scraper that brought in 30+ daily leads, then finished with hosting and an executive dashboard.

02

The product question was: how do you tell?

Only a name and a job history are available. My solution was a model trained on the INSEE public name rankings that estimates how likely a name is to be French. The client wanted an LLM instead. He insisted “j’y tiens beaucoup”.

I advised against it, because GPT-4o performed poorly on this task, but we built what the client chose. We never measured both approaches’ accuracy. GPT-4o could give a TRUE answer once, and a FALSE answer if you prompt it again on the same profile. No consistency.

03

The interface was a spreadsheet.

The first version was a black box with no interface. Each day it filled a Google Sheet and posted to a Slack channel when the scraping job finished. The COO already lived in spreadsheets, and was limited in time, so I gave him no new tool to learn. Output was a single TRUE/FALSE per profile, which kept token costs predictable.

04

After a month he wanted to see the machine.

He asked for a V2 with three things: health metrics for the tool, with an on and off switch. An editable GPT prompt, so he could iterate himself. Sales Navigator search URLs as inputs for advanced filters.

He also asked for the AI’s full reasoning in every output. I pushed back because token usage would grow sharply, and I framed it as a cost per lead rather than as no. V2 is the on/off toggle, the search links, the prompt, the model output, and a health check.

05

He ended it. I know the tradeoffs, not the reason.

The spreadsheet and Slack matched how he already worked. TRUE/FALSE was the cheapest output that would scale, and it hides the reasoning. Following the client over my model preserved the relationship, and consistency suffered, and so did satisfaction. The editable prompt and the URL inputs moved the product from a black box to a tool he could configure.

The client ended the service after V2 without giving a reason. I can’t know why. My hypotheses: the LLM’s name accuracy never met his bar, or he found a way to recreate the system with no-code tools he knows, like Zapier.

06

What I would set up before building.

When I’m overruled, I should set a measurable test, such as accuracy on 200 labelled profiles, before building, so the decision rests on evidence rather than on persuasion.

“Minimal” isn’t automatically right. After one month, this user wanted visibility into how the tool worked. I should have offered a simple health view from the start. Cost is a design constraint. Showing what full reasoning would cost per lead is the conversation I would have earlier.