Ship a Fan Offer Engine Before Marketing Has a CRM
Create a free account to upload your work. Your progress saves as a draft until you submit.
What You'll Be Doing
The Challenge
Envorso Sports runs the fan-facing platform (ticketing, website, and mobile app) for the Seattle Seawolves of Major League Rugby. The league itself has just come onto the platform, and other teams will onboard through the season. Ticketing, website, and mobile app are live with paying customers. CRM, marketing automation, personalization, and revenue operations (pricing and yield) are what gets built next, AI-native from the start, by you.
Here is the front office today. Each club and the league hold a large fan database: ticket transactions, web and app activity, shop purchases, and email engagement. The league's database is many times larger than any single club's, and almost none of it is used today. One salesperson calls season-pass holders. One marketer sends a broadcast email and sees who comes through. Nobody follows up on the fans who start a ticket purchase and walk away.
Your first feature: a fan offer engine, starting with cart win-back as its first trigger. Every day, some fans start a ticket purchase and abandon it, a stale cart. The team wants something that looks at stale carts, decides which fans are worth a win-back offer, picks the offer and the channel, and puts it in front of a marketer to approve, edit, or reject, instead of a dashboard that reports how many carts went stale.
Here is a sample of stale carts from the last 7 days. Read it carefully, it reflects the real data, including its rough edges.
| Cart ID | Fan ID | Team | Source | Match | Seats | Section | Section Sold % | Cart Value | Abandoned | Lifetime Tickets | Last Purchase | Shop Spend (12 mo) | Season Pass | Email Opt-In | Push Opt-In |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| C-1001 | F-204 | Seawolves | Web | Next home match (in 4 days) | 2 | Lower Bowl | 88% | $96 | 3 hrs ago | 14 | 21 days ago | $120 | No | Yes | Yes |
| C-1002 | F-511 | Seawolves | Web | Home match (in 18 days) | 4 | Upper Deck | 41% | $140 | 26 hrs ago | 0 | Never | $0 | No | Yes | No |
| C-1003 | F-092 | Seawolves | App | Next home match (in 4 days) | 1 | Lower Bowl | 88% | $58 | 70 hrs ago | 3 | 180 days ago | $35 | No | No | Yes |
| C-1004 | F-333 | Seawolves | Web | Next home match (in 4 days) | 6 | Club | 97% | $540 | 1 hr ago | 40 | 9 days ago | $410 | Yes | Yes | Yes |
| C-1005 | F-777 | Seawolves | Web | Home match (played 2 days ago) | 2 | Upper Deck | 63% | $70 | 96 hrs ago | 1 | 300 days ago | $0 | No | Yes | No |
| C-1006 | F-204 | Seawolves | App | Next home match (in 4 days) | 2 | Lower Bowl | 88% | $96 | 2 hrs ago | 14 | 21 days ago | $120 | No | Yes | Yes |
| C-1007 | F-618 | League team (onboarding) | Web | Their home match (in 9 days) | 3 | Sideline | 55% | $105 | 30 hrs ago | 2 | 60 days ago | Not synced | No | Yes | No |
| C-1008 | Guest (no Fan ID) | Seawolves | Web | Home match (in 18 days) | 4 | Upper Deck | 41% | $140 | 5 hrs ago | Unknown | Unknown | Unknown | No | Yes | No |
Data notes: Match is the match the cart was for, relative to today. Section Sold % is that section's sell-through for that match. C-1008 is a guest checkout, its email address matches the account for F-511.
What to Deliver
- The engine: a proof-of-concept that processes the stale carts and, for each fan worth acting on, proposes a specific offer (for example a promo code, a season or match pass, a merch add-on, a seat upgrade, or a reminder-only nudge), the channel (email or in-app/push), and a stated reason. Not every cart should produce an offer. Use AI where it earns its place, deciding what should be rules and what should be a model call is part of the task.
- The surface: a web UI in TypeScript (React/Next.js patterns, a single component or small app is fine) where a marketer sees each proposed offer and approves, edits, or rejects it before anything reaches a fan. A JSON dump is not sufficient.
- The README and video walkthrough, see File Upload Requirements below.
Constraints to Consider
- No CRM or marketing automation exists. Delivery is a transactional email provider and our mobile app's in-app/push messaging. You can stub both, but your design has to work with nothing else, no Salesforce, HubSpot, or Braze.
- TypeScript is the stack. The web app is Next.js and the services are TypeScript. Explore in anything you like, but what you'd ship runs in TypeScript.
- You are the first in-house engineer. A five-engineer team in Argentina works overlap hours on the rest of the platform. There is no ML or ops team, whatever monitoring this needs, you design.
- First step ships in one sprint for the Seawolves. Other teams in the league come onto the platform this season. Scope accordingly.
- A wrong send costs real money and fan trust. The fan base is small and loyal. An offer to the wrong fan, through a channel they opted out of, or twice, is a bigger cost here than at a large e-commerce site. This cannot fail silently.
- Offer guardrails: promo codes are single-use and capped at 15% off.
On Using AI
We expect you to use AI tools. We evaluate how you use them, not whether you use them. Evidence of iteration, redirection, and critical evaluation scores higher than a polished output with no process documentation.
This includes agentic development. If you use coding agents, show how you scoped each task, the guardrails you gave them (for example a spec or tests), and what you rejected or changed on review.
The single highest-signal indicator: your video answer to the mandatory AI question. If you cannot name a specific moment where you redirected AI output, evaluators will assume you did not.
Mandatory AI question for your video: Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you, and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.
Speak naturally. Communication is assessed on clarity of technical ideas and logical structure, not verbal polish, accent, or filler words. This role works closely with team front offices, so assume a team's marketer is watching alongside an engineer.
Submission
Upload each deliverable as a separate file directly on the Provn platform: your code, your README document (Sections A, B, and C), and your video walkthrough (MP4 or MOV).
What You'll Accomplish
Design a fan data and offer pipeline that holds up in production, not just on sample data
Ship an end-to-end feature in TypeScript, from data to a surface a non-technical user acts on
Turn a front-office revenue problem into offer logic and a scoped first release
Use yield and commerce signals to decide when an offer earns revenue and when it gives revenue away
Make and record scoping decisions independently under ambiguity
Use AI tools and coding agents critically: direct them, check them, and own what ships
How Your Work Will Be Scored
What to Submit
Engine + UI Code
Format: .zip, .tar, .gz, .bz2, .7z, .rar
Your working proof-of-concept: the logic that decides which fans get which offer through which channel, plus the UI where a marketer reviews and acts on the proposals. Runnable or clearly readable is sufficient, production hardening is not expected.
Sign in to upload files
README Document
Format: .pdf, .doc, .docx, .rtf, .txt, .md
Three required sections.
Section A, Written analysis (300 to 500 words): how you decided which fans get an offer, the offer and channel logic you used and why, what you deliberately did not build yet, and what you would ship next. Stale carts are the first trigger: in a few sentences, explain how a second trigger (a season-pass holder who has not renewed, or a shop buyer who has never bought a ticket) plugs into your design without a rewrite.
Section B, Production Plan. Two parts. Part B1: how you would know this engine's offers are actually good (not just "it ran without errors"), what could make it send something bad without anyone noticing, and how you would catch that before it reaches a fan. Part B2, Required reasoning question (answer without AI assistance): Describe a scenario where an AI coding assistant would give you a plausible but incorrect answer for this type of problem, and explain specifically how you would catch it. What would the incorrect output look like, and what would you check to identify the error before acting on it?
Section C, AI Usage Log (Mandatory): This is not a trick. We want to see how you work with AI, not whether you used it. In a short section of your README, document your AI collaboration process. For each significant interaction with an AI tool, briefly note: what you asked the AI to help with, what it gave you, what you kept, changed, or rejected, and why. Three interactions documented is sufficient. The log does not need to be exhaustive. If you used coding agents, include at least one agent task: what you asked it to build, the guardrails you set, and what you rejected on review.
Sign in to upload files
Video Walkthrough
Format: .mp4, .mov, .webm
Cover: (1) summary of the problem and what you built, about 60 seconds; (2) demo of the engine and the UI, and the design decisions behind them, 2 to 4 minutes; (3) your Production Plan from Section B, 1 to 3 minutes; (4) the mandatory AI question (see On Using AI above), 1 to 2 minutes; (5) what you would do differently with more time, 30 to 60 seconds. Speak naturally. Communication is assessed on clarity of technical ideas and logical structure, not verbal polish, accent, or filler words.
Sign in to upload files
Create a free account to upload your work. Your progress saves as a draft until you submit.
On this page