PetPals — Product Requirements Document

Review draft 1.2 · 28 October 2026 Native iOS first. Matching native Android next.

This document consolidates the product discussion into one current specification. It replaces the earlier running PRD notes. “Agreed” means the user explicitly requested the behavior; it does not mean the entire storyboard or implementation is approved. Proposed release boundaries, prices and technical choices are identified below. Graphics and storyboard review remain in progress.

1. Product purpose

PetPals helps people enjoy life with their pets, build useful routines, connect with friends, discover local care and bring missing pets home. The pet is the personality at the center of the experience. One human account can manage several pets and, where verified, a real business location.

The experience must make the next step obvious. A person should not need to understand our feature inventory to start a walk, report a sighting or find a veterinarian. Each journey should show the current task, one clear next action and a reliable way back.

The existing live app has active users. A redesigned experience must preserve their identities, pets, relationships, content, points and outstanding obligations. A feature deferred from the redesign cannot simply disappear for existing users who depend on it.

2. What we are agreeing before building

1. Finish the storyboard, including onboarding and important failure states.
2. Agree on the journeys, visual direction and realistic first-release scope.
3. Finalize the Firebase/Google architecture, data contracts, permissions, costs and migration plan.
4. Build and validate the backend foundations in an isolated development environment.
5. Implement and pilot native iOS, then roll out gradually with a rollback path.
6. Build matching native Android against the agreed product and service contracts.

This PRD covers planning and review mockups. The user has authorized publishing the review website at petpals.isnotreal.site. Production app/backend changes, purchases and database migrations remain outside this planning scope. The current Flutter mockup and live-source layouts are references to capabilities, not designs to reproduce.

3. People and roles

• Pet owner: manages one or more pets, walks, routines, posts, friends, rewards and missing-pet cases.
• Nearby helper: can browse permitted missing-pet information and report sightings without inventing a pet profile.
• Business operator: verifies authority over a physical location, manages its PetPals presence, answers inquiries/reviews and buys permitted promotions.
• Partner/advertiser: supplies agreed products or paid advertising; may be separate from a location's operator.
• Moderator/operator: reviews claims, reports, advertisements and exceptional reward or migration cases through controlled tools.

One person may have several roles. Business management must stay distinct from the pet's personality page. Shared household care, detailed staff permissions and multi-location administration require later design decisions.

4. Navigation and visual rules

The agreed persistent navigation is: Profile · Feed · Missing · Nearby · Messages. Missing is the central rescue entry. The bar meets the bottom edge and respects the phone's safe area; it must not float above an empty gap.

Profile is the selected pet's everyday hub. Feed is a separate destination. This supersedes the earlier idea of scrolling down Profile into the feed. Settings remain available through the header, with account/security and business management separate from pet identity.

Visual requirements:

• Square app controls, buttons, cards and image corners. No rounded app containers. Native device/system chrome retains its platform shape.
• Blue/yellow light direction, real pet and product imagery, generous readable type and clear hierarchy.
• Dark appearance uses black backgrounds and charcoal surfaces. Blue remains an interaction accent.
• Small pawprint details give the product character without replacing labels or adding clutter.
• A custom PetPals icon family is requested. The graphics pass must replace generic feature artwork with consistent, distinctive assets, while retaining understandable meanings and accessible names.
• Emergency reporting uses strong red actions with clear wording. Urgency comes from placement, contrast and language, not flashing animation.
• Native touch targets: at least 44pt on iOS and 48dp on Android. Support larger text, screen readers, reduced motion and visible focus without clipping essential controls.

The local storyboard uses sample content and simulated camera, location, payment and publishing actions. Generated product images illustrate a proposed catalogue; they are not real partner offers.

5. Proposed release scope

The first release should prove the connected everyday loop: return/sign in → select pet → walk/capture → finish/goal → optional share → eligible points → useful reward. Missing-pet support and existing-user continuity are equally important release gates. DNA cup sales are a confirmed launch requirement under an existing paid partnership, not a later marketplace expansion.

First redesigned iOS release — proposal

