How I built a small private web app to organize personal medical studies, upload PDFs and images, and share temporary access during doctor visits.
Mi Salud started with a very normal family problem: medical studies were everywhere.
Some PDFs were in email threads. Some images were in WhatsApp chats. Some files were downloaded on one phone but not another. A lab result might be in a folder, a screenshot, or buried under a forwarded message from months ago.
It was not a dramatic technical problem. It was just annoying, repetitive, and easy to get wrong when someone actually needed the file.
I built Mi Salud for my wife and my family as a private place to organize personal medical studies and make them easier to find when we needed them.
The app is live at:
https://salud.antonellamaino.com.ar
Doctor visits often come with a small scramble:
None of this needs a big platform. For our case, we just needed a simple web app where we could upload files, see a history, download them again, and temporarily share a study during a visit.
I did not want to build a medical record system. I did not want diagnosis features, OCR, AI summaries, or anything pretending to understand the medical content. The goal was much smaller: store personal files in a way that was easier to manage than a mix of chats, email attachments, and local downloads.
Mi Salud is a responsive web app with email and password login.
Once logged in, a user can upload private PDF or image files related to medical studies. The app keeps them in a history list, so they can be found again later without digging through old conversations.
Each uploaded file can be downloaded only through authenticated access. That was important to me: the app should not just expose files through public URLs.
There is also a temporary sharing feature. For doctor visits, the app can generate a share link and QR code that lasts 24 hours. The idea is practical: if you are sitting in a waiting room or in front of a doctor, you can open the app, pick the study, and share access without sending the file permanently through another channel.
After 24 hours, that temporary access expires.
That feature is probably the most “real life” part of the app. It exists because medical appointments are not always organized moments. Sometimes you need to show something quickly from your phone, and a QR code is easier than searching, downloading, forwarding, and hoping the other person can open the attachment.
One of the main decisions was what not to build.
Mi Salud does not try to interpret medical studies. It does not extract text from files. It does not provide recommendations. It is not a replacement for a hospital system, a clinic portal, or a professional medical record.
It is just a private file organizer for personal use.
That constraint helped keep the product honest and the code simpler. A lot of software becomes complicated because it tries to sound more important than it is. In this case, the value was in being boring and reliable: log in, upload a PDF, find it later, share it temporarily if needed.
The backend is built with Node and Express.
For storage, I used SQLite. For this kind of app, SQLite is a good fit: simple to deploy, easy to back up, and more than enough for a small private system. I did not need a separate database server or a more complex setup just to manage a family’s documents.
The app runs in Docker on a VPS. nginx sits in front of it, and Let’s Encrypt handles HTTPS certificates.
The deployment is intentionally standard:
There is nothing exotic in the infrastructure, and that is the point. I wanted something I could understand, maintain, restart, inspect, and move if needed.
Even though Mi Salud is a web app, I thought about it mostly as something that would be used from a phone.
That affected the interface. The upload flow needed to work on mobile. The history list needed to be readable on a small screen. Downloads and sharing needed to be reachable without too many taps.
A medical study organizer that only works comfortably from a laptop would not solve the real problem. Most of the time, the person looking for the file is not sitting at a desk. They are at home, at a clinic, in a waiting room, or trying to help someone else from their phone.
So the responsive part was not a nice extra. It was part of the core use case.
There are many ways to store documents: cloud drives, email labels, messaging apps, shared folders.
But none of those matched exactly how we were using these files. I wanted a dedicated place, with a very small set of actions, that did not mix medical studies with every other kind of document.
I also wanted control over the tradeoffs. For example, the 24-hour temporary share link is not something I wanted to improvise manually every time. It made sense as a first-class feature because it matched a real situation we had.
Building it myself let me make the app specific without making it big.
The main lesson was not technical. It was about building software close to an actual need.
When the user is someone in your own family, there is less room for fake product thinking. You see the awkward parts immediately. You notice when a button is too hidden, when a flow takes too long, or when a feature sounds good but nobody needs it.
Mi Salud reminded me that useful software does not always need to be ambitious. Sometimes it just needs to remove a recurring annoyance from everyday life.
For me, this project sits in that category: small, personal, practical, and built around a real workflow.