Lessons From Building MealCircle: A Healthcare SaaS Post-Mortem

Why I'm Publishing This

MealCircle is a retention-first clinical nutrition SaaS I built for dietitians from scratch, HIPAA-oriented, with multi-tenant architecture and an EHR integration path designed around FHIR. It's the product I point to when people ask whether I've actually shipped healthcare software myself.

This article is the honest version of what building it taught me — not a fundraising narrative, but a technical post-mortem written for engineers and founders who are about to do something similar.

What I Got Right

Starting with HIPAA architecture, not retrofitting it

The biggest risk in healthcare SaaS is building a functional product and then trying to bolt on HIPAA compliance before enterprise sales conversations. The compliance work changes the data model, the infrastructure design, and the third-party tool selection — retrofitting it is significantly more expensive than starting with it.

Every database table had a practice_id and row-level security from migration 1. Cloud Audit Logs were enabled before the first line of application code. Secret Manager was the only way credentials entered the system. See the HIPAA engineering checklist for the full architecture I started with.

Multi-tenant isolation at the database layer

I used PostgreSQL row-level security to enforce tenant isolation structurally — not just in application code. This means a code bug cannot leak cross-tenant data. Hospital security audits want to see this kind of structural isolation, not application-layer assertions. The full implementation is in the MealCircle multi-tenant database design article.

Building the retention model before the feature set

Most nutrition apps have meal logging. MealCircle's differentiation is adherence tracking and retention risk scoring. I built the data model for adherence before I built the meal logging UI. That sequencing forced every product decision to be evaluated against the retention thesis. Features that didn't generate adherence data got deprioritized.

What I Got Wrong

Delaying Stripe billing by three months

Covered in detail in the billing article, but the short version: billing delay creates technical debt and you lose three months of revenue data that would have informed pricing decisions earlier.

Over-engineering the analytics pipeline for v1

I built a full async analytics pipeline for the retention risk scores in v1 — Celery workers, Redis queue, the works. In practice, the scores only needed to refresh daily. A simple nightly cron job would have been fine for the first year. I spent 3–4 weeks on infrastructure that a pg_cron scheduled query would have handled.

Not setting clear EHR integration scope early enough

I spent two months evaluating Epic's developer programs (the successors to App Orchard) before deciding to build against FHIR R4 with a middleware separation. That decision was correct, but I should have reached it in week one — the Epic app approval timeline makes it clear upfront that direct integration is a multi-month process. Adopting a middleware-first EHR strategy earlier would have freed that time for retention feature work.

The Build vs Buy Decisions

| Component | Decision | Rationale | |---|---|---| | Auth | Firebase Authentication | Managed identity on Google Cloud, saves weeks | | Payments | Stripe | PCI handled, webhook reliability | | Email | SendGrid (BAA) | HIPAA BAA available | | Infrastructure | Google Cloud | HIPAA BAA, Cloud KMS, Cloud Audit Logs | | Database | PostgreSQL on Cloud SQL | Row-level security, familiar | | EHR integration | FHIR middleware pattern | Vendor-agnostic, scalable |

The common thread: buy anything that is a solved problem with a HIPAA BAA available. Build anything that is your core differentiation.

What This Means for Opexia Work

Building and shipping MealCircle changes the conversations I have about custom healthcare software. I'm not advising on healthcare SaaS architecture from theory — I've made the actual HIPAA trade-offs, hit the actual multi-tenant edge cases, and shipped the actual production system.

When an operator asks whether custom PM software is the right investment, I can point them to the build vs buy framework and then to MealCircle as evidence that custom healthcare SaaS built right is a defensible, maintainable product — not an expensive one-off.

Visit mealcircle.co to see the product, or mealcircle.co/founding for the origin story.

If you're building a healthcare SaaS product and want a technical partner who has shipped one — start a conversation.