ReciPure

Independent Product — Currently Under Development This whole project is still a work in progress. ReciPure hasn't launched yet and remains under active development — screenshots, a demo video, and App Store / Google Play availability will be added here as they're ready.

The Idea

ReciPure started from a familiar, specific frustration: recipes end up scattered across Instagram saves, TikTok bookmarks, screenshots, and half-remembered web pages — and even once you've found one, making it healthier means doing your own research on substitutions, portioning, and nutrition. The idea was to collapse that gap: capture a recipe from wherever it lives, turn it into something structured and usable, and make "healthier" a single decision rather than a research project.

The product's own framing of this is direct: "Cook what you love — just healthier." Not a diet app, not a recipe-of-the-day feed — a system that takes the recipe you already wanted to cook and makes it a little better for you, without asking you to change what you're making.

The inspiration point was ReciMe and apps like it — established recipe-management products with a loyal following. ReciPure describes its core recipe-management layer as a "ReciMe-level base" — the baseline of what a serious recipe app needs to do well (import, organize, plan, shop, cook) — with a second, distinguishing layer on top: AI-assisted structuring and a healthier-recipe engine. This is founder reasoning, not validated market research — there's no user-interview data or survey behind it, and that's worth being upfront about.

ReciPure is a hybrid mobile application — built once, running on both iOS and Android — organized around one core loop: Import → Transform → Cook. A user brings in a recipe (a social link, a web page, a pasted caption, a photo, or typed by hand), the app turns it into a consistent structured recipe, can optionally generate a healthier version that still looks and tastes like the same dish, and then cooks it with guided, narrated steps. From there, recipes organize into collections, feed into a shopping list, and slot into a weekly meal plan.

The product is structured in two layers: Recipe Infrastructure (import, structuring, organization, grocery, meal planning, core cooking utilities — the baseline category expectation) and Intelligent Enhancement (the Healthy Swap engine and guided cooking — the differentiating layer).

What's deliberately out of scope for this version: personalized, goal-adaptive health recommendations (weight loss, muscle gain, allergy-aware substitutions) are an explicit future direction, not a current feature — the current Healthy Swap engine applies one considered, non-personalized transformation. Commercially, the product is a hard-paywalled subscription — there is no free tier inside the app, by explicit business-model decision.

---

Design

ReciPure runs on a deliberately constrained design system rather than an ad-hoc one: a citrus-and-olive palette (citrus reserved for highlights only, olive for primary actions, no pure black anywhere), a typography split between a clean sans-serif for the bulk of the UI and a serif accent used sparingly for emphasis, and a consistent spacing/radius scale across every screen.

One design-engineering decision is worth calling out because it's a real, documented reversal: the project installed and configured Tailwind-style utility styling early on, then deliberately abandoned it in favor of inline styles driven by a single shared theme-token module. The reasoning, which I wrote into the project's engineering rules: with two competing styling systems wired into the build, it's too easy for visual decisions to drift from the single source of truth. Rather than straddle both, the utility-styling path was frozen out entirely and never used — a small thing, but it reflects a general pattern in how this product was built: prefer one clear system over two half-used ones, even after paying the setup cost of the one that got abandoned.

The navigation and information architecture went through a real revision cycle, not just an initial design: an early version had separate "Recipes" and "Cookbooks" sections with a conventional bottom tab bar. A structured internal product review flagged this as redundant and recommended merging them into a single home surface with a grid-first layout, plus moving the navigation itself to a floating, elevated treatment rather than a bar flush against the screen edge. Both changes were implemented as a dedicated phase — the navigation today has exactly three tabs (Home, Planner, Grocery) behind a custom floating bar.

---

Engineering & Ownership

ReciPure's codebase is solo-authored: every commit across roughly five months of phase-by-phase development carries the same author, with no merge commits and no co-authorship anywhere in the history. The commit history is tagged by phase and task, and checked samples line up closely with the project's own phase-tracking documentation — a running build log kept current throughout, not a retrospective narrative written after the fact.

Part of how this was built is worth describing precisely, because overstating it would undercut the more defensible version of the claim: the project operated under a self-imposed written rule requiring a stop-and-confirm step before touching anything load-bearing — database schema, authentication logic, payment logic, or the AI prompt architecture itself — with an AI coding agent doing the implementation work under that constraint. That rule is real and documented. What isn't claimed is that every individual sign-off moment is independently verifiable from the repository alone — the rule's existence and sole authorship of the result are the evidence; moment-by-moment adherence to it isn't something a code audit can confirm on its own. The accurate framing: one person set the architectural boundaries the AI could not be relied upon to self-police, and the repository shows that boundary was written down and the result was built by one author.

