Idea to a system someone can actually run.

Before a single line of app code, the product needed a home: a dedicated domain for its backend, DNS configured through a managed edge platform, and business email set up and routed correctly. It's a small detail in a case study, but it's exactly the kind of setup work a small business owner doesn't want to have to think about — and exactly the kind of thing that has to be right before anything else can be built on top of it.

Scavenger is a native SwiftUI app for iPhone and iPad — a shared shopping list for a household, built around the idea that grocery runs and errands are a team sport. Add items by typing, talking, or snapping a photo of a list, and an AI-assisted feature sorts everything into categories automatically, so nobody's manually organizing a list mid-aisle.

The app was designed, built, and iterated in a tight, fast cycle — weeks, not months, from first commit to an App Store submission — and is now live and available for download.Live That status is accurate as of this writing; a case study is only useful if it tells you the truth about where things actually stand, not where they're hoped to be.

An app that works in a demo and a system a business can actually operate are two different things. Alongside the app, we built a dedicated internal operations console — real usage and cost visibility, feedback triage, crash and error trend tracking, and the layered safety controls described below — so running Scavenger day to day means looking at real numbers, not guessing.

Scavenger's AI feature calls a paid third-party API — real usage means real exposure to cost anomalies, whether that's a bug, misuse, or something in between. The obvious protection is one all-or-nothing switch: something looks wrong, the whole feature goes dark for every user. We built something more deliberate instead — a layered, proportionate response, so the scale of the reaction actually matches the scale of the problem.

A cost anomaly degrades gracefully — one affected account loses one feature — instead of taking the whole product offline for everyone. That's the kind of engineering judgment that matters more to a business than any single feature: proportionate response over blunt instruments.

Monitoring that nobody sees isn't monitoring — it's a dashboard nobody opens. Real conditions (elevated error rates, cost anomalies, feedback spikes, and health checks) are tied to real alert routing: email for a record of what happened, and push-based on-call-style notifications for anything that actually needs eyes on it right away. Each condition has its own threshold and its own cooldown, so a real incident is impossible to miss and a brief blip doesn't turn into alert fatigue.

Alerts also track their own resolution — when a condition that triggered an alert clears, that gets reported too, closing the loop instead of leaving an open question about whether something's actually fixed.

Not everything needs to run in the cloud, and not everything should. Everything in the customer's actual path — the application itself, every feature that has to be reliably available — runs in the cloud, built specifically to maximize uptime for what the end user is actually touching. Reporting and internal operations tooling, the parts no customer ever sees, run on existing on-premises infrastructure instead — a deliberate, cost-aware choice, not an incidental detail about where a server happens to sit.

That infrastructure is held to the same bar as anything public-facing: scoped access, real monitoring, and a check that confirms the monitoring itself is still running — not just the systems it watches — so a quiet failure in the watcher can't go unnoticed. It's the same standard applied everywhere else: infrastructure competence isn't just a cloud/mobile story, and it doesn't stop at the parts a client happens to be looking at.

A safety or scope claim — "this only runs in debug," "this can't reach production data," "this is off by default" — is only as good as the verification behind it. Before anything ships, and before any claim like that gets made about it, it's checked three ways: against the actual source, against the build configuration used for the real release (confirmed, not assumed), and against the compiled release artifact itself.

That third check is the one most teams skip, and it's the one that actually matters — source can look correct and a shipped binary can still say something different if a build flag or an environment difference slips in between the two. Verifying against what actually ships, not just the code that's supposed to produce it, is what turns "this should be fine" into "this is confirmed fine" before it ever reaches a user or a client.