Deepthi's Reading

Clinical

004

The Patient Symptom Tracking App Story

Helping patients notice, document and communicate what they feel

Lovable · React · TypeScript · Figma

Edition #004 · 6 chapters · 15 min read

Free sample edition

The Patient Symptom Tracking App Story

Helping patients notice, document and communicate what they feel

Patients often forget or struggle to describe what happened between visits. This is a way for people to capture symptoms as they occur, organise them over time, and walk into an appointment with something clear to show. Part of the Third Eye Vitals family of patient-safety products.

An ebook edition of the Patient Symptom Tracking 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, TypeScript, Figma, ChatGPT, PWA.

Free to read — no payment neededStart 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 Figma really is, and what it cannot do
•what Lovable really is, and what it cannot do
•what React really is, and what it cannot do
•what TypeScript 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 Patient Symptom Tracking App had to exist

Track 1 · My journey

Patients kept forgetting what happened between visits, and clinicians kept guessing. I wanted the patient to hold the record. Patients often forget or struggle to describe what happened between visits. This is a way for people to capture symptoms as they occur, organise them over time, and walk into an appointment with something clear to show. Part of the Third Eye Vitals family of patient-safety products. The honest test I set myself was simple: if this existed tomorrow, would anyone actually open it twice? Everything in the rest of this book is downstream of that one question. Patient Symptom Tracking App is what came out the other side.

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

The first conversation

Track 1 · My journey

I did not start with code. I started by describing the thing out loud, in ordinary language, the way I would explain it to a colleague. The build tool answered with a working screen, and that changed the conversation from theory to critique — it is much easier to say what is wrong with something in front of you than to specify it from nothing. These were the exchanges that actually moved the build: Me: "It must work on a cheap phone with bad internet." → That single sentence decided the whole architecture. Me: "Fewer fields." → Every removed field increased the chance the entry actually gets made. Me: "What if they log a red-flag symptom?" → The app stopped being a diary and started being a safety net. Each of those lines looks small. Together they are the design document. I have stopped writing long specifications; the transcript is the specification.

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: Lovable, React, TypeScript, Figma, ChatGPT, PWA

Track 1 · My journey

I sketched the screens in Figma first — what a tired patient could tap with one thumb. Then I described those screens to Lovable and got a working app instead of a picture. Making it a PWA meant it installed on a phone with no app store in the way, which matters enormously in the settings I work in. The build kept forcing clinical questions on me: how many symptoms before the list is overwhelming, what counts as a red flag, when do you tell someone to seek help instead of logging another entry. The stack was Lovable, React, TypeScript, Figma, ChatGPT, PWA. I did not choose it for elegance; I chose it because it let me get a real, usable thing in front of a real person quickly, and because I could change my mind cheaply when the first idea turned out to be wrong. The rhythm mattered more than the tooling. Ship something small, use it honestly, fix the one thing that hurt most, repeat. Most of the good decisions in Patient Symptom Tracking App came from that loop rather than from planning.

Track 2 · Learn with Deepthi

Lovable

USED — evidence shows I used it

What did I just discover?: That Lovable was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: Lovable is a web tool where you describe an app in plain language and it writes and runs the real code for you, in a browser.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: You write a request. An AI model reads your project files, decides which files to change, writes the change, and the preview reloads with the new version.
A little deeper (optional): Under the hood it is a normal codebase (React front end, a database, server functions). The AI is an editor of that codebase; nothing magical is added at runtime.
Why does this exist?: Building a working web app normally needs setup, hosting and code knowledge. Lovable exists to remove that setup so the idea can be tested first.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Patient Symptom Tracking App, especially while getting the first working screens in front of people.
Common beginner misunderstanding: Beginners think the AI "understands the whole app perfectly". It only sees the context it is given, which is why clear, specific instructions change the quality of the result.
What this tool cannot do: It cannot know what you did not tell it, it cannot judge whether your product idea is good, and it can confidently make a wrong change that still builds.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

Reads the request and the existing code, then proposes and writes specific file edits.

What the tool is doing

Stores the files, runs the build, serves the live preview and connects the database.

What I am doing

Decides what the product should do, judges whether the result is right, and corrects it when it is not.

What data is moving where?

1.Me: I describe the change
2.AI: reads project files and writes edits
3.Tool: builds and deploys the preview
4.Me: I look at the result and correct it

What is happening right now?

Deepthi writes an instruction

AI model reads the project files

AI writes file changes

Build system rebuilds the app

Preview reloads

Deepthi reviews and corrects

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with Lovable and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Track 2 · Learn with Deepthi

React

USED — evidence shows I used it

What did I just discover?: That React was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: React is a way of building web pages out of small reusable pieces called components, where the screen updates automatically when the data changes.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: You describe what the screen should look like for a given state. When the state changes, React works out the smallest set of changes and applies them to the page.
A little deeper (optional): React keeps a lightweight in-memory description of the UI, compares the new one with the old one and updates only the differences in the browser document.
Why does this exist?: Before it, keeping the screen in sync with changing data meant manually updating page elements — slow and error-prone. React exists to make the screen a function of the data.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Patient Symptom Tracking App, especially while getting the first working screens in front of people.
Common beginner misunderstanding: People assume React is a whole app framework. It is only the interface layer — routing, data and security are separate concerns.
What this tool cannot do: React only draws the interface. It does not store your data, secure it, or talk to a database on its own.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