Structurally, I kept the backend to a strict, consistently applied layering: routes delegate to controllers, controllers delegate to services, and no business logic lives in the routing layer. The frontend is organized by product domain (recipes, swaps, cookbooks, grocery, meal planning, voice, auth, paywall, analytics, monitoring, notifications), each domain owning its own components, hooks, and services rather than one large undifferentiated folder.

---

Architecture

The backend is a Node/Express service backed by Postgres (via Supabase), with its schema evolved through seven sequential, versioned migrations rather than a single upfront design — recipes gained source-identity tracking for deduplicating re-imports, then an editing/versioning column, then nutrition-provenance tracking, then push-notification support, each added as the product's needs became concrete. The schema carries deliberate indexing on the access patterns that matter: lookups by user, chronological ordering, tag search, meal-plan lookups by date.

One piece of backend architecture stands out as a genuine engineering problem solved, not just a feature shipped: recipe import and the Healthy Swap transformation both call out to an AI provider, and those calls can take long enough that a plain synchronous request either times out or leaves someone staring at a spinner. The solution is a dual-path system — every request checks, at request time, whether a background job queue is not only configured but actually has a live worker currently processing it, confirmed via a short-lived heartbeat signal the worker refreshes continuously.

That second check matters: a queue with no live worker behind it would otherwise make requests hang forever waiting on a job nobody will ever process.

A second piece of real security engineering: any feature that lets a user submit an arbitrary URL for the server to fetch is a standing invitation for server-side request forgery. Every outbound fetch whose destination is derived from user input runs through a dedicated guard that blocks private and reserved IP ranges (including the address cloud providers use for internal metadata), restricts to standard web ports and protocols, resolves DNS and checks every address a hostname might return — not just the first, which closes a common bypass — and re-validates the destination at every hop of a redirect chain rather than trusting the first one. This is scoped precisely to where it's needed: applied to every fetch that follows a user-supplied link, left off fetches to fixed, trusted third-party hosts where it would add nothing.

On the mobile side, ReciPure is built with Expo and React Native, deliberately staying on Expo's managed workflow rather than ejecting to hand-maintained native code — a choice that mostly paid off, with one exception. Letting a user share a recipe link directly from Instagram, TikTok, or a browser into the app requires genuine native integration on both platforms: a real Share Extension target on iOS, real intent filters on Android. Getting this working inside the managed workflow surfaced a known, documented issue in the third-party plugin handling native project generation, resolved with a targeted patch rather than ejecting the whole project just for this one feature.

