We ran the Advantage Assessment on ourselves first.

Community grocery price-sharing PWA for Austin neighbors — live with real Firebase data across 22 stores.

Findings

• OperationsDaily price-reseed automation is built (src/utils/reseed.js) but the Cloud Function path is blocked on a Firebase Blaze-plan upgrade — a billing decision, not an engineering one, sitting between the product and full reliability.
• VisibilityNo structured data (schema.org) on any page, and the app lives on a subdomain of a different property (marketprice.migratelife.org) rather than its own indexed domain — diluting whatever search equity it builds.
• TrustNo visible proof the price data is current or community-verified anywhere in the UI — a first-time visitor has no signal for "can I trust this number."

Priority fix: Operations first: unblock the Blaze-plan upgrade so reseed runs automatically, since every other capability gap is downstream of "is the data actually fresh."

Assessment complete. Fix not yet started — logged as the next engagement.

AI message-reframing tool with live Stripe billing, 6 reframing modes, and a built-in share/virality loop.

Findings

• TrustReal usage exists (rinses, shares, paying subscribers) but none of it surfaces on the homepage — no usage count, no social proof, despite the product having genuine traction to show.
• VisibilityShare pages (/share/[id]) already carry proper OG meta tags for virality, but no schema.org markup exists anywhere and the homepage title tag is generic rather than keyword-specific.
• GrowthShare-adoption is tracked in aggregate (total shares, total share views) but not per-rinse — so there’s no way yet to see which reframes actually drive the viral loop.

Priority fix: Trust first: surface real usage numbers on the homepage. It’s the cheapest fix here and the product already has the proof, it’s just not shown.

Assessment complete. Fix not yet started — logged as the next engagement.

AI-powered media ingestion, tagging, and semantic search pipeline for video production teams — built for internal production work, now opening up to outside creators with self-serve upload and subscription billing.

Findings

• OperationsEvery render request spawned its own unlimited thread with no concurrency cap, and job status lived only in memory — a server restart silently lost every in-flight render. Replaced with a durable, DB-backed job queue with a fixed concurrency cap and atomic multi-worker claiming; verified under real load that the cap holds exactly and job status survives a full restart.
• TrustA cross-tenant access gap: a logged-in subscriber could list, build timelines from, and render footage belonging to any other client’s event just by knowing its name — the editing surfaces never checked the per-tenant access list every other page already enforced. Found and closed before any outside customer was invited, verified in both directions.
• GrowthNo self-serve path existed for a new customer — every account and every piece of footage needed an admin to set up by hand. Built invite-based signup (pre-scoped access, zero admin follow-up) plus a self-serve upload pipeline, and wired up real Stripe billing end-to-end.

Priority fix: Growth next: checkout and webhook billing are live and verified end to end, but deliberately switched off until real paying customers are actually being invited — no point paywalling a product that’s still finding its first users.

Operations and Trust fixes shipped and verified live. Growth (billing) built and verified, intentionally not yet turned on.