Writes and rearranges these components on request.

What the tool is doing

Renders the components in the browser and re-renders them when data changes.

What I am doing

Decides what the user should see and in what order.

What data is moving where?

1.Data changes
2.React re-renders the affected components
3.The browser shows the update

What is happening right now?

State changes

React compares old and new UI

Only the differences are applied to the page

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with React and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Track 2 · Learn with Deepthi

TypeScript

EXPLORED — I researched or discussed it

What did I just discover?: That TypeScript was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: TypeScript is one of the pieces this build rests on — it is worth understanding what it makes cheap and what it makes hard before you commit to it.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: In simple terms: I give TypeScript an input, it does one well-defined job with it, and it hands back a result the rest of the project can use.
Why does this exist?: TypeScript exists to solve a specific, repetitive problem so that people building things do not have to solve it again from scratch every time.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Patient Symptom Tracking App, especially while getting the first working screens in front of people.
Common beginner misunderstanding: A common beginner assumption is that adding TypeScript automatically makes a project better. A tool only helps when it matches the problem you actually have.
What this tool cannot do: TypeScript does one job well and nothing outside that job. It cannot decide what your product should be, and it will not protect you from a wrong requirement.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

The AI model reads my instruction, decides how TypeScript fits, and writes or explains the part that uses it.

What the tool is doing

TypeScript performs its own specific job — the AI does not do that work itself, it only directs it.

What I am doing

I decide whether TypeScript is the right choice, approve it, and judge whether the outcome is actually what my readers need.

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with TypeScript and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

Track 2 · Learn with Deepthi

Figma

EXPLORED — I researched or discussed it

What did I just discover?: That Figma was doing more of the work in this build than I gave it credit for.
What I thought it meant: I assumed it was a technical detail I could pick up later.
What I learned: It shaped what was easy and what was expensive, and therefore what the product became.
What is it, really?: Figma is one of the pieces this build rests on — it is worth understanding what it makes cheap and what it makes hard before you commit to it.
Think of it like this (analogy): A workshop tool: it does not decide what you make, but it strongly influences what you find yourself making.
How does it actually work?: In simple terms: I give Figma an input, it does one well-defined job with it, and it hands back a result the rest of the project can use.
Why does this exist?: Figma exists to solve a specific, repetitive problem so that people building things do not have to solve it again from scratch every time.
Why did it matter to my project?: Because the constraints of your tools quietly become the constraints of your product.
Where I used it: Used throughout Patient Symptom Tracking App, especially while getting the first working screens in front of people.
Common beginner misunderstanding: A common beginner assumption is that adding Figma automatically makes a project better. A tool only helps when it matches the problem you actually have.
What this tool cannot do: Figma does one job well and nothing outside that job. It cannot decide what your product should be, and it will not protect you from a wrong requirement.
What surprised me: How much of the design pressure came from the tool rather than from the problem.

What happens behind the scenes

What the AI is doing

The AI model reads my instruction, decides how Figma fits, and writes or explains the part that uses it.

What the tool is doing

Figma performs its own specific job — the AI does not do that work itself, it only directs it.

What I am doing

I decide whether Figma is the right choice, approve it, and judge whether the outcome is actually what my readers need.

One thing to remember

Remember this

Choose tools by what they make cheap to change, not by what they make possible.

Try it yourself

Rebuild one screen of your own project with Figma and time it honestly.

Accuracy note: product behaviour checked on 2026-08-15. General concepts are stable; product-specific behaviour can change.

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

Track 1 · My journey

The first version had too many fields and nobody would have completed it twice. I cut it down until logging took under thirty seconds. Breakage is the most useful part of the process because it is unambiguous. A feature nobody uses is a feature that failed, no matter how well it is built. So I cut, simplified, and made the default path shorter until the product stopped resisting the person using it. I keep this chapter in every book deliberately. The polished version of a build story is not useful to anyone; the failure is where the transferable lesson lives.

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

The point of Patient Symptom Tracking App was never the software. It was the change in behaviour around it: fewer things forgotten, less guessing, a clearer handover between the people involved. Helping patients notice, document and communicate what they feel What I watch for now is whether the thing gets opened a second time, without being asked. Second use is the only honest metric I have found at this scale. Everything else is a story I tell myself. The status of this build: in_progress. That is stated plainly on purpose — unfinished work teaches as much as shipped work, and pretending otherwise makes these books useless.

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

In healthcare, the feature that gets used beats the feature that is complete. Design for the worst day, not the demo. Three things I would repeat on the next build: 1. Describe the problem before naming a tool. The tool is the last decision, not the first. 2. Get something usable in front of a real person within a day. Opinions about a screenshot are worth more than opinions about a plan. 3. Keep a record of the conversation. The transcript is the design history, the documentation and — as this book proves — the product. If you take one thing from Patient Symptom Tracking App: the difference between an idea and a product is a short loop, run honestly, many times.

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 Patient Symptom Tracking App.
React: React — part of the stack used to build Patient Symptom Tracking App.
TypeScript: TypeScript — part of the stack used to build Patient Symptom Tracking App.
Figma: Figma — part of the stack used to build Patient Symptom Tracking App.
ChatGPT: ChatGPT — part of the stack used to build Patient Symptom Tracking App.
PWA: PWA — part of the stack used to build Patient Symptom Tracking App.