Navigation is file-based (Expo Router), three tabs behind the custom floating bar described above. I kept platform-specific code deliberately narrow — iOS and Android share the same product logic, and the only differences are where the platforms are genuinely different (keyboard-avoidance behavior, per-platform billing SDK configuration, Android's notification-channel concept having no iOS equivalent, secure token storage differing between native and web).

State is split cleanly by purpose: focused, single-responsibility client-side stores for things like authentication state, notification preferences, and in-progress job tracking, with server data handled separately through a query-caching layer that manages its own cache invalidation, retry behavior, and — on at least one high-interaction surface, checking off a grocery item — full optimistic updates with rollback if the server rejects the change.

A real mobile-specific problem surfaced in the cooking experience itself: background timers in React Native are throttled by the OS once the app isn't in the foreground, which would silently break a cook-mode countdown the moment someone switched apps mid-recipe. The fix schedules a real OS-level local notification the instant the app detects it's backgrounding during an active timer, so the user still gets alerted even though the in-app timer itself has stalled. This specific backgrounding case is handled; a broader, separate question — how very long timed steps are presented before that point — is still open (see Pre-Launch Status).

---

AI & Product Systems

ReciPure's AI usage is intentionally narrow — two real capabilities, not a broad "AI-powered" surface.

Recipe structuring. When a recipe comes in from a link, pasted text, or a photo, a language model turns the raw source material into a consistent structured recipe — title, ingredients with quantities, ordered steps, timing, servings, and nutrition. A second, vision-capable model handles the photo-import path specifically. Handwriting recognition isn't a separate capability — it's the same photo-import model and code path, extended by one additional prompt instruction to also read handwritten text.

The product makes one specific, enforced promise about recipe structuring: it will not invent a recipe that isn't there. That's backed by a hard rule in code that rejects any AI output that doesn't meet a minimum bar of actual structure — a real ingredient list and a real set of steps — regardless of what the model claims to have found. A defensive normalization step also corrects for missing fields and type mismatches before that data is trusted downstream, applied to the recipe-structuring and photo-import paths; this same normalization hasn't yet been extended to the Healthy Swap response path — a known gap, not a hidden one.

Healthy Swap. The harder design problem wasn't making a recipe healthier — a model will happily swap out every ingredient it can find an excuse to change. The harder problem was making sure a healthier Butter Chicken still reads, cooks, and tastes like Butter Chicken. The transformation is explicitly instructed to first identify what the dish actually is — its cuisine, its defining ingredients, what makes it recognizable — before touching anything, bound by hard constraints it's told never to violate: keep the same cooking method, don't introduce new equipment, keep the step count close to the original, and prioritize taste over how many things got changed. The system favors a couple of well-chosen, high-impact substitutions over maximum change, and leaves an already-reasonably-healthy dish mostly alone.

What this AI system deliberately does not do: no two-way voice interaction — cooking narration is one-directional text-to-speech, not a voice assistant that listens for commands; no personalization — Healthy Swap applies one considered transformation, not a goal-specific one; no streaming of AI output to the client — every call returns a complete result; and no automatic retry on a transient provider hiccup — a brief outage or rate-limit surfaces as an honest failure rather than silently retrying.

---

Commercialization

ReciPure is a subscription product with a hard paywall — there's no way to use the core app without an active subscription, by explicit product decision, not a technical limitation. Subscription state is managed through RevenueCat rather than custom billing logic, with the mobile client handling purchase and restore flows and the backend separately re-verifying subscription status before allowing the two features that carry real per-use cost: recipe import and Healthy Swap generation. That server-side re-check is deliberately fail-open — if the billing provider itself has an outage, the check allows the request through rather than blocking a paying customer over a third-party disruption, a documented tradeoff favoring availability over strict enforcement during a provider failure.

That gating split is deliberate product thinking: the app-wide paywall exists for business positioning — this is a premium product, not a freemium one. The narrower, separate server-side re-check exists for a different reason — cost protection specifically on the two features that call a paid AI provider. Every other feature (organizing recipes, planning meals, building a grocery list) carries no AI cost and isn't re-gated at that layer.

Still open: final subscription pricing and plan cadence haven't been decided. The commercial infrastructure is cadence-agnostic by design at the entitlement level, though the plan-selection screen's current display logic only cleanly distinguishes two tiers today — supporting a third cadence correctly in the UI is a small, known piece of remaining work, not just a pricing decision.

---

Tech Stack

No dedicated Testing row — the documented QA approach has been structured manual testing (running real content through the full import and cooking pipeline), not an automated suite. That gap is tracked as known, planned work — see Pre-Launch Status.

---

Pre-Launch Status

As of this writing, ReciPure is a working product that hasn't launched and remains under active construction. The core loop — bringing in a recipe from a range of common sources, structuring it, optionally making it healthier without losing what made it recognizable, cooking it with guided narration, and organizing it into a shopping list and weekly plan — works today for the sources currently supported: direct links and content from major social platforms, general web pages, pasted text, photos, and manual entry. Not every social platform named in early product planning is wired up yet — one source doesn't have a working import path today, a known gap rather than something implied as finished.

The commercial layer is real, working infrastructure with an open pricing decision on top of it, plus the small plan-display fix noted above once a third cadence is added. QA has been a structured manual process rather than an automated test suite — a known, planned gap, not an unnoticed hole.

What remains before a public launch: the product is moving through dedicated phases for UI/UX refinement, a security review, and building out automated test coverage, followed by a final production readiness check before App Store and Google Play submission.

No users, no revenue, and no retention data exist yet, because the product hasn't launched. Any numbers that might eventually support claims about adoption or engagement don't exist today and aren't claimed here.

---

What's Next

• Finalize subscription pricing and plan structure, and extend the plan-selection UI to correctly display a third pricing cadence.
• Complete a dedicated security review pass before submission.
• Build out automated test coverage, moving beyond the current manual QA process.
• Finish on-device validation of the remaining iOS-specific integrations (native share extension, push notification delivery) that depend on store-account setup not yet completed.
• Close the remaining gap on social-source import coverage noted above.
• Submit to the App Store and Google Play.
• Revisit the Healthy Swap engine's next stated direction — personalized, goal-adaptive transformations based on individual health goals and dietary preferences — as a deliberate post-launch evolution of the current, intentionally generic version.

---

Scope: This case study reflects a working, pre-launch product under active development — not a finished release. It's solo-built under my own name. No automated test suite exists yet (QA has been manual), no continuous-integration pipeline is in place, and no users, revenue, or retention data exist because the product hasn't launched. Screenshots and a demo video will be added here as they're ready.