• Returning-user sign-in/recovery, short onboarding, multiple pets and pet switching.
• Pet profile/photo/bio/life goals, privacy settings and recent posts.
• Recorded walks with photos, short video and notes; completion statistics, goals, private saving and reviewed sharing.
• Basic grooming routines, reminders and completion tracking.
• Friends feed, an initial For You experience, posts/reactions/comments, messages and effective report/block controls.
• Missing-pet reporting, local alerts, camera-first sightings, updates and owner-confirmed reunion.
• Nearby walking spots, veterinarians, groomers, pet sitters and pet-friendly businesses, with map/list views and inquiries.
• Preserved points/history and a small real partner catalogue with supported redemption and fulfillment.
• DNA cups available to buy at launch under the paid partnership, with checkout, verified orders, fulfillment and customer support.
• Physical-location claims through manual verification, basic business management, PetPals review replies and managed promotions.
• Direct partner advertising and an initial paid promotion route. Managed campaign operations can support early revenue before a full self-service advertising console.

Paid missing-pet reach is a requested capability. Include its states and entitlement model now; activation depends on approved radius/pricing, purchasing rules, delivery limits and cost tests. Free reporting and sighting help must work independently.

This is still a substantial scope. Estimates and a staged release sequence follow storyboard agreement; there is no committed launch date or fixed budget in this PRD.

Later expansion — proposal

• Monolith training/serving and sophisticated recommendation experiments. The user intends Monolith for main feeds; simple initial ranking requires agreement, not a silent substitution.
• Broad multi-seller marketplace checkout, expanded reward campaigns and seller tooling. The complete DNA cup purchase and support journey is required at launch.
• Self-service campaign buying/reporting, advanced staff permissions and multi-location administration.
• Group events/challenges, leaderboards, complex streaks, livestreams, stories, encounter/radar games and expanded care records.
• Additional health/lab integrations and native results features beyond the agreed DNA partnership commitments. Launch obligations for kit instructions, sample handling and results access must be confirmed with the partner, not assumed deferred.
• Deeper adoption/breeder commerce and complete reservation/payment workflows. Preserve existing listings, messages, applications and reservations while expansion waits.

6. Onboarding and returning users

New owner journey: welcome → choose purpose → create/recover account when needed → add one pet → choose optional trackers/goals → review privacy → Profile.

“Already use PetPals” checks the existing session. A valid session restores the existing account and pets. Otherwise it opens sign-in and recovery. It must not create a duplicate account or match ownership using pet names or email text alone. Existing anonymous/device identities require a safe linking/recovery plan.

New-owner onboarding sets up exactly one pet. Add another pet is available later from Profile; it is not an onboarding step or loop. Returning users recover all existing pets. Helpers and business operators can continue without creating a fictional pet.

Per pet, ask what the person wants to track: walks and grooming are agreed; play/enrichment and other care reminders are optional proposals. Let users skip nonessential choices and change them later. Grooming schedules are chosen by the owner, not prescribed universally.

Request camera, microphone, location and notification permissions when the relevant feature is used. Denial and cancellation must leave a useful alternative. Establish terms/privacy and age requirements before implementation; the target age policy is not decided.

Acceptance: a returning user does not lose or duplicate their pets; a new owner finishes with one pet and can skip optional trackers; Back preserves setup choices; adding another pet later does not overwrite the first pet's settings.

The review website shows two independent phones: onboarding on the left and the everyday app on the right. A dropdown above each phone jumps to preview states; Restart resets onboarding and Back preserves choices within the flow. The device picker remains available for iPhone and Pixel. The current onboarding proposes welcome, purpose, account, first pet, optional routines/goals, privacy and completion; account methods remain illustrative until confirmed.

7. Profile, pet personality and privacy

The hub shows the selected pet's name, photo and Visit Profile action beside the name. Swipe horizontally through owned pets, with bare left/right chevrons over the image. Pet identity, statistics, routines and action context change together.

Beneath the image show views, likes, walks recorded this week and goal progress, such as “2 more walks to reach your goal.” Views/likes definitions and time windows remain open; sample counts are not verified analytics.

Hub actions include Let’s walk!, Grooming, Shopping and Pet Sitters, with compact points/rewards and a prominent MY PET IS MISSING action. Do not turn every optional routine into another equally prominent tile.

