# Teleton Peru Raffle Web App: Requirements Specification

## Summary
This specification reads both verbatim voice notes from Rodrigo Nores and turns them into an implementable requirements set for a mobile-first Next.js raffle web app for Teleton Peru. It covers the full purchase flow (register, pre-payment upsell, payment, confirmation email, database capture, draw), the two raffle events (an end-of-August warm-up of about 5 prizes and the main raffle of about 10 prizes on September 12, 2026), and the two pricing framings that conflict inside a single audio. The central unresolved item is pricing: the audio states both an "S/10 base plus S/5 then S/5" model and an "S/5 base plus S/5, S/10, S/15 upsell" model, and this must be resolved with Rodrigo before build. A second fork, returning-buyer recognition by phone or email versus a flat-price repeat, is also analyzed with a recommendation. Because this handles real money, real personal data, and a national charity's reputation, the spec biases hard toward trust, fairness, auditability, accessibility, and compliance with Peru's data law.

## Body
## 0. Scope and grounding

This document is grounded strictly in the two verbatim transcripts (audio 1 and audio 2 from Rodrigo Nores) plus the project brief. Anything not stated in those sources is marked `[inferred]` and is a candidate for confirmation, not a fact. Quotes below are lifted verbatim from the transcripts.

Two raffle events are in scope:

- Raffle 1 (warm-up): "Una primera rifa de unos cinco premios a finales de agosto, como para ir generando viralidad." About 5 prizes, end of August 2026.
- Raffle 2 (main): "una siguiente rifa ya principal, que haya unos diez premios el 12 de septiembre." About 10 prizes, September 12, 2026.

Prizes: "aparatos electronicos, televisores, vales de consumo" and explicitly "sujeto a lo que las empresas nos puedan dar." So prize lists are not final and must be data-driven, not hardcoded.

Distribution channels named: Instagram, TikTok, lives, posts. A dedicated influencer ("un representante de la rifa, que lo mueva, que sea como el influencer principal") will drive traffic. This is the source of the viral-spike load profile.

Surface: "Buscamos que sea un landing aparte, que posiblemente lo insertemos en la web." So a standalone landing that may later be embedded into teleton.pe.

---

## 1. Functional requirements

### 1.1 Registration

Source: "la persona se inscribe, dice 'Rodrigo Nores, voy a participar con cinco soles'." And "las personas se puedan poner su nombre."

- FR-1.1.1 A visitor can register with at minimum a name and a contact. Transcript 2 names the contact candidates explicitly: "por el numero del celular o el correo."
- FR-1.1.2 Registration is the first step of the purchase flow, before any payment. The base entry is selected at this step (one chance at the base price).
- FR-1.1.3 The form must be mobile-first and short. Field list and rationale are in Section 4.
- FR-1.1.4 The form must show and require acceptance of terms and conditions and a personal-data consent checkbox before proceeding to payment. `[inferred]` from the legal nature of a paid national raffle; not stated in the audio but mandatory under Peru law (Section 5).

### 1.2 Pre-payment upsell

Source: "Previamente le puede salir 'quieres ganar una opcion mas por cinco soles, o dos opciones mas por 10 soles, o tres opciones mas por 15', como que les salga ahi una opcion. Si quiere lo marca, si quiere no."

- FR-1.2.1 After registration and before redirect to the payment platform, the user is offered additional chances as an optional upsell.
- FR-1.2.2 The upsell is genuinely optional ("Si quiere lo marca, si quiere no"). The user can decline and proceed with the base entry only.
- FR-1.2.3 The upsell tiers and their prices are governed by the pricing model chosen in Section 2. They must be configuration, not hardcoded, because the audio itself states two different tier structures.
- FR-1.2.4 The selected total (base plus any upsell) must be computed server-side and carried into the payment request as a single authoritative amount and chance count. The client must not be trusted to send the price.

### 1.3 Entry and ticket purchase

Source: "que valga 10 soles la rifa, y que si ellos quieren tener una oportunidad es esa." Also the database intent: "La idea es que eso vaya a una base de datos."

- FR-1.3.1 A purchase yields one or more raffle chances. The number of chances is the unit that enters the draw, not the number of payments. One payment can buy multiple chances.
- FR-1.3.2 Each chance must be individually represented for the draw so that buying N chances gives N independent entries in the pool. `[inferred]` mechanism: one row per chance, or one purchase row with a chance count expanded at draw time. Recommendation in Section 1.7.
- FR-1.3.3 A chance is valid only when its payment is confirmed (Section 1.4 and 1.6). Unpaid or pending entries must never enter the draw.

