Deepthi's Reading

Quality

047

The clabsi-risk-radar Story

From manual audits to digital excellence

Lovable · React · Recharts · TanStack Query

Edition #047 · 6 chapters · 6 min read

The clabsi-risk-radar Story

From manual audits to digital excellence

A CLABSI audit workflow showing the transformation from paper to real-time monitoring.

An ebook edition of the clabsi-risk-radar 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, Charts.

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 Charts 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
•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 CLABSI Risk Radar had to exist

Track 1 · My journey

Moving central line audits off paper needed a case, and the case needed numbers rather than conviction. This build exists to make that argument visible in one sitting.

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

Choosing persuasion over collection

Track 1 · My journey

I asked for the manual workflow and the digital workflow drawn beside each other, and for the money to be in the picture. That decision set the whole architecture: it presents, it does not gather.

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: React, Recharts and a magazine layout

Track 1 · My journey

Two real screens came out of it — a dashboard of workflow comparisons and insights, and a long-form article, Predict, Prevent, Protect, carrying the methodology. Survey and compliance figures are hardcoded constants inside the components. The financial model works from a published per-infection cost of roughly twenty-five to forty-five thousand dollars.

Track 2 · Learn with Deepthi

Pareto analysis

USED — evidence shows I used it

What did I just discover?: That failures cluster — a small number of causes produce most of the non-compliance.
What is it, really?: A chart ordering causes by frequency so the largest contributors sit first.
Think of it like this (analogy): Fixing the two taps that leak, not surveying every tap in the building.
How does it actually work?: Count occurrences per cause, sort descending, plot bars with a cumulative line.
Why did it matter to my project?: Because improvement effort is finite and should go where the volume is.
Where I used it: The compliance failure breakdown in the dashboard.
What this tool cannot do: Frequency is not severity. The rarest failure can still be the most harmful.

Track 2 · Learn with Deepthi

Cost-benefit modelling

USED — evidence shows I used it

What did I just discover?: That a clinical argument travels much further once it carries a number.
What is it, really?: An estimate placing the cost of the current state against the cost of the change.
Think of it like this (analogy): Comparing a repair bill with the cost of the damage you keep paying for.
How does it actually work?: Take a published per-case cost, multiply by expected cases avoided, subtract the cost of the intervention.
Why did it matter to my project?: Because the people who approve a change are usually not the people doing the audit.
Where I used it: The financial impact section, built on a published per-infection cost range.
What this tool cannot do: The model is only as good as its assumptions, and every figure here is a hardcoded constant.

Track 2 · Learn with Deepthi

Hardcoded constants

USED — evidence shows I used it

What did I just discover?: That data written directly into components is fine for an argument and disqualifying for a system.
What is it, really?: Values fixed in the source code rather than loaded from a database or a file.
Think of it like this (analogy): Numbers printed on a poster. Accurate on the day it was printed.
How does it actually work?: The component declares the array of figures and renders straight from it.
Why did it matter to my project?: Because knowing which of your builds contain them tells you which ones can be called live.
Where I used it: surveyData and complianceData inside the dashboard and article components.
What this tool cannot do: Nothing updates without a code change, and no one can tell from the screen how old a number is.

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

The mislabel I had to correct

Track 1 · My journey

I had been calling this a dashboard. Reading the code back, there is no persistence and no data entry anywhere in it, so it is a research presentation with charts. Correcting my own description was the most useful thing that happened in this project.

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 argument became portable. A cost-benefit case you can hand someone as a link is a different object from a slide deck you have to present.

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

Decide whether you are building an argument or a system. Both are legitimate. Confusing the two is how a demo quietly becomes a promise.

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 clabsi-risk-radar.
React: React — part of the stack used to build clabsi-risk-radar.
Charts: Charts — part of the stack used to build clabsi-risk-radar.