Visit Profile opens the pet's personality: profile photo, bio, life goals and recent posts. Owners can edit; visitors cannot see editing controls. Life goals are personal ambitions written in the pet's voice, not clinical advice or performance requirements.

Privacy requirements:

• New posts default to Friends only. Per-post choices: Only me, Friends or Public.
• Profile visibility is separate from post visibility. A public profile never makes private posts public.
• Changing a posting default affects future posts only. Editing an existing audience is explicit.
• Preview the pet page as a friend or public visitor.
• Private walks stay private until the owner selects sharing and reviews its audience.
• Friend relationships, post-author identity across multiple pets and co-carer permissions must be defined before schema approval.

Acceptance: changing pets updates all visible context; a public visitor cannot read friends-only content through a profile, feed, cached response or share link.

8. Walks and grooming

Walk entry and recording

Let’s walk! is a button. It opens two choices: a large bold “Start a walk & record it,” then “Help me find a new place to walk” underneath.

Recording carries the selected pet forward and can include other owned pets. Explain route privacy and request location as needed. During the walk, show Walk in progress, elapsed time, distance, participating pets, Take a photo, Record a video, Write a note and End walk. Pause/resume is a proposed secondary action.

Photos, video clips and notes belong to that walk event. Capture returns to the active walk. Cancelling a photo or closing a note does not stop recording. Persist unfinished work locally so interruption or lost connectivity does not silently discard it. Video duration, upload limits and storage retention remain open decisions.

Ending shows duration, distance, pets and captured moments, followed by accurate encouragement tied to that week's goal. Saving the walk grants each eligible pet one completion credit; revisiting the summary or retrying sync cannot count it twice.

Sharing

A walk is private by default. Offer Keep private and an optional share journey. The owner selects highlights, caption and audience, then sees exactly what will be posted. Share time/distance and selected photos/video/notes; hide precise route, start and end locations by default.

Remove unrelated GPS metadata from shared media derivatives. Visible landmarks and notes may still reveal a location, so the owner must be able to remove them. Do not promise automatic anonymity. Exact or generalized route sharing is not approved scope.

Grooming

Support a chosen grooming activity, date/interval, reminder and completion history per pet. Initial examples: brushing, bath, nail trim or a groomer appointment. Completing a task updates the correct pet once. Users can reschedule or disable a reminder. Shared care, richer notes/photos and appointment integrations can follow.

Acceptance: a multi-pet walk is one event with correct per-pet credit; offline progress is retained; private routes never appear in the shared post; grooming settings remain independent for each pet.

9. Feed and messages

The Feed toolbar contains logo · Friends / For You · settings. No PetPals wordmark, “Good company” heading or introductory block on this page. Composer wording: “Share Something..”.

Friends contains friends' permitted posts only. Keeping unrelated recommendations and advertisements out of Friends is the current proposal. For You contains eligible public discovery and clearly disclosed sponsored placements. Monolith is the intended recommendation direction, but not a dependency already adopted or running.

Support selected-pet posting, audience review, reactions, comments, reporting and blocking. Counts need consistent definitions. A reported/blocked relationship must have an enforced outcome across feed, profile and messages, not merely a recorded button tap.

Messages provides clear context for pet-friend conversations, business inquiries and missing-pet contact. Sending, pending, failed and delivered states must be distinguished where known. A request sent to a business is not a confirmed appointment or payment.

Acceptance: Friends never leaks nonfriend/private content; blocked interactions behave consistently; retrying a message does not produce duplicates; offline drafts do not claim delivery.

10. Missing pets — priority experience

Entry and active status

MY PET IS MISSING is prominently visible on Profile; Missing is the center navigation entry. A red status bar appears below the header only when an active relevant case exists: MISSING PET ALERT NEAR YOU or MILO IS REPORTED MISSING. No active relevant case means no bar.

The current requested example is on Messages only. Broader placement and multiple-case aggregation still need agreement. An owner's own active case takes precedence in the proposed ordering.

Owner journey

Choose pet → last-seen place/time and identifying details → review exposure/contact → publish free alert → manage case and updates → confirm safely home.