### 1.4 Payment

Source: "te manda a una plataforma de pago" and "Luego lo manda a la plataforma de pago, realiza el pago."

- FR-1.4.1 The flow redirects to (or embeds) an external payment platform. The specific provider is not named in the audio and is an open decision (Section 6).
- FR-1.4.2 Payment must support the small-ticket amounts implied (single chances of S/5 or S/10). Fee drag on small tickets is a real concern and feeds the pricing recommendation (Section 2).
- FR-1.4.3 Payment confirmation must be received server-side via a provider webhook or server-to-server verification, not solely via the browser redirect back to the site. This is required for trust and reconciliation.
- FR-1.4.4 The system must handle the three payment outcomes: success, failure, and abandoned/timeout. A registration with no confirmed payment is a lead, not an entry, and must be clearly distinguished in the database.

### 1.5 Confirmation email

Source: "se le da la confirmacion tal vez a su correo para que lo tenga validado."

- FR-1.5.1 On confirmed payment, the system sends a confirmation to the buyer's email.
- FR-1.5.2 The confirmation should state the number of chances purchased, the amount paid, and which raffle event the entry belongs to. `[inferred]` content detail; the audio only says "confirmacion ... para que lo tenga validado."
- FR-1.5.3 Because email is the validation artifact and a contact channel, email capture is effectively required even though the audio lists phone "o" email as alternatives. See Section 4 for the resolution of this tension.
- FR-1.5.4 `[inferred]` A WhatsApp or SMS confirmation is not requested in the audio. Email is the only confirmation channel named. Do not build SMS/WhatsApp confirmation unless Rodrigo asks.

### 1.6 Database capture

Source: "La idea es manejar una base de datos" and "a nosotros ya nos llega a nuestra base de datos para luego hacer el filtro" and "para que luego el sorteo se vea de forma sencilla, que no haya una mayor complicacion."

- FR-1.6.1 Every confirmed purchase is persisted with the buyer identity, the chances bought, the amount, the event, the payment reference, and timestamps.
- FR-1.6.2 The data model must make "el filtro" (the draw selection) simple and defensible. Rodrigo explicitly wants the draw to be simple to run: "que no haya una mayor complicacion."
- FR-1.6.3 The database must distinguish confirmed entries from incomplete registrations and from failed payments, so the draw pool is unambiguous.
- FR-1.6.4 Admin export is `[inferred]` but strongly implied by "hacer el filtro" run by "nosotros." Provide a clean export of confirmed entries per event for the draw.

### 1.7 Returning-buyer recognition

Source (audio 2): "yo un dia me inscribo la rifa, pago mis 10 soles, y otro dia quiero tener mas posibilidades de ganar. Entonces tendria que haber una forma de que se sepa que ya me inscribi, no se, por el numero del celular o el correo, de manera que le salgan las opciones que esa persona tiene. No se si eso es sencillo, sino ahi podemos ver una forma mas simple donde no haya variedad: cada opcion es un mismo precio y sigue el proceso regular."

- FR-1.7.1 The system should let a person who already registered come back later and buy more chances.
- FR-1.7.2 Rodrigo offers two paths and is explicitly unsure which is feasible. Fork A: recognize the returning person by phone or email and show them "las opciones que esa persona tiene." Fork B: drop recognition entirely, make "cada opcion es un mismo precio," and just repeat the normal process.
- FR-1.7.3 This fork is analyzed in Section 3 with a recommendation. The data-model choice in FR-1.3.2 should not block either fork: store one identity keyed by phone/email, and one purchase record per transaction, so accumulated chances per person are computable whether or not the UI surfaces them.

### 1.8 The draw and winner selection

Source: "para luego hacer el filtro" and "el sorteo se vea de forma sencilla."

