A personal story
Why I built HeartScan
An uncertain night, an unlikely experiment,
and a reason to keep going.
HeartScan began with something I could feel but could not easily explain: an unfamiliar beat, a pause, then a stronger thump in my chest. By the time I reached a doctor, it could be gone. The examination would capture that moment, not the one that had worried me.
I did not set out to build a medical technology company. I was a physicist by education, an entrepreneur by experience, and someone with a personal reason to be curious about his own heart. This is how that curiosity became a project, and why I am still working on it.
The night I could not explain
I had been aware of my heart since childhood. My pulse was relatively slow, and routine examinations sometimes led to another ECG. I was also diagnosed with mitral valve prolapse as a child. Neither stopped me from living a normal life, but my heart was never quite something I could forget about.
Years later, while running a business in Belarus, I went through a difficult separation from a business partner. It was a period of severe stress. Around that time, I began noticing strange sensations in my chest. My grandfather had died of heart disease at 57, so those sensations were not easy to dismiss.
One night I woke at perhaps two or three in the morning. We lived outside the city. I lay there trying to decide how worried to be, then drove to the emergency department alone, not wanting to wake my wife and children. I expected to be admitted. Instead, an ECG looked normal. By then, my heart had settled down.
I went home with much the same uncertainty. A later appointment with a patient cardiologist helped, and the episodes subsided. What stayed with me was the difficulty of describing something intermittent: I knew how it had felt, but had no recording of that moment to show anyone.
Starting again in Poland
My degree is in physics, with a specialization in radiophysics. Programming had interested me since school, when friends and I competed over efficient machine code and tried to understand disassembled programs. At university I wrote software for laboratory assignments. But I did not go on to become a professional software engineer.
Instead, I built a business in computer repair, hardware sales, and e-commerce. I spent years dealing with customers, suppliers, employees, and all the practical problems that do not appear in a programming exercise.
After the political events in Belarus in 2020, I had to leave the country. My family and I moved to Warsaw. Starting again in Poland meant finding a new professional direction as well as rebuilding everyday life. During another stressful period, familiar heart sensations returned, then eventually subsided again.
I was becoming interested in machine learning and sensor data. One project involved vibration diagnostics for machinery: record the movement of an engine or mechanical component, then look for information in the signal. It brought together the physics and programming I had always enjoyed. I did not yet realize how personal that line of work would become.
A phone in a sauna relaxation room
The connection came while I was lying in a sauna relaxation room. I felt those familiar irregular thumps again, and I had a smartphone in my hands. I wondered whether the vibration-analysis prototype I was developing could record anything from my chest.
From an engineering point of view, a heart is a pump, although a far more complicated one than that description suggests. It contracts, moves blood, and transmits tiny movements into the surrounding body. A phone already contains an accelerometer, the sensor that detects movement and orientation. Perhaps the two could meet.
I started recording and looking at the data in MATLAB. Repeating structures appeared in the signal. I could begin to separate individual heartbeat cycles and examine the unusual beats I had felt. Seeing a physical sensation represented as data was fascinating. Something that had been difficult to describe was now something I could look at.
For a brief, enthusiastic moment, I thought I might have discovered something new. In my original account, I joked about an invitation to meet the Queen, or perhaps a Nobel Prize. Then I read the scientific literature. Naturally, other people had been working on this long before me.
A discovery, just not mine
The method is called seismocardiography, or SCG: recording the small mechanical vibrations of the chest produced by heart activity. An ECG records electrical activity; SCG records mechanical movement. Learning that distinction gave me a name for what I was seeing, and a much larger body of work to learn from.
Finding an existing field did not make the experiment less interesting. It made it more interesting. There were researchers asking serious questions about these signals, and practical difficulties that had kept the technique from becoming an everyday tool. Smartphones offered a way to investigate it with hardware people already owned.
But one clean recording from my own chest was not enough. A different phone, a different position, breathing, or a small movement could change the waveform. I needed recordings from other people, not just more time looking at my own signal. The first goal was to collect a thousand recordings for research.
I contacted cardiologists and cardiac surgeons I knew, read papers, and tried to understand which questions were worth asking. My physics background helped me work with signals. It did not make me a doctor. The more I learned about the heart, the less adequate my simple pump analogy became.
The prototype was not beautiful
I chose Flutter so we could build for Android and iOS without two entirely separate codebases. I had never built a mobile application professionally. Trying to keep costs down, I hired inexpensive freelancers and sometimes assigned the same small task to several candidates. I thought I was reducing risk. In practice, I created more work for myself.
The first prototype was full of bugs. I spent enormous amounts of time testing builds, reporting problems, and testing again. Replacing the main developer with someone more experienced cost more per hour but saved time. An early attempt to delegate the data science also taught me that I did not yet understand the problem well enough to define the work properly.
In the end, I wrote much of the original signal processing in MATLAB and handed over working algorithms for implementation. Meanwhile, I spent too long refining screens and discussing design. I wanted the first version to feel finished when I should have been learning from people using it.
Getting through Apple's review took approximately six months of correspondence and calls. There was no single breakthrough that turned the experiment into a product, just a succession of problems I had not known to anticipate. Almost nothing followed my original plan.
Then people made it their own
When we finally launched, I was still thinking mainly about collecting research recordings. Then people began returning to the application for their own reasons. Some wanted to check their heart rate. Some saved measurements and compared recordings. Others were simply curious to see a visual representation of their heart's mechanical activity.
That changed the project for me. The application was no longer only a way to gather data for an engineering problem. It was something people had chosen to make part of their lives. Their questions and feedback helped us improve the recording process and make the visualizations easier to understand.
Saved measurements and PDF reports mattered because information could leave the app. People told us they used reports to help describe their experiences in conversations with doctors. Having once struggled to explain my own sensations, I understood why keeping a record could matter to someone. Those accounts were meaningful to me without being evidence of a medical result.
I still enjoy the technical work, but a waveform is no longer just an interesting pattern on my screen. There is a person behind it. Remembering that changes how I think about both the useful things we can build and the conclusions we must not draw.
Useful should not mean out of reach
We learned about a pilot involving a charity working with children in remote communities in Senegal. The interest there was not in elaborate analysis. It was in a practical way to measure pulse with a phone already available. That stayed with me after so much time spent thinking about algorithms and difficult signals.
The pilot did not establish clinical effectiveness. What it changed was my sense of who might find a basic measurement useful. A feature that seems ordinary in one setting can matter differently somewhere else. Accessibility stopped being an abstract product principle and became a more personal reason to keep working.
That same motivation influenced language support and, later, browser-based measurement. Someone who wants to check their pulse may not want to install an application first. Reducing that barrier is worthwhile in itself, even though browser support and recording conditions still limit what is possible.
HeartScan is a business, and engineering, infrastructure, and research all cost money. I want it to be sustainable. But I do not want every decision to begin and end with which audience can pay the most. Making something useful available more widely is part of the point of building it.
What I am still working toward
Today, the distance between an interesting signal and a reliable medical conclusion is much clearer to me. HeartScan can record mechanical signals and estimate heart rate under suitable conditions. It does not diagnose illness, replace an ECG or a clinical assessment, or provide emergency monitoring. A reassuring-looking recording cannot tell someone that everything is fine.
Recordings shared for research with consent help us investigate signal quality and heartbeat detection. But a collection of waveforms is not automatically a clinical dataset. To answer medical questions, we need independently established reference measurements, appropriate protocols, research partners, and independent validation. More software cannot substitute for that work.
I want to keep pursuing it, and to make the field easier for others to explore too. That is part of the motivation behind OpenSCG, our open research initiative. Knowledge and tools in this area should not depend on one company's product. There is room to build a business and contribute to a wider scientific effort.
I sometimes say I want to do some irreparable good to the world. It is a joke, but it is close to what I mean. I still think about that uncertain night, and about the unexpected path from a sauna experiment to people finding their own uses for something we built. I cannot promise where the research will lead. I am glad to be doing it, and grateful to everyone who has helped it become more than my own experiment.