I'm launching my project, Paindai, a pain journaling app that helps people track and share their chronic pain symptoms with doctors, on ProductHunt this Saturday. This app is more than just a technical project; it’s a personal journey inspired by watching my fiancée struggle with chronic pain over the last few years. Here, I’ll share the story behind Paindai, its technical stack (Ruby on Rails, HTMX, Ubuntu, and AWS), and why I believe it’s a product with potential to help others in similar situations.
Why Build Paindai? The Challenge of Chronic Pain
My fiancée has been dealing with chronic pain for years, experiencing everything from aching joints and muscles to intense back pain that often required pain gel just to get through the day. Chronic pain is notoriously hard to pin down, and for her, symptoms shifted often and unpredictably. Recently, after years of advocating and navigating the healthcare system, she finally got a diagnosis of a CSF (cerebrospinal fluid) leak and deteriorating spinal discs. Having a clear answer was a relief, but the path to that diagnosis was exhausting and frustrating, especially when her pain symptoms varied day to day.
Many patients, particularly women, struggle with having their pain taken seriously. Studies have shown that women’s pain is often downplayed, leading to delayed diagnoses and inadequate treatment. Watching her experience this inspired me to develop Paindai—a tool that could help anyone struggling to communicate the complexity of their pain.
Enter Paindai: How It Works
Paindai is a Rails-based journaling app that lets users log pain events as they happen. It allows users to record not only the intensity and location of their pain but also time, context, and other relevant details. Over time, Paindai gives users a complete history of their pain, which they can share with doctors, making it easier to track patterns, identify triggers, and improve their medical care.
With chronic pain, data is power. Having detailed records helps people advocate for themselves, providing hard evidence for patterns and severity that might otherwise be lost. The app is free to use, though I also have a paid version to support hosting and development costs, as well as to support future feature additions, including AI-powered insights for potential diagnoses and treatment recommendations.
The Tech Stack: Rails, HTMX, and Full-Stack Development
Building Paindai meant combining a stable, versatile back-end with a front-end that could support dynamic, interactive logging without requiring a massive framework. Rails was the natural choice for a backend with strong data handling capabilities and easy integration with the various tools Paindai needed.
Ruby on Rails
Having used Ruby on Rails for over a decade, I knew I could leverage its strengths in structuring a clean, maintainable app. Paindai is built with a standard Rails setup but leans heavily into customization to suit the unique requirements of chronic pain tracking. For example, I wanted to make it easy for users to add a new pain entry without reloading the page, a feature that can get clunky if not handled well.
HTMX for Interactive Pain Tracking
For the front end, I chose to use HTMX, which allowed me to inject interactivity into the app without the need for a heavyweight framework like React or Vue. HTMX lets you use simple HTML attributes to load content dynamically, and it was a perfect fit for Paindai’s pain logging feature. By using HTMX, I could create an experience where users can add or update pain entries seamlessly, without page reloads.
Using HTMX with Rails, I could manage form submission and data updates on the back end while delivering a smooth, single-page experience on the front end. It also allowed me to keep the codebase lean and avoid the overhead of managing a large client-side JavaScript framework, which I wanted to avoid for the sake of simplicity and maintainability.
Deployment on Ubuntu and AWS
Paindai is hosted on AWS, with an Ubuntu instance providing a reliable environment for Rails and background job processing with Delayed Job. The choice of Ubuntu made sense for its familiarity and robust support for server-side Rails applications, and AWS was ideal for its scalability and reliable infrastructure.
Deploying Paindai on AWS was a straightforward process thanks to its flexible server setup. I’m using Nginx as a web server and PostgreSQL for the database, which is well-suited for handling the relational data that comes with tracking pain over time. I set up SSL with manual DNS configuration, as I prefer to have control over my domain without installing unnecessary dependencies.
Background Jobs and Notifications
For background processing, I’m using Delayed Job rather than Sidekiq, as it integrates smoothly with the rest of the Rails stack and is more lightweight for my current needs. I implemented background jobs to handle data-intensive tasks, such as generating user reports or preparing insights based on pain entries.
One feature in progress is a notification system that will remind users to log their pain if they haven’t for a few days, or even provide encouragement if they’ve logged frequently. This is intended to improve user engagement and create a helpful feedback loop for people managing their chronic pain.
Building AI-Driven Insights
One of Paindai’s future goals is to incorporate AI-driven insights. In our experience, having even a rough sense of which specialists to consult based on symptoms was incredibly valuable, and I’d like to make that feature available to Paindai users. The AI functionality I envision will analyze users' pain entries and offer suggestions on what kinds of doctors or treatments they might consider, based on common correlations or existing research.
This is where Ruby and Rails come in handy once again. Rails’ Active Record makes it simple to handle structured data, and by converting pain logs to JSON format, I can prepare this data for AI analysis without overcomplicating the database schema. Once this feature is fully built out, I hope it can give users a proactive tool in managing their care.
Launching on ProductHunt and Building an Audience
ProductHunt has become the go-to for launching Paindai. I’m hoping that the community there will see the value in what Paindai is doing. In preparation, I’ve been promoting it everywhere I can—on Dev.to, Medium, Twitter, and through blogging. For anyone who’s launched on ProductHunt before, I’d love to hear what strategies worked best for you. Did Twitter drives make a difference? Did a particular blog post take off?
Looking Ahead: Why Paindai Matters
Paindai isn’t just a tech project; it’s a tool to help people manage an overwhelming part of their lives. Chronic pain affects millions and can be incredibly isolating. It’s easy to feel overlooked in a healthcare system that doesn’t always validate subjective pain. With Paindai, my hope is to give people a tool to be better advocates for themselves. Tracking pain may seem simple, but it has profound benefits for health outcomes. It empowers patients to take control, communicate clearly, and potentially unlock treatments they didn’t even realize were an option.
If you or someone you know could benefit from a tool like Paindai, I invite you to check it out on ProductHunt or visit Paindai.com.
Top comments (1)
I'm curious - why did you choose HTMX over Hotwire?
Also, do you have mobile app/pwa? or plans for?
Also, I'm curious about the encryption that's mentioned on web. I would be very happy to read about how to get that into the app, if you would plan on writing some more :)
I'm happy to see any new projects based in real life problems, so good luck with this!