Back to all insights
Build Log 2026-04-29 9 min read

Building MealCircle: How I Architected a HIPAA-Compliant Nutrition SaaS for Dietitians

A first-person build log of MealCircle — the retention-first clinical nutrition SaaS I built for dietitians — covering HIPAA architecture, multi-tenant design, and key engineering decisions.

What MealCircle Is

MealCircle is a retention-first clinical nutrition SaaS I built for registered dietitians and nutrition practices. The core problem it solves: dietitians lose patients between sessions because there's no lightweight engagement layer keeping patients connected to their care plan between appointments. MealCircle is that layer — meal logging, progress tracking, and coach-patient communication, built around the clinical workflow rather than bolted on top of it.

I built it because I couldn't find a nutrition SaaS that treated retention as a first-class product priority. Most tools in the space are EHR-adjacent documentation platforms. MealCircle is a retention engine that happens to integrate with clinical documentation.

This article covers the architecture decisions I made building it — the same decisions I apply when designing custom healthcare software for Opexia clients.

The HIPAA Problem for a One-Person SaaS

Building a HIPAA-compliant SaaS as a solo founder is a different problem than building it as a team. You can't divide security work across specialties. Every decision — infrastructure, authentication, data model, third-party tools — is yours, and every one of them has compliance implications.

The baseline I set before writing application code:

  1. All PHI datastores encrypted at rest with KMS (AWS RDS + encrypted S3)
  2. All network communication TLS 1.2+ with no HTTP fallback
  3. CloudTrail enabled from day one — immutable audit logs before the first user
  4. Secrets Manager for all credentials — no environment variable API keys
  5. BAAs signed with AWS and every third-party service that could see patient data

The HIPAA engineering checklist I publish on Opexia is essentially the implementation guide I wrote for myself building MealCircle.

Multi-Tenant Architecture: One Codebase, Many Practices

MealCircle serves multiple nutrition practices — each is a separate covered entity under HIPAA, and their patient data must be strictly isolated.

I chose PostgreSQL row-level security (RLS) for tenant isolation:

-- Every patient table carries a practice_id
ALTER TABLE patients ENABLE ROW LEVEL SECURITY;

CREATE POLICY practice_isolation ON patients
    USING (practice_id = current_setting('app.current_practice_id')::UUID);

-- Set at the start of every request in the application middleware
SET LOCAL app.current_practice_id = 'abc123...';

With RLS, even if my application code has a bug that forgets to filter by practice_id, the database silently returns only the current practice's rows. Tenant isolation enforced at the storage layer, not just the application layer. This is the same pattern I use in client work — documented in the CCM/PCM software requirements article.

The Retention-First Data Model

Most nutrition apps model meals. MealCircle models adherence — the relationship between what a patient was coached to do and what they actually did. The difference sounds subtle; it changes the data model entirely.

A meal log entry isn't just calories and macros. It's a data point on a patient's compliance curve: did they follow the coach's recommendation this week, and did the recommendation match their reported goal? The dashboard surfaces this as a retention risk score — practices can see at a glance which patients are trending toward churn before they miss their next appointment.

What I'd Build Differently

  • Start with Stripe earlier: I delayed subscription billing by 3 months using manual invoicing. The integration complexity was the same; the delay just created billing technical debt.
  • Use FHIR from day one for patient demographics: MealCircle started with a custom patient schema and later needed to map it to FHIR for EHR integration. Starting with FHIR-aligned resource shapes would have saved that migration. See the FHIR vs HL7 v2 comparison for why FHIR shapes are worth using even before you need full interoperability.
  • More aggressive RLS testing: I added a suite of cross-tenant query tests after launch. Should have been in from the first migration.

You can see MealCircle in action at mealcircle.co — the features page shows the retention-focused interface, and the for clinics page covers the practice management side.

If you're building a healthcare SaaS and want a technical partner who has shipped one — the contact page is the right starting point.

Related Service

Custom Practice Management

Deep-dive into our engineering approach, capabilities, and technical specifications.

View Engineering Specs →
SA

Written by Sheharyar Amin

Founder & Lead Engineer, Opexia