Use in-app contact by default. Do not publish a home address or phone number automatically. Publishing, notification queueing and actual delivery are different states. Owners confirm reunion; a helper's report cannot close the case. Stop pending outreach after confirmed closure, and define how stale cases request updates or expire.

Helper journey

1. Start with a list: pet image on the left; name, brief description and last-seen area on the right. Map view uses the same cases.
2. Open “Have you seen Buddy?” with the owner's post, photo and where/when last seen.
3. Show a large red REPORT SIGHTING action immediately below the photo. It opens the camera first so the person can photograph a moving animal.
4. After capture, allow an optional note. A clearly visible note-only fallback is available when a photo is not possible. Preserve the draft when going back or closing.
5. Show a large “Where did you see them?” heading and two large, bold choices in the middle: Use my location / Choose on a map.
6. Current location is acquired when chosen and confirmed, not silently attached. On a map, keep a target fixed in the center and move the map underneath it; confirm with Use this location.
7. Review evidence and location, then send. Share the confirmed location only with permitted case roles, not automatically with a public feed.
8. Show Sent only after acceptance; offline work is Saved, not sent. A sighting is a possible match, not proof the pet has been found.

Record when the animal was seen separately from submission time. Current location may differ from the sighting spot. Preserve location source, timestamp and accuracy where available. Denial, poor accuracy and timeout must retain the manual-map fallback. Sightings and owner closure are free.

Geographic reach and paid expansion

Agreed baseline: a free alert with a 3-mile radius, aimed at eligible app users in that area. Optional feed posting is separate and requires an audience choice.

Illustrative expansion only: approximately $10 for 15 miles or $25 for 150 miles. Currency, duration, exact prices and coverage are not approved. Publish the free alert before offering an upgrade. Failed or cancelled payment leaves existing coverage active.

“Everyone within the radius” is a product ambition, not a promise of receipt: location freshness, consent, connectivity, notification settings and platform behavior affect eligibility and delivery. A 150-mile circle covers 2,500 times the area of a 3-mile circle; test recipient density and costs before pricing.

Acceptance: camera precedes note entry; target stays fixed while the map moves; the selected coordinate is what gets submitted; retries create one sighting; helpers cannot close another owner's case; paid expansion cannot disable a free alert.

11. Nearby, maps and our directory

Nearby answers “What are we looking for?” with Walking spots, Pet sitters, Groomers, Veterinarians and Pet-friendly places. Missing-pet help and adoption/rescue can be secondary entries.

Map and List share categories, area, loaded records and selected place. A pin and its row open the same detail. Pet Sitters on Profile enters the relevant filter directly. Directions, contact and inquiry should be obvious; a booking requires an explicit later confirmation.

Architecture proposal:

• Render a standard native map on the phone, with our own coordinate markers and local clustering/filtering.
• Use already-loaded PetPals directory data when opening the map or switching views. Panning does not automatically launch a paid business search. Offer Search this area.
• Evaluate licensed regional Overture Places data plus partner/business submissions as a directory seed. Test actual launch-region coverage before choosing it.
• Keep a stable PetPals business ID, source/provenance and provider mappings. Do not turn Google search responses into a permanent owned directory.
• Use bounded Firebase reads and local caches. Consider shared public regional summaries only if measured scale justifies them. Private sightings and user coordinates never enter public directory caches.

Current Google pricing lists unlimited free Maps SDK usage for standard native iOS/Android maps without a Map ID. Map IDs trigger a different paid map-load SKU. Places, routes, Firebase and media remain separate costs. Verify the actual development billing SKU before release. [1,2]

The first person in an uncovered area may trigger a deduplicated discovery/import job when opening Nearby, not during account creation. Show existing content promptly and explain incomplete coverage. Do not imply that bounded search results contain every business.

Detailed proposal: MAPS-ARCHITECTURE.txt. Provider selection and the exact read/cache design remain subject to review.

12. Business accounts, claims and reviews

Businesses represent real physical locations. Claim journey: find location → authenticated claimant → demonstrate authority → pending verification → approved, rejected or appeal. A PetPals claim is separate from Google Business Profile ownership. Prevent duplicate claims and keep verification evidence private.

Verified operators can manage permitted listing information, respond to inquiries, reply to PetPals reviews, publish promotions and request paid distribution. Initial verification and campaign support can be manually operated if adequately staffed.