- FR-1.8.1 The draw selects winners from the pool of confirmed chances for a given event. Each chance is one entry; more chances mean proportionally higher odds.
- FR-1.8.2 `[inferred]` The number of winners per event maps to the prize count (about 5 for the warm-up, about 10 for the main raffle), one winner per prize unless Rodrigo specifies otherwise. The audio does not state the winner count, only the prize count.
- FR-1.8.3 The selection method must be reproducible and auditable. Given Teleton's public reputation, the draw should be defensible: a documented method, a recorded random seed or a witnessed live draw, and a frozen entry snapshot at draw time. `[inferred]` mechanism; the audio only requires that it be "sencillo."
- FR-1.8.4 Whether the draw is executed in-app or exported and drawn manually/live is an open decision (Section 6). A live, on-camera draw aligns with the "hacer live" distribution plan and maximizes perceived fairness. `[inferred]`.
- FR-1.8.5 The system must prevent a single chance from being selected for two prizes in the same event (draw without replacement) unless Rodrigo wants otherwise. `[inferred]`.

### 1.9 The two separate raffle events

- FR-1.9.1 The app must support two distinct events with separate prize sets, separate entry pools, separate open/close windows, and separate draws.
- FR-1.9.2 An entry belongs to exactly one event. A buyer in August does not automatically have chances in September. `[inferred]` but consistent with "una primera rifa" and "una siguiente rifa ya principal" being described as separate events.
- FR-1.9.3 Model the event as configuration (name, dates, prize list, pricing, open/close window) so the same codebase runs both raffles and future ones without a rebuild. This directly serves "sujeto a lo que las empresas nos puedan dar" (prizes change) and the two-event structure.

---

## 2. The pricing ambiguity (must be resolved with Rodrigo)

The single audio states two different pricing structures. Both are quoted here verbatim.

Framing A, stated first:

> "Pensamos, por ejemplo, que valga 10 soles la rifa, y que si ellos quieren tener una oportunidad es esa, pero si quieren dos oportunidades mas, cinco soles mas, tienes dos oportunidades mas, otros cinco soles mas, tres oportunidades."

Read literally, Framing A is: base S/10 for 1 chance. Plus S/5 for 2 more chances (running total S/15 for 3 chances). Plus another S/5 for what the audio calls "tres oportunidades" (running total S/20). Note the internal inconsistency even within Framing A: the last step says "otros cinco soles mas, tres oportunidades," which could mean 3 additional chances for the third S/5 increment, or a cumulative total of three. This is ambiguous on its face.

Framing B, stated a few sentences later in the same audio:

> "voy a participar con cinco soles ... Previamente le puede salir 'quieres ganar una opcion mas por cinco soles, o dos opciones mas por 10 soles, o tres opciones mas por 15'."

Read literally, Framing B is: base S/5 for 1 chance. Upsell options are: 1 more chance for S/5, OR 2 more chances for S/10, OR 3 more chances for S/15. That is a flat S/5 per chance with no volume discount, presented as pick-one upsell tiers.

The two framings disagree on the base price (S/10 vs S/5) and on whether extra chances are discounted (Framing A bundles, Framing B is flat S/5 each). This must be resolved before build. Below are three clean models.

### Option 1: Flat per-chance (recommended)

One chance equals one fixed price. The "upsell" is just choosing a quantity. This matches Framing B's economics (S/5 buys 1 chance, S/10 buys 2, S/15 buys 3).

| Aspect | Assessment |
|---|---|
| Conversion | Simplest to understand. "S/5 por chance, mientras mas compres mas chances tienes." Low cognitive load, which fits the "agil" and "jugueton" brief. |
| Payment-fee drag | Worst case at the S/5 single-chance minimum, where fixed per-transaction fees eat the largest percentage. Mitigated by nudging quantity at the upsell step. |
| Clarity and fairness | Highest. Price per odds is transparent, which protects Teleton's reputation. Easy to explain on a live. |
| Build | Simplest. One price constant per event, quantity selector, amount equals price times quantity. |

### Option 2: Base plus bundle-upsell (volume discount)

A base price for the first chance, then discounted bundles for more (this is the literal reading of Framing A: S/10 for 1, then S/5 for 2 more, so the 2nd and 3rd chances are cheaper per chance than the first).

| Aspect | Assessment |
|---|---|
| Conversion | The bundle ("2 mas por solo S/5") is a strong upsell lever and raises average order value. Matches Framing A intent. |
| Payment-fee drag | Better than Option 1 because it pushes larger single transactions, spreading the fixed fee across more chances. |
| Clarity and fairness | Lower. A discount on odds is harder to explain and can read as "pagar menos por mas chances," which a journalist or skeptic could frame as unfair to single-chance buyers. Needs careful copy. |
| Build | Moderate. Tiered pricing table per event, careful handling of the "2 more / 3 more" semantics that the audio left ambiguous. |

