03 Services
Postgres schemas that survive a schema change, authentication that does not lock users out, edge functions for the work that cannot live on a phone, and row-level security written so a leaked client key cannot read another person's data.
Every app in this portfolio has a backend behind it and we wrote all of them: Postgres on Supabase, authentication, edge functions for the work a phone cannot do, and the webhooks that keep the App Store and the database telling the same story.
The part we take seriously and most teams skip is row-level security. A mobile app ships its client key inside the binary, and anyone who downloads the app can read that key out of it. So the only safe assumption is that the key is public, and every table has to be written so that whoever holds it can reach one user's rows — their own — and nothing else. We write those policies with the schema and then test them with a key that should not be allowed, because that is the only test that proves anything.
The rest is unglamorous and load-bearing: migrations that roll forward on a live database with users on it, an account deletion path that actually deletes, and a schema that survives the day the product changes shape.
Every meal is tied to an account rather than to a device, which is the difference between an app people use for a week and one they keep for a year. That is Postgres, auth and sync on the server, with HealthKit on the phone so the same numbers also land in Apple Health.
Bite AIOrder Fit matches restaurant meals near you against a calorie target, so the catalog behind it sits on the server and can change without an App Store release. The app asks a question; the backend answers it. That split is a decision made at schema time, not a refactor.
Order FitPolicies are written per table and audited per policy, including deletes, on the assumption that the client key is already in a stranger's hands. The bar is simple: with that key, a stranger can read their own rows and cannot read, write or delete anybody else's.
Apple requires an in-app way to delete an account, and signing the user out does not count. We build the server half — the rows, the stored objects and the subscription record — so that what the app promises and what the database does are the same thing.
Tables, relationships and the queries the app will actually make, before screens get built on top of a shape everyone regrets in month three.
Row-level security goes in table by table as the schema is written, not in a pass at the end when nobody remembers what each column was for.
Every change is a migration that can be applied to a live database with users on it. Nothing gets fixed by hand in a console and forgotten.
Edge functions and webhooks for the work a phone cannot do or cannot be trusted to do: purchase verification, scheduled jobs, and anything holding a secret.
Every policy is exercised with a key that should be refused. A policy nobody has tried to break is a policy nobody has tested.
A paragraph about the app, the feature or the thing that is stuck is enough, plus roughly when you need it and the budget range you are working with. One piece of this on its own is fine, and so is the whole thing. Our team reads every message and answers, usually within one business day.