DEV Community: EmoPulse

As a solo founder, I've learned that monitoring my team's wellness is crucial. But what if I told yo

EmoPulse — Thu, 14 May 2026 10:00:02 +0000

As a solo founder, I've learned that monitoring my team's wellness is crucial. But what if I told you we can do it without wearables? Follow @emopulseai on Telegram for daily AI insights -> t.me/emopulseai

rPPG chaos: a noisy signal's unexpected role

EmoPulse — Fri, 01 May 2026 11:38:47 +0000

Earlier this week, I found myself staring at a noisy heart rate signal, wondering how it could possibly be useful. As the sole founder and engineer of EmoPulse, I've grown accustomed to dealing with imperfect data, but this particular signal seemed like a lost cause. And yet, as I delved deeper into the issue, I stumbled upon an unexpected insight: this noisy signal could become our anti-spoof primitive.

The underlying lesson here is that sometimes, the things that seem like flaws or imperfections can actually become our greatest strengths. In the case of our remote photoplethysmography (rPPG) implementation, the noise and variability of the heart rate signal made it seem like a poor candidate for any serious application. However, as we began to explore its properties, we realized that this very noise could be used to detect spoofing attempts. It's a counter-intuitive observation, to say the least: the thing that makes our signal imperfect is also what makes it secure.

Our custom rPPG implementation, which extracts heart rate from face color changes, is just one part of our broader behavioral perception infrastructure layer. We use MediaPipe's 478 facial landmarks and 52 ARKit blendshapes to extract 47 biometric and behavioral signals from any standard RGB camera, all on-device in the browser via WebAssembly. The output is a structured state vector posted to a Flask /state endpoint on our server, which runs on a $0/month Oracle ARM box in Chicago. As we worked to develop our liveness scoring system, we discovered that the rPPG signal's noise could be used to detect anomalies in the data. Specifically, we found that a BPM standard deviation above 12 BPM, combined with other penalty signals like gaze stability and micro-expression count, could be used to identify spoofing attempts with remarkable accuracy.

This insight has significant implications for our journey at EmoPulse. As we continue to develop and refine our technology, we're forced to confront the trade-offs between security, accuracy, and usability. Our liveness scoring system, which runs on the server-side and uses a sliding window of the last 5 ticks per session, is just one example of how we're working to balance these competing demands. As we move forward, we'll need to continue exploring the properties of our signals and finding creative ways to leverage their imperfections.

What will be the next unexpected benefit to arise from our imperfect signals, and how will it change the course of our development?

Building a 5-layer ontological perception engine alone

EmoPulse — Fri, 01 May 2026 11:38:46 +0000

Earlier this week, I found myself staring at a wall of code, wondering how I ended up building a 5-layer ontological perception engine by myself. It was a moment of exhaustion, but also a moment of clarity. I realized that the hardest part of building EmoPulse wasn't the technology itself, but the solitude of making decisions without a team to bounce ideas off of.

As I reflected on the past year, I noticed a pattern. Every time I thought I had made a breakthrough, I would soon realize that it was just a small step in a much larger journey. The stress classification path, for example, implements published peer-reviewed methodology from Giannakakis et al., which reports 93 to 96 percent accuracy on cohorts of N=48 to 58. But what does that really mean? It means that I have to trust the research, trust my implementation, and trust that it will work in the real world. It's a heavy burden to carry alone.

The technical reality of building EmoPulse is daunting. I've had to extract 47 biometric and behavioral signals from any standard RGB camera, all on-device in the browser via WebAssembly. The output is a structured state vector posted to a Flask /state endpoint on the server, with sub-50ms end-to-end latency from frame capture to state vector emission. It's a complex system, and one that requires a deep understanding of the underlying technology. I've had to rely on tools like MediaPipe and custom rPPG implementation to get the job done.

As I look back on the past year, I realize that building EmoPulse has been a journey of continuous learning. Every decision I make has a ripple effect, and every problem I solve reveals a new set of challenges. The liveness scoring system, for example, was a recent addition, shipped on 2026-04-08. It's a server-side anti-spoof scorer that runs on signals already in the /state payload, with a sliding window of last 5 ticks per session. It's a complex system, and one that requires careful consideration of the potential risks and benefits.

The journey of building EmoPulse is far from over. In fact, it's just beginning. As I move forward, I'm forced to confront the reality of my own limitations. I have to be careful not to overpromise and underdeliver, and I have to be willing to adapt to changing circumstances. The pre-seed round of EUR 2 million at EUR 6 million pre-money is just the beginning, and I know that the real challenge lies ahead. What will I learn next, and how will it change the course of EmoPulse?