PetPals owns its review system around PetPals business IDs. Reviews include author, rating/text, timestamps and moderation state; replies belong to verified business roles. Businesses can reply or report a review, not change the customer's words or delete unfavorable feedback. Trusted processing maintains eligible rating/count summaries.

Do not merge PetPals stars with Google ratings or imply a PetPals claim grants permission to reply to Google reviews. External provider content needs its own attribution and permitted-use handling.

Acceptance: an unverified claimant cannot take over a business; paying for promotion cannot change verification or review scores; duplicate business records can be reconciled without losing reviews or ownership history.

13. Shopping, points and rewards

Shopping introduces a curated set of useful partner products with real imagery, clear terms and a transparent destination. Start with a small supported catalogue rather than an unbounded marketplace. Sample graphics and point values must not be mistaken for approved inventory, prices or earned balances.

DNA cups — confirmed launch requirement

The user confirmed an existing paid partnership: customers must be able to buy DNA cups from launch. A promotional tile, points-only reward or interest form does not satisfy this requirement. The partner name, exact product, prices, commercial terms and operational responsibilities still need confirming; no provider or financial arrangement is assumed here.

Required journey: Shopping → DNA cup product details → quantity and delivery details → review full cost → pay → verified order confirmation → order status and support. An agreed partner-hosted checkout can fulfill this journey if the handoff and confirmation are reliable; the checkout owner is still to be decided.

• Use partner-approved product imagery, descriptions, instructions and claims. Clearly identify the paid partnership and who sells, fulfills and supports the order.
• Show availability, currency, item price, any shipping/tax and the complete total before payment. Explain delivery estimates and cancellation/return/refund terms.
• A purchase does not require earned points. Discounts, point earning or redemption apply only if explicitly agreed with the partner.
• Distinguish payment pending, confirmed, failed and cancelled from fulfillment states. A checkout return alone cannot mark an order paid. Verify payment through the agreed provider and reconcile delayed confirmations.
• Retried payments or confirmations must not create duplicate charges or orders. Keep a stable order reference and a recoverable path after interruption.
• Provide confirmation, fulfillment/shipping updates where available, and a clear support contact. Handle unavailable stock, failed fulfillment and refunds with accountable owners, even if early operations are manual.
• If the partner requires kit/sample registration, support the correct pet for each kit, including households with several pets. Confirm collection, return and results-access instructions before launch. Do not imply that an in-app lab/results integration already exists.
• Track partner attribution and reconcile orders, payments, refunds and any agreed settlement obligations. The exact paid partnership arrangement remains a commercial decision to document.

Acceptance: a customer can complete a real supported DNA cup purchase at launch, receive a confirmed order reference and reach fulfillment/support. Failed or abandoned checkout does not claim success; retries cannot duplicate an order; the partner's required post-purchase steps are supported. Review product details, checkout, confirmation, order status and help in the storyboard before implementation.

Points and rewards

The complete reward journey is: eligible activity → pending/confirmed points → balance/history → offer and terms → redemption review → success or failure → fulfillment/support.

• Viewing an offer never spends points. Duplicate taps, sync retries and duplicate activity events cannot earn or redeem twice.
• Distinguish confirmed spendable points, pending activity and legacy balances awaiting reconciliation.
• Define eligible earning events, limits, exclusions and reversals before launch. Do not award points for every like, favorable review or opened share sheet by default.
• Preserve genuine legacy balances and obligations. Native points and the Flutter demo's Coin economy are not assumed to be interchangeable.
• A coupon issued is not an order fulfilled. A partner-checkout return is not proof of payment. Confirm the actual outcome before updating rewards or order status.
• The phone displays cached balances; trusted backend logic owns the ledger and redemption decisions.

Acceptance: every balance change has a reason and reference; insufficient balance/failure is recoverable; retries cannot double-spend; partner terms and support are visible before redemption.

14. Advertising and revenue

Support direct partner product placements, paid business/location promotion, promoted posts and a potential external ad-network lane. The provider mix, inventory priority and commercial model are open decisions. They should coexist within one understandable placement and disclosure model.

