Deepthi's Reading

Systems

034

The doctor-buddy-app Story

A pocket assistant for the ward

Lovable · React · Supabase · Capacitor

Edition #034 · 6 chapters · 6 min read

The doctor-buddy-app Story

A pocket assistant for the ward

A quick-reference companion app for doctors on the floor.

An ebook edition of the doctor-buddy-app build journey: how it started, what actually happened, the conversations that changed the build, what broke, and what I learned. Written in plain English for readers with no technical background. Tools covered: Lovable, React.

Start reading Back to the library

Start here

What you'll understand by the end

Not mastery — understanding. By the last page you'll be able to explain these in your own words, even with no technical background.

•what Lovable really is, and what it cannot do
•what React really is, and what it cannot do
•the difference between what the AI does, what the tool does, and what I do
•why permissions and privacy matter once AI can act on your behalf
•where a real person's judgement is still necessary

The concept ladder — the order I actually learned things

I had an idea worth building

↓

I asked an AI to help me shape it

↓

I learned the AI could explain things but could not act outside the chat by itself

↓

I met the tools that actually do the work

↓

I learned how those tools are connected and permitted

↓

I built something real and watched it break

↓

I learned where my own judgement is still required

Chapter 01

Why Doctor Buddy had to exist

Track 1 · My journey

Repertorisation on paper is slow enough to shape the consultation around it. Grading symptoms against rubrics and totalling remedies by hand takes time that the patient is sitting through.

Learning checkpoint

Before this chapter

I had a problem I could describe in a corridor conversation, but nothing I could hand to anyone.

After this chapter

I still did not know which tools to use, but I knew exactly who I was building for.

What changed my mind

The problem stopped being a complaint and became a specification.

Can you answer these?

?Can you state the problem in one sentence, without naming a solution?
?Do you know who is holding the screen when your product is used?

Chapter 02

Modelling the method before the screens

Track 1 · My journey

The first real work was not a page, it was a schema. Kent's rubrics, remedies by kingdom, the grade a remedy carries for a rubric, the symptoms attached to a case, the aggregated result. Once the method existed as tables, most screens were obvious.

Learning checkpoint

Before this chapter

A blank project and a chat window.

After this chapter

The shape of the product was decided before a single deliberate design decision was made.

What changed my mind

I learned to treat conversation as a design tool, not as preparation for design.

Can you answer these?

?What is the one sentence in your own notes that decided the architecture?
?Are you describing outcomes, or dictating implementation?

Chapter 03

Building it: Supabase, roles and Capacitor

Track 1 · My journey

Thirteen routes, including separate doctor and patient dashboards, case taking, prescriptions and medication management. Access is enforced by a user_roles table and a has_role function driving row level security, so the separation between doctor and patient is a database rule rather than a hidden button. Capacitor is configured for Android and iOS so the same build installs as a phone app. Telugu is in the schema itself — rubric text and prescription instructions both have their own language columns.

Track 2 · Learn with Deepthi

Row level security

USED — evidence shows I used it

What did I just discover?: That access control belongs in the database, where the rule cannot be bypassed by a different screen or a direct query.
What is it, really?: A database feature where policies decide, row by row, which rows a given user may see or change.
Think of it like this (analogy): A filing cabinet that only hands you your own folders, no matter who asks on your behalf.
How does it actually work?: A policy attached to the table checks the requester's identity against the row before returning it.
Why did it matter to my project?: Because a patient and a doctor using the same app must never be one bug away from each other's records.
Where I used it: Every table in the app, driven by a has_role function.
What this tool cannot do: Policies only protect what they cover. A table with security enabled and no policy simply returns nothing.

Track 2 · Learn with Deepthi

A roles table

USED — evidence shows I used it

What did I just discover?: That a user's role must live in its own table, never as a column on their profile.
What is it, really?: A separate table linking a user to one or more roles, read by a security-definer function.
Think of it like this (analogy): A staff badge issued by the building, not a name tag you write yourself.
How does it actually work?: user_roles holds user and role; has_role answers yes or no; policies call that function.
Why did it matter to my project?: Because a role stored on an editable profile row is a privilege escalation waiting to happen.
Where I used it: The user_roles table and has_role function separating doctor, patient and admin.
What this tool cannot do: It only helps if every policy actually calls it instead of trusting a value from the client.

Track 2 · Learn with Deepthi

Junction tables

USED — evidence shows I used it

What did I just discover?: That a many-to-many relationship needs a table of its own, and that the extra column on it is often the real content.
What is it, really?: A table whose rows join two other tables, optionally carrying data about the relationship.
Think of it like this (analogy): A seating plan: not a list of people or of chairs, but of which person is in which chair.
How does it actually work?: rubric_remedies holds a rubric, a remedy, and the grade the remedy carries for that rubric.
Why did it matter to my project?: Because in repertorisation the grade is the whole method — it is what gets totalled.
Where I used it: rubric_remedies and case_symptoms, which together produce the repertorisation score.
What this tool cannot do: The join table grows fast, and its extra columns need the same care as any other clinical data.

Learning checkpoint

Before this chapter

I had screens in my head and a stack I had not yet justified.

After this chapter

A working product, and a much shorter list of things I believed without evidence.

What changed my mind

The stack became a means, not an identity.

Can you answer these?

?Could you rebuild your first screen in an afternoon if you had to?
?Which tool are you using out of habit rather than fit?

Chapter 04

What broke: three ways in

Track 1 · My journey

A shared auth page and separate doctor and patient login pages all coexist, which is one entrance too many and a real source of confusion. The scoring is the other loose end: totals are modelled in the database, but the interface is still vague about the moment a repertorisation is calculated.

Learning checkpoint

Before this chapter

Something that worked in the demo and failed in real life.

After this chapter

A smaller, blunter, considerably more useful product.

What changed my mind

I stopped defending the first version and started measuring it.

Can you answer these?

?What in your build is complete but unused?
?What would you cut if you had to halve the time it takes to use?

Chapter 05

What actually changed

Track 1 · My journey

Security stopped being something I remembered to check. Putting roles in their own table and letting the database refuse the row is the first time a build of mine was safe by construction rather than by attention.

Learning checkpoint

Before this chapter

A product that worked, and no clear evidence that it mattered.

After this chapter

A clear-eyed view of what the product does and does not fix.

What changed my mind

Success stopped meaning "it is built" and started meaning "it is used".

Can you answer these?

?What behaviour changed because your product exists?
?Would anyone notice if it disappeared tomorrow?

Chapter 06

What I would tell you before you start

Track 1 · My journey

Model the method, not the pages. And never store a role on the profile row — it belongs in its own table with a function that answers the question.

Learning checkpoint

Before this chapter

You have read what happened. Here is what to take with you.

After this chapter

A method you can reuse on a completely different problem.

What changed my mind

The build became repeatable rather than lucky.

Can you answer these?

?What is your version of the short loop?
?What will you ship this week, even if it is embarrassing?

Appendix

Deepthi's Dictionary

Short loop: Describe, build, use, correct — repeated in hours rather than weeks. The core working method behind this build.
Second use: Whether someone opens the product a second time without being asked. The simplest honest measure of whether it works.
Conversation beat: A single line in a build conversation that changed a decision. Collected, these form the real design document.
Worst day design: Designing for the tired, rushed, distracted user rather than the ideal one in a demo.
Lovable: Lovable — part of the stack used to build doctor-buddy-app.
React: React — part of the stack used to build doctor-buddy-app.