### Option 3: Tiered packages (pick-one, no running addition)

Sell named packages: 1 chance for S/X, 3 chances for S/Y, 5 chances for S/Z. The buyer picks exactly one package. This removes the additive ambiguity in both framings.

| Aspect | Assessment |
|---|---|
| Conversion | Clean, very common, easy to anchor (a middle package looks like the best value). Good for "jugueton" presentation. |
| Payment-fee drag | Best, because the smallest package can be set above the fee-pain threshold and larger packages are encouraged. |
| Clarity and fairness | High, as long as the odds math per package is shown. No running-total confusion. |
| Build | Moderate. A package list per event; the draw still counts chances. |

### Recommendation

Adopt Option 1 (flat per-chance at S/5) for the warm-up raffle. It is the cleanest to explain on a live, the easiest to build under time pressure, the fairest on its face for a charity, and it matches the most recent framing in the audio (Framing B). Present the upsell exactly as Rodrigo described it ("1 mas por S/5, 2 mas por S/10, 3 mas por S/15"), which is flat pricing dressed as tiers. Keep price-per-chance and the upsell tiers as event configuration so that if Rodrigo prefers a volume discount (Option 2) or packages (Option 3) for the September main raffle, it is a config change, not a rebuild. Whatever is chosen, set the single-chance minimum with the payment provider's per-transaction fee in mind, because at S/5 a flat fee plus percentage can consume a meaningful share of each ticket. Confirm the exact fee schedule with the chosen provider before locking the base price.

---

## 3. The returning-buyer fork (recognize vs flat-repeat)

Rodrigo himself frames this as a fork and flags uncertainty about feasibility (audio 2, quoted in 1.7).

### Fork A: recognize by phone or email

The returning visitor enters their phone or email, the system finds their prior confirmed entries, shows "las opciones que esa persona tiene," and lets them add more chances.

