🌈 Looking for help if possible: I’m Stuck on My TrackMyHRT App (Medication + Symptom Tracker)

Hey devs — I’m working on a small, offline, privacy‑first desktop app called TrackMyHRT, and I’ve hit a point where I could really use some outside perspective.

TrackMyHRT is part of a larger vision, but right now I’m focusing on this one tool: a simple, calm interface for logging HRT doses, symptoms, mood, energy, libido, and notes, with local‑only storage and export options. It’s meant to help people understand their patterns and advocate for themselves without giving their data to a cloud service.

The core features work, but I’m stuck on the next steps.

🔧 Where I’m stuck (TrackMyHRT‑specific)

1. Data model decisions

I’m unsure whether to:

keep the current JSON structure as‑is

refactor into something more future‑proof

or split entries into smaller components (meds, symptoms, metadata)

I don’t want to over‑engineer, but I also don’t want to put myself into a corner.

1. UI flow + structure

The current UI works, but I’m struggling with:

how to make the entry form feel smoother and less “form‑heavy”

whether the viewer should stay simple or become more detailed

how to keep everything accessible without clutter

I want it to feel calm and low‑pressure, not like filling out a medical form.

1. Export formats + long‑term planning

Right now I support .jsonl, .json, .txt, and .md.I’m unsure whether:

this is too many

I should standardize around one

or I should add a more structured export for future integrations

1. Migration logic

I have a small migration step for older JSONL → JSON storage.I’m not sure if I should:

keep supporting legacy formats

or simplify and drop old versions entirely

💬 What I’m looking for

Advice on structuring small but extensible data models

Thoughts on designing a calm, accessible UI for daily logging

Opinions on export formats and long‑term maintainability

Examples of similar trackers or patterns I could learn from

General “here’s how I’d approach this” insight

below is the github repo for the HRT Journey Tracker Suite where the TrackMyHRT tool is located
TrackMyHRT👈

I’m not looking for someone to rewrite the app — just some guidance from people who’ve built trackers, logging tools, or small desktop apps before.

TrackMyHRT is meant to support people navigating hormone therapy in a private, offline, non‑judgmental way. No accounts, no cloud sync, no analytics — just a simple tool that helps people understand their own journey.

I want to build this thoughtfully, but right now I’m too stuck in my head to see the next steps.

If you have experience with python, PySide6, data modeling, UX for logging tools, or just strong opinions about app structure, I’d love to hear from you.

Thanks for reading — and thanks in advance for any guidance.

Comments

[EmberNoGlow]

1. Code refactoring is an underrated and essential part of the workflow. Never be afraid to change something in your code, even if it breaks. Even if you add something that doesn't work, you've still created something new, not just tried to tweak incomprehensible code. This is already a great achievement. It's better to have buggy, yet beautifully written, functionality than to have well-functioning, but poorly written, code that's difficult to extend. Clean code is easier to extend and fix.

2. The data export format isn't the most important thing, in my opinion, whether it's written in JSON, YAML, or TXT. The most important thing is, again, ease of access to the data and good readability for checking for bugs and bottlenecks. It's better to use one format, but one that's well-supported.

3. Looking for compatibility with previous versions (if the current version has changed significantly) can backfire in the future, as you'll still have to migrate to new structures, as supporting the old format limits your functionality.

4. Clearly define your goals. Create a roadmap and development documents. Defining goals on the fly - "What if I add this small feature?" - is a bad idea, as the project can turn into a sandbox with a multitude of ideas that may be completely unrelated.

5. Don't be afraid to use AI! In my experience, while developing my project, I used AI for everything from refactoring to adding features, and even my training (you can read my post about this). My project was constantly changing and breaking, then fixing, or even completely changing the architecture.

Don't be afraid to experiment and refactor, as it's part of the process. Good luck!

[codebunny20]

Thank you so much