Social products · 2 min read
Quit Together
Quit Together combines a personal progress dashboard with a social space. The product includes daily check-ins, community posts, comments, support reactions, and follow recommendations. Its backend gives PostgreSQL and Neo4j distinct responsibilities.
- My role
- Personal project
- Project scope
- Application implementation · private source
The main responsibilities in this workflow.
- Check-ins and community actions
- Go application
- PostgreSQL records
- Neo4j follow graph
- Progress and recommendation views
A lapse should not erase the whole journey
The progress model distinguishes the overall journey from the current smoke-free streak. A later smoking event can change the streak without pretending that all earlier effort disappeared. The calculation also accounts for reported cigarettes smoked when estimating cigarettes avoided and money saved.
The domain code clamps negative quantities and handles a quit date in the future. These are small details with a visible product effect: a dashboard should not display nonsensical negative progress because an input or date boundary is unusual.
The social layer has its own data model
Community features include image posts, comments, support reactions, and authenticated views. Follow relationships and recommendations live in Neo4j, while PostgreSQL provides application persistence for the other workflows.
The graph uses relationship operations for following and unfollowing, and supplies follower/following information to the product. This is a concrete reason to explore graph storage: relationship traversal and recommendations are different access patterns from recording a daily check-in.
Keep domain logic inspectable
Progress calculations are separated into domain code, with tests around statistics and social behavior. Session and password helpers have their own checks. This organization makes it possible to reason about an arithmetic or state rule without rendering the whole application.
Using two databases also creates an operational cost. Each store has a lifecycle, failure behavior, and consistency boundary. The portfolio describes that architecture without claiming a distributed transaction across the two systems.
A product experiment, not a health-outcome claim
The dashboard, calendar, community, and achievements make the application broader than a simple day counter. The interesting design work is in connecting personal progress to supportive interactions without collapsing the two into one metric.
The calculations are estimates based on user inputs. I do not claim clinical effectiveness, a measured cessation rate, or verified user-growth figures. This is a personal software product demonstrating Go, data modeling, and social features.
Project notes
Private source. Estimates are user-input based; no clinical efficacy or user-growth claim.