The DNA cup paid partnership is confirmed launch scope. Its product sales and order lifecycle are distinct from campaign placement and advertising delivery; the commercial terms remain to be documented.

Proposed disclosure: “Ad · Sponsored by [advertiser]”, prominent with the creative and retained after opening it. Do not rely on a logo or “Promoted” alone to explain payment. Specific launch-market and platform requirements need review before operation. [3,4]

Separate campaign, creative/version, moderation, funding/payment and delivery states. Successful payment is not approval; approval is not proof of delivery. Support budget/schedule limits, pause/end, rejection, exhaustion, refunds and reporting.

Private content cannot become advertising silently. Promoting a Friends-only or Only-me post requires deliberate approval of a public advertising version. Source edits, deletion or privacy changes must stop or re-review affected creative.

Requirements include Why this ad?, hide/report controls, frequency limits and a clear advertiser destination. Paid placement must be distinguishable from organic relevance, business verification and review ratings. Avoid advertising interruptions in missing-pet reporting; do not target on private messages, precise home/walk routes or missing-pet distress.

Paid missing-pet reach is a separate entitlement from commercial campaigns. Physical-product checkout, in-app promotional boosts and digital reach upgrades require separate purchasing-rule evaluation for each storefront; do not assume one payment provider handles them identically.

Acceptance: every paid impression carries its disclosure; paused/expired/exhausted campaigns stop serving; retries cannot duplicate charges; changing an ad budget cannot mint owner rewards or broaden private-post access.

15. Backend, privacy and cost requirements

Firebase and Google services are the chosen direction. Favor client-side presentation, local drafts, photo compression, loaded-result filtering and deliberate caching. Keep authorization, claim approval, review aggregates, point ledgers, purchase verification and notification audience selection authoritative on trusted services.

Conceptual records to preserve in later schema design: accounts and identity links; pets and ownership roles; routines and walk events; media derivatives; posts and audiences; friendships and blocks; conversations/messages; missing cases, sightings and reach entitlements; businesses, provider mappings, claims, reviews/replies; promotions/campaigns/creatives; partners, products/SKUs, orders/items, payment/provider references, fulfillment/shipping, refunds and support; partner-required kit registration and pet associations if applicable; reward ledger/redemptions; delivery jobs, moderation and audit events.

This is an entity checklist, not an approved collection layout. Use stable IDs, explicit ownership, lifecycle/version information and retry identifiers. Keep public summaries separate from private operational or location data.

For DNA cup commerce, trusted services verify payment, authorize order access, enforce price/availability rules and deduplicate provider events. Phones may cache product details and order summaries but cannot declare a purchase paid. Keep delivery addresses and any kit/results references private and distinct from public pet profiles or advertising audiences.

Native Firestore supports offline caching. A cache does not eliminate online read costs or establish complete/fresh coverage. Bound queries, paginate, avoid unnecessary listeners, cap media and show stale/pending states. Provider restrictions apply to phone storage as well as server storage. [5,6]

Do not fetch every user's position to the client for alert matching. Use a private consented eligibility index, fresh enough for the agreed alert semantics, with deduplicated outreach. Keep eligible, queued, accepted, delivered and opened counts distinct.

Define abuse controls, content moderation, account deletion/export, retention, access revocation and privacy-safe analytics before launch. Budget alerts are not hard cost caps; add request quotas and application-level limits where appropriate. Measure provider calls, database reads, cache hit rates and media/network usage separately.

16. Existing-user transition and source findings

Source reviewed: EHadnot007-beep/petpalsapp-company (current live-app source provided), Digital-Disconnections-LTD/petpals (Flutter mockup) and bytedance/monolith (research reference).

The supplied native checkout has build issues and referenced files that are absent. Several overlapping storage paths exist. These findings do not prove that features or balances are absent from the shipped app. Production user records have not been downloaded in this planning work.

Before rollout, reconcile the shipping binary/source and data contracts. Preserve account identity, all pets/media, friends/messages, walks/achievements, active missing cases, points, business accounts, listings/applications and outstanding reservations or payment obligations.

Use additive compatibility where possible, explicit legacy-ID mapping, reconciliation evidence, a limited pilot and rollback. Do not delete old collections or reset local points because the new app uses a cleaner model. A “Reserved” flag is not proof payment succeeded.