- Data implications: requires a stable person identity keyed by phone and/or email, with all purchases linked to it. Requires a lookup-and-resume step in the flow. To prevent someone from viewing another person's entries by typing a stranger's phone number, recognition needs a lightweight verification (for example a one-time code sent to the email or phone) before showing any entry detail. That adds a step and a dependency (an email or SMS OTP sender) and a small amount of friction. `[inferred]` that verification is needed; the audio does not mention it, but showing a person's entry history to anyone who types their contact is a privacy problem on a charity site.
- Pros: better repeat-buyer experience, accumulates a richer per-person picture, supports messaging like "ya tienes 3 chances, suma mas."
- Cons: more build, an extra verification dependency, a larger privacy and data-protection surface (you are now displaying stored personal data on lookup, which raises the bar under Peru's data law).

### Fork B: flat-price repeat, no recognition (recommended)

Every chance is the same price and a returning buyer simply runs the normal flow again. Two purchases by the same person are just two purchase records that happen to share a phone or email.

- Data implications: still capture phone and email on every purchase (Section 4), so the same person's records can be reconciled later by matching contact fields, even though the UI never surfaces "your existing entries." This keeps the door open to add Fork A later without a data migration. No verification step, no OTP dependency, minimal privacy surface.
- Pros: fastest to build, no verification dependency, smallest privacy surface, exactly the fallback Rodrigo offers ("una forma mas simple donde no haya variedad"). The draw still correctly aggregates a person's chances because chances are counted per confirmed purchase.
- Cons: a returning buyer does not see their prior chances in the UI and could, in principle, lose track of how many they have. Acceptable for a short campaign.

### Recommendation

Ship Fork B for the warm-up. Capture phone and email on every purchase regardless, so post-hoc dedupe and a future "find my entries" feature remain possible. Use the warm-up to observe whether meaningful repeat-buying actually happens. If it does, build Fork A (with email/phone verification) for the September main raffle. This sequencing matches Rodrigo's own "si eso es sencillo, sino ... forma mas simple" framing and avoids committing to the harder build before there is evidence it is needed.

---

## 4. Exact data fields to capture at registration

The audio explicitly requires a name and a contact, and names phone and email as the contact and recognition keys ("por el numero del celular o el correo"). Email is also the confirmation channel ("la confirmacion tal vez a su correo"). The minimal, justified field set:

| Field | Required | Source / rationale |
|---|---|---|
| Full name (nombre completo) | Yes | "las personas se puedan poner su nombre." Needed to identify a winner and to personalize the confirmation. |
| Mobile phone (numero de celular) | Yes | Named in audio 2 as a recognition key. Also the most reliable contact in Peru and the backup for prize handoff. |
| Email (correo) | Yes | Named in audio 2 as a recognition key, and named in audio 1 as the confirmation channel. Even though the audio says phone "o" email, email is functionally required because it is the validation artifact (FR-1.5). Recommend capturing both rather than one-or-the-other, to keep recognition and confirmation both reliable. |
| Number of chances selected | Yes (derived) | The base chance plus any upsell selection. Drives the payment amount and the draw weight. |
| Event identifier | Yes (system-set) | Which raffle (August warm-up vs September main) this entry belongs to. Set by the system, not the user. |
| Terms-and-conditions acceptance | Yes | `[inferred]` Legal requirement for a paid raffle. Store the fact, version, and timestamp of acceptance. |
| Personal-data consent (Ley 29733) | Yes | `[inferred]` Required to lawfully store and process the contact data and to email the buyer. Store consent fact and timestamp. |
| Marketing-contact consent | Optional, separate checkbox | `[inferred]` If Teleton wants to message participants beyond this raffle, that must be a distinct, opt-in consent, not bundled with the mandatory data consent. |
| UTM / channel source | Optional (system-captured) | `[inferred]` Not in the audio, but Rodrigo plans heavy Instagram, TikTok, and influencer pushes. Capturing the referring channel lets Teleton measure which channel and which influencer post drove entries. Low cost, high value, no extra user friction. |

Fields deliberately NOT collected at registration:

- DNI (national ID): not requested in the audio. Collecting it from every buyer is an unnecessary data-protection liability. `[inferred]` Recommendation: collect DNI only from actual winners, at prize-handoff, when identity verification is genuinely needed.
- Postal address, birthdate: not in the audio. Do not collect. Age targeting (22 to 38 and 35 to 50) is a marketing-message strategy, not a data field to collect, unless a minimum-age legal requirement forces an age gate (open question in Section 6).

Principle: capture the minimum that the flow and the law require. Every extra field lowers mobile conversion and raises breach liability for a charity.

---

## 5. Non-functional requirements

### 5.1 Mobile-first

Source: "Vamos a mover mucho las redes sociales ... el Instagram, el TikTok, hacer live, post."

- NFR-5.1.1 The entire flow must be designed for a phone first: large tap targets, single-column, minimal typing, numeric keypad for phone, a payment step that works inside in-app browsers (Instagram and TikTok open links in their own webviews, which can break some redirect and cookie flows). `[inferred]` that in-app webview compatibility matters; it follows directly from the named channels.
- NFR-5.1.2 The landing must load fast on mobile data. Static, CDN-cached landing content; defer heavy assets.
- NFR-5.1.3 The flow must survive the payment redirect returning into an in-app webview. Test the full purchase inside the Instagram and TikTok in-app browsers before launch.

### 5.2 Viral-spike scalability

Source: the influencer ("representante de la rifa") plus lives create sharp, bursty traffic.

- NFR-5.2.1 The read path (landing, prize display) must be statically generated and CDN-cached so a traffic spike from a single live or post does not hit application servers for every view.
- NFR-5.2.2 The write path (registration, payment initiation, webhook handling) must be thin and idempotent. Payment-confirmation webhooks must be idempotent so a retried webhook never double-credits chances.
- NFR-5.2.3 The system must enforce that the chance count and amount are computed and validated server-side, so spikes cannot be exploited to submit manipulated prices.
- NFR-5.2.4 Load-test at the expected peak (estimate the influencer's reachable audience and a realistic conversion burst) before the end-of-August launch. The August warm-up is itself the load test for September; instrument it.
- NFR-5.2.5 `[inferred]` Add basic abuse protection on the registration and payment-initiation endpoints (rate limiting, bot mitigation) since a public, money-handling form under heavy promotion is a spam and fraud target.

### 5.3 Trust, fairness, and auditability

Driven by the project rule that this handles real money and a national charity's reputation.

- NFR-5.3.1 A chance counts in the draw only if its payment is confirmed server-side. No unpaid or pending entry may ever enter the pool.
- NFR-5.3.2 Every confirmed entry must be reconcilable to a payment-provider transaction (store the transaction ID and status). Teleton must be able to reconcile total entries against total money received.
- NFR-5.3.3 The draw must be reproducible and documented: a frozen snapshot of confirmed entries at draw time, a recorded method (seed-based RNG or a witnessed live draw), and an exportable winners record. This protects Teleton if any participant disputes the result.
- NFR-5.3.4 The public-facing copy must state the odds mechanic honestly (more chances means higher but not guaranteed odds) to avoid any deceptive-promotion exposure for a charity.
- NFR-5.3.5 `[inferred]` Keep an append-only log of entry creation and payment status changes for audit. Do not allow silent edits to confirmed entries.

### 5.4 Accessibility

Teleton serves people with disabilities, so accessibility is a brand imperative, not a nice-to-have.

- NFR-5.4.1 Target WCAG 2.1 AA across the entire flow: semantic HTML, correct heading order, labeled form fields, sufficient color contrast, visible focus states, and full keyboard operability.
- NFR-5.4.2 The flow must be operable with a screen reader end to end, including the upsell selection and the payment redirect and return. Verify with at least one screen reader on mobile.
- NFR-5.4.3 Do not encode meaning in color alone (for example selected upsell tiers must be distinguishable without relying on color).
- NFR-5.4.4 Respect reduced-motion preferences; any playful animation must degrade gracefully.
- NFR-5.4.5 Form errors must be announced and clearly described in text, not shown only as a color change.
- NFR-5.4.6 `[inferred]` This is the highest-leverage reputational requirement: a Teleton raffle that is not accessible to people with disabilities would be a brand contradiction. Treat an accessibility pass as a launch gate, not a follow-up.

### 5.5 Localization: Spanish (Peru) only

- NFR-5.5.1 All copy is Spanish, Peruvian register (tu, eres, quieres, cuentame, dime, aqui, mira). No voseo anywhere (no vos, no sos, no queres, no contame, no aca).
- NFR-5.5.2 Money is shown in soles as S/ followed by the amount (for example S/5, S/10).
- NFR-5.5.3 No second language is in scope. Do not build i18n machinery beyond a single Spanish (Peru) locale unless asked.
- NFR-5.5.4 Tone per the brief: keep Teleton's supportive, impact-driven message but make it more cercano, jugueton, a bit of comedy, modern, to reach beyond the existing Teleton community. The two audiences (22 to 38 motivated by the prize, 35 to 50 motivated by the cause) are a messaging concern, handled with copy and creative, not separate flows. `[inferred]` that a single flow serves both; the audio does not ask for two separate funnels.

### 5.6 Embeddability and deployment surface

- NFR-5.6.1 Built as a standalone landing ("un landing aparte") on the mandated Next.js stack, with the option to later embed into teleton.pe ("posiblemente lo insertemos en la web").
- NFR-5.6.2 `[inferred]` Decide early whether "insertar en la web" means an iframe embed or a subdomain/subpath under teleton.pe, because that choice affects cookie, payment-redirect, and analytics behavior. Flagged as an open decision (Section 6).

---

## 6. Decisions needed from Rodrigo or the client side

These are the explicit blockers and choices that the build cannot resolve internally. Numbered for reference in client communication.

1. Pricing model and exact prices. Resolve the two conflicting framings in the audio (S/10 base plus S/5 then S/5, versus S/5 base plus S/5, S/10, S/15 upsell). Confirm the base price, whether extra chances are flat-priced or discounted, the exact upsell tiers, and whether there is a maximum number of chances per person.
2. Returning-buyer fork. Confirm Fork A (recognize by phone or email and show existing chances) versus Fork B (flat-price repeat, no recognition). The recommendation is Fork B for the warm-up. Rodrigo flagged this himself as a feasibility question.
3. Payment platform. Which provider (and therefore which fee schedule and which payment methods, for example card, Yape, Plin, bank transfer)? This drives the minimum viable single-chance price and the in-app-webview behavior. Not named in the audio.
4. Winners per event. The audio gives prize counts (about 5, about 10) but not winner counts. Confirm one winner per prize, and whether one person can win more than one prize in the same event.
5. Draw mechanism and timing. In-app automated draw versus exported list drawn live on camera (the latter aligns with the "hacer live" plan). Confirm the exact draw date/time for each event and who runs it.
6. Prize list and prize fulfillment. Final prizes are "sujeto a lo que las empresas nos puedan dar." Confirm how prizes are displayed when not yet finalized, who handles winner contact and prize delivery, and what data (DNI, address) is collected from winners at handoff.
7. Embedding strategy for teleton.pe. Iframe embed versus subdomain/subpath. This affects payment redirect, cookies, and analytics.
8. Email sending. Which email service sends the confirmation, and from which Teleton-controlled domain (for deliverability and trust). The audio says email confirmation but names no sender.
9. Legal and consent copy. Who supplies the official terms and conditions, the privacy notice, and the data-consent language for compliance with Peru's Ley 29733? Is there any minimum-age requirement or age gate for participation? Are there any raffle or promotion permits required for a paid national raffle in Peru that must be referenced on the page?
10. Internal approvals and timeline. The audio states pending approvals: "reunirnos con el equipo de comunicaciones, con Sergio para la aprobacion, reunirnos con las marcas para los productos." Confirm the dates these approvals and brand deals are expected to close, since the end-of-August launch depends on them.
11. Analytics and channel attribution. Confirm whether Teleton wants per-channel and per-influencer attribution (UTM capture, dashboard). Recommended and low-cost, but not requested in the audio.
12. Data ownership and retention. Confirm where the "base de datos" lives, who owns it, who can export it, and how long participant data is retained after each draw.

## Recommendations
- **Resolve the pricing ambiguity before any build, and adopt flat per-chance pricing (Option 1, S/5 per chance) for the August warm-up, with price-per-chance and upsell tiers stored as event configuration.**: The single audio states two conflicting models (S/10 base plus S/5 bundles, versus S/5 base with S/5/S/10/S/15 upsell). Flat per-chance is the cleanest to explain on a live, the fairest on its face for a charity, the easiest to build under deadline, and it matches the most recent framing in the audio. Keeping it as config lets September switch to a volume discount or packages without a rebuild.
- **Ship Fork B (flat-price repeat, no live recognition) for the warm-up, while capturing phone and email on every purchase so the data supports adding recognition later.**: Fork B is exactly the simpler option Rodrigo offers, removes an OTP/verification dependency, and minimizes the privacy surface under Peru's Ley 29733. Capturing the keys now keeps the upgrade path to Fork A open without a data migration, and the warm-up will cheaply reveal whether real repeat-buying justifies the harder build.
- **Make a raffle chance count in the draw only on a server-side, webhook-confirmed, settled payment, store one auditable record per purchase with its transaction ID and status, and freeze an entry snapshot with a documented method at draw time.**: This handles real money and a national charity's reputation. Trusting the browser redirect or admitting pending payments would let unpaid entries into the pool and make results indefensible. Reconcilable, snapshot-based draws protect Teleton if any participant disputes fairness and satisfy the auditability requirement.
- **Collect only name, phone, and email at registration plus explicit terms and data-consent checkboxes; collect DNI only from actual winners at prize handoff.**: The transcripts only require a name and a contact (phone or email). Over-collection (DNI, address, birthdate) is a direct liability under Ley 29733 and adds breach risk for no functional gain, while extra fields lower mobile conversion. Winner-time DNI collection covers the one moment identity verification is genuinely needed.
- **Build one event-configurable codebase, statically render and CDN-cache the landing, keep the write path thin and idempotent, and load-test at the influencer-driven peak before the end-of-August launch.**: Rodrigo plans lives and influencer pushes that produce sharp, bursty traffic. A cached static read path plus an idempotent webhook-driven write path keeps the site up during spikes without duplicate or lost entries, and modeling the raffle as data avoids a rebuild between the August warm-up and the September main raffle (whose prizes are still subject to brand deals).
- **Treat a WCAG 2.1 AA accessibility pass, verified with a mobile screen reader end to end including the payment redirect, as a launch gate rather than a follow-up.**: Teleton serves people with disabilities, so an inaccessible Teleton raffle would be a brand contradiction with real reputational cost. Making accessibility a gate, not a later fix, aligns the product with the organization's core mission and the brief's explicit trust-and-accessibility bias.

## Open Questions
- Pricing: which framing is correct (S/10 base plus S/5 bundles, or S/5 base with S/5/S/10/S/15 upsell), what is the exact base price and tier structure, and is there a maximum number of chances per person?
- Returning-buyer fork: confirm Fork B (flat-price repeat, no recognition) for the warm-up, or require Fork A (recognize by phone or email and show existing chances)?
- Payment platform: which provider, which methods (card, Yape, Plin, transfer), and what is the per-transaction fee schedule that sets the minimum viable single-chance price?
- Winners: how many winners per event (one per prize?), and can one person win more than one prize in the same event?
- Draw mechanism and exact date/time per event: automated in-app draw versus exported list drawn live on camera, and who executes it?
- Prize handling: how are not-yet-finalized prizes displayed, who contacts winners and delivers prizes, and what data (DNI, address) is collected from winners at handoff?
- Embedding: iframe embed into teleton.pe versus a subdomain/subpath, given the impact on payment redirect, cookies, and analytics?
- Email sending: which email service and which Teleton-controlled sending domain for the confirmation email?
- Legal: who supplies terms and conditions, the privacy notice, and Ley 29733 consent copy, is there a minimum-age requirement, and are any paid-raffle or promotion permits required in Peru?
- Approvals and timeline: confirmed dates for sign-off from the communications team and Sergio, and for closing the brand prize deals, given the end-of-August launch dependency?
- Analytics: does Teleton want per-channel and per-influencer attribution (UTM capture and a dashboard)?
- Data ownership and retention: where does the database live, who owns and can export it, and how long is participant data retained after each draw?

## Risks
- [high] The pricing ambiguity is not resolved before build, so the team either guesses wrong or stalls, and the upsell and payment amounts ship inconsistent with what Rodrigo intends.  -> FIX: Treat pricing as Decision 1, a hard blocker. Lock the model in writing with Rodrigo before any payment code, and implement price-per-chance and upsell tiers as event configuration so a late change is a config edit, not a rebuild.
- [high] A viral spike from an influencer live overwhelms the write path or causes duplicate/lost entries via retried payment webhooks, taking the site down or corrupting the entry pool at the worst moment for a charity.  -> FIX: Statically render and CDN-cache the read path, make registration and webhook handling thin and idempotent, add rate limiting, and load-test at the estimated peak. Use the August warm-up as an instrumented dress rehearsal for September.
- [critical] Unpaid, pending, or abandoned registrations leak into the draw, or the draw is not reproducible, so a participant or journalist can credibly allege the raffle was unfair, damaging Teleton's national reputation.  -> FIX: Count only server-confirmed, settled payments as chances, reconcile every entry to a transaction ID, freeze an entry snapshot at draw time, and use a documented, witnessed or seed-based draw method with an exportable winners record.
- [high] Personal data (and any over-collected fields like DNI or address) is mishandled or breached, violating Peru's Ley 29733 and exposing Teleton to legal and reputational harm.  -> FIX: Collect only name, phone, and email at registration with explicit consent and timestamps, defer DNI to winner handoff, encrypt data at rest and in transit, restrict export access, and confirm a retention policy. Have Teleton supply compliant privacy and consent copy.
- [high] The flow breaks inside Instagram and TikTok in-app browsers (payment redirect, cookies, or return step fails), so traffic from the primary distribution channels cannot complete a purchase.  -> FIX: Design the payment step for in-app webview compatibility and test the full purchase end to end inside the Instagram and TikTok in-app browsers on real devices before launch.
- [medium] The product is not accessible to people with disabilities, contradicting Teleton's core mission and creating a visible brand contradiction.  -> FIX: Make WCAG 2.1 AA a launch gate, build semantic and keyboard-operable forms, verify the full flow including the payment redirect with a mobile screen reader, and do not rely on color alone for meaning or errors.
- [medium] Client-side dependencies slip: communications-team and Sergio approvals, or the brand prize deals, are not closed in time, jeopardizing the end-of-August launch.  -> FIX: Surface these as explicit timeline decisions, build the prize list and pricing as configuration so the app is launch-ready independent of final prizes, and agree a date by which approvals and at least the warm-up prizes must be confirmed.
- [medium] Small single-chance tickets (for example S/5) suffer heavy payment-fee drag, so a large share of each ticket is lost to fees and net funds to Teleton are lower than expected.  -> FIX: Confirm the provider's fee schedule before setting the base price, nudge quantity at the upsell step, and consider setting the minimum chance or package price above the fee-pain threshold once fees are known.