Support, privacy links, andour first merged backend

Why this week mattered

For the first two weeks of building Mommy Refuel, the app worked entirely on its own: everything a mother typed lived on her phone, and there was no way for us to reach her if something broke, and no way for her to reach us either. That is fine for a private prototype. It is not fine for something real people install through TestFlight. On 2026-08-29 I sat down with our own TestFlight launch checklist and started closing the gaps, one by one, starting with the two most basic things any app needs before anyone outside my house tries it: a working support link and a working privacy link.

A real support page, not a placeholder

It turned out the app already had the code to show "Help & support" and "Privacy policy" rows in the Profile screen, and it already knew how to read the URLs for them — but nobody had ever set the URLs. Two dead settings, sitting unused since the very first build. I fixed that by pointing the app's support and privacy keys at real pages, and by writing an actual support page from scratch rather than a one-line contact form.

The support page says plainly what Mommy Refuel is at this stage: an informed beta. Safety-related content is draft, not a medical or emergency service. It explains what happens to your data on the device, how to delete it, and it lists real crisis numbers, because a wellbeing app that skips that is not being honest with the people using it. I wrote it in English and Ukrainian side by side, since both languages ship in the app itself.

App Store screenshot sets

The same day I captured and committed the first full set of App Store screenshots, along with install notes for testing the app straight on a phone. None of this was glamorous work — it is the unglamorous 20% of shipping an app that never shows up in a demo, but blocks everything if you skip it.

A real backend: cloud sync, export, and delete

Two days later, on 2026-08-31, the app got its first real backend. Until then, "your data stays on your device" was true because there was nowhere else for it to go. That is not the same as a deliberate privacy design — it is just an app with no server yet. I built the actual thing: a cloud sync service on Supabase, with the edge functions to back it up.

The two functions I care most about are account-export and account-delete. A mother should be able to get a copy of everything the app holds about her, and she should be able to make all of it disappear, permanently, on request — not as a settings toggle that quietly keeps a backup somewhere. Both functions went in from day one, alongside row-level security rules and triggers so that one person's data is never visible to another, and a set of automated tests that check the deletion rules actually hold, not just that the button exists.

I also wrote the first real documentation set that week: how authentication flows, how the backend is architected, the database schema, deployment steps, a map of exactly what personal data the app touches, and a security overview. Writing these down before the backend grew any further mattered more to me than adding features — it is much easier to keep a system honest when you wrote down what "honest" means before the second and third feature arrive.

An auto-deploy pipeline for the backend

The same day, I set up a deploy pipeline so the backend does not depend on me remembering the right sequence of commands. Every push to main now runs linting, type checks, and unit tests, then links to Supabase, pushes database migrations, sets secrets, deploys the edge functions, and finally hits a /health endpoint to confirm the deploy actually worked — not just that the commands ran without error. Pushing to main deploys to staging automatically; production only deploys when I trigger it manually, on purpose, with credentials scoped through GitHub Environments. I never want "I pushed to main" and "I shipped to real users" to be the same action by accident.

Where and when

• 2026-08-29, 07:02 — Support & privacy URLs wired into the app's build settings, Profile support rows shown, new support page written EN/UK, first App Store screenshot sets and install notes committed (f6ad294).
• 2026-08-31, 16:11 — Cloud sync backend: Supabase edge functions for account export/delete and health, request-safety guards, database migrations, and six new documentation files covering auth, architecture, schema, deployment, the data map, and security (5c4f3d8).
• 2026-08-31, 16:14 — Auto-deploy workflow added: verify → migrate → deploy → health-check, staging on every push to main, production only on manual trigger (a817d96).
• 2026-08-31, 16:56–17:12 — A first, self-hosted AI proxy supporting both Anthropic and OpenAI, with a safety gate that runs before any model call, plus the iOS app pointed at it through a new backend URL setting (e7e7170, 7bafa4f, a42ecd8).
• 2026-08-31, 17:20 — Pull request #1 merged into main: the first time app, backend, and site changes went through review before landing, rather than direct commits (9e9f7d1).
• 2026-08-31, 17:53 — Two small follow-up fixes to load the self-hosted environment correctly and update the Supabase config (e0eafc1, 6d3de2a).

What this means if you use the app

If you were testing Mommy Refuel this week, nothing changed on your screen — this was entirely infrastructure. But three things became true that day that were not true before: there is now somewhere to write to us if something is wrong (the new support page), there is a real answer to "what happens to my data" beyond "it's on your phone" (export and delete, backed by tested rules, not a promise), and the backend that everything else — sync, the assistant, family features — depends on now deploys the same way every time instead of by hand.

What this is not, yet

This week did not touch the App Store. It did not add any feature a tester would notice. The AI proxy that shipped here was self-hosted and temporary — within two days I would move it to a cleaner setup, which is its own story. I am writing all of this down honestly, including the boring parts, because I think a changelog that only mentions the exciting weeks is not really a changelog.