Acceptance: the migration plan names every retained record/obligation, defines recoverable failure paths and demonstrates that active users can continue their important tasks without recreating accounts or pets.

17. Validation and launch measures

Before release, verify complete journeys rather than isolated screens: onboarding/recovery, switching pets, walk capture/completion/sharing, grooming, friend privacy, message retries, missing report/sighting/reunion, directory inquiry, business claim, points/redemption and DNA cup purchase through verified confirmation, fulfillment and support. Exercise payment failures, interrupted checkout, delayed/duplicate provider events, unavailable stock, cancellations/refunds and the partner's required post-purchase steps.

Test offline and reconnect behavior, denied permissions, duplicate submissions, expired sessions, app interruption, text scaling, screen readers and both themes. Verify precise location never leaks through public posts, media metadata or shared caches. Verify real account authorization and deployed rules independently of prototype behavior.

Proposed product measures: successful onboarding/recovery; completed walks and grooming tasks; optional sharing completion; useful reward redemption/fulfillment; DNA cup purchase completion, fulfillment and support outcomes; missing-case publication and sighting completion; owner-confirmed reunions; directory-to-inquiry conversion; verified business participation; ad disclosure/reporting quality; crash-free use and cost per active user.

Baseline values and numerical targets are not established. Do not optimize engagement metrics at the expense of privacy, emergency usefulness or reward integrity.

18. Decisions needed next

• Approve the full storyboard, including the custom graphics pass and important error/permission states.
• Choose the first-release feature order and explicitly agree any simpler initial For You ranking before Monolith.
• Confirm launch region, minimum age, account providers/recovery and household/business role boundaries.
• Agree feed friendship/author semantics, views/likes definitions, week boundaries and notification behavior.
• Agree media/video limits, retention, grooming detail and interrupted-walk recovery.
• Choose directory seed/provider after a local coverage check; set freshness rules and a cost envelope.
• Define missing-alert recipient eligibility, stale-case handling, multiple alerts and any paid radius/price/duration/refund terms.
• Define the DNA partner's products/SKUs, prices, inventory, seller/payment arrangement, commercial terms, fulfillment, returns/refunds and support responsibilities, plus any required kit/sample/results workflow. DNA cup sales at launch are already decided.
• Confirm other partner inventory, earning/redemption rules and legacy balance reconciliation.
• Select initial paid-ad lane, disclosure/purchasing review, campaign billing model and manual operations staffing.
• Complete legacy source/data reconciliation and approve a staged migration plan.

19. Review materials and sources

Shared interactive storyboard: https://petpals.isnotreal.site/ Shared PRD reader: https://petpals.isnotreal.site/prd.html Custom graphics review: https://petpals.isnotreal.site/graphics.html Local working preview: http://127.0.0.1:8771/ Map architecture discussion: MAPS-ARCHITECTURE.txt Feature comparison: FEATURE-INVENTORY.txt Detailed source evidence: NATIVE-FEATURE-AUDIT.txt and FLUTTER-FEATURE-AUDIT.txt Setup/source notes: PLANNING-NOTES.txt (historical; this PRD supersedes its older design choices) Previous running PRD: archive/PETPALS-PRD-before-consolidation-2026-10-28.txt

Primary references checked during planning: [1] Google Maps pricing: https://developers.google.com/maps/billing-and-pricing/pricing [2] Map billing triggers: https://developers.google.com/maps/billing-and-pricing/sku-details#maps-sdk-ess-sku [3] FTC native advertising guidance: https://www.ftc.gov/business-guidance/resources/native-advertising-guide-businesses [4] Apple App Review Guidelines: https://developer.apple.com/app-store/review/guidelines/ [5] Firestore offline behavior: https://firebase.google.com/docs/firestore/manage-data/enable-offline [6] Google Places policy: https://developers.google.com/maps/documentation/places/web-service/policies [7] Overture Places and licensing: https://docs.overturemaps.org/guides/places/ and https://docs.overturemaps.org/attribution/

Review goal: agree the product journeys and release boundaries, resolve the decisions above, then convert this PRD into implementation contracts. No production backend or migration has been built as part of this storyboard.