Giftmaxxing

Tinder for gift taste — swipe to teach it yours, share a link to learn anyone else's, and never give a bad gift again.

Comment

Giftmaxxing

Why Track 1 (Monetizable B2C)

Giftmaxxing is a direct-to-consumer gifting product with a built-in revenue model: Amazon affiliate links on every recommendation, native sponsored placements ranked by the same taste model, and a take-rate on group-gift pools. It's a consumer social-commerce app aimed at a recurring, high-intent buying behavior — squarely the B2C / ecommerce / retail track.

Testing instructions (for judges)

  • Sign in with the test account so every feature (including Maxi, the AI concierge) works:
    • Email: judge+clerk_test@gmail.com
    • Password: judge123
    • Verification code always (if prompted): 424242
  • Most of the app (feed, swipe, recommendations, visual search, invite loop, pools) is browsable; Maxi requires a signed-in session, so please use the test login above to try it.
  • The app is free to use with no restrictions for evaluation through the judging period.
  • Group gifts are a coordination/pledge feature — the app records contributions and pool progress and simulate payments (by design).

Inspiration

This started with a very specific, very relatable problem: one of us panics on his girlfriend's birthday every year. Not because he doesn't care, but because he cares a lot, and her taste keeps evolving. What was perfect last year feels off this year, and there's no good way to keep up. The "solution" everyone falls back on is just asking "what do you want for your birthday?". This quietly ruins the whole thing. Nobody likes being asked. It kills the surprise and makes a thoughtful gesture feel like a transaction.

So the real problem isn't "find a gift." It's: how do you keep a living, up-to-date sense of someone's taste without ever interrogating them about it?

That reframing is the whole product. The core action, swiping on things you'd love to receive, quietly trains a taste model, and a shareable "swipe challenge" lets you capture someone else's evolving taste in ten seconds, no signup, no awkward questions. Zoom out and it's a universal pain: we open twenty tabs, forget dates, double-buy, and never really know the person we're buying for. Wishlists are dumb lists; marketplaces are generic search boxes; neither learns taste. We wanted the opposite. We wanted it on a data foundation (Amazon DynamoDB + Vercel) that could scale from day one to millions without a rewrite.

What it does

Giftmaxxing is a taste-driven social gifting network ("Pinterest × Instagram for gifts"). Here is the full feature set:

Core taste engine

  • Personalized feed: an infinite-scroll, Instagram/Pinterest-style feed of real gift-worthy finds, blended from a Reddit-mined gift-knowledge base and Pinterest pins, ranked per user by our recommendation engine.
  • Swipe-to-train deck: the signature interaction: "Would you want this gifted to you?" Each swipe is a taste signal written to Amazon DynamoDB (interactions table). A yes becomes a positive seed; a no drops the item from your feed. Recommendations sharpen in real time.
  • Recommendations ("Recs Lab"): your liked/swiped items' embeddings are averaged into a taste centroid, then matched by k-nearest-neighbor over Amazon S3 Vectors. When no vectors are available it transparently falls back to a facet ranker over DynamoDB (social proof + recipient/occasion/category + recency): the response even tags its source (vector vs facet).
  • Visual search ("Google Lens for gifts"): upload or snap a photo; we embed it with Amazon Bedrock Titan Multimodal Embeddings and return visually similar gifts via the same kNN index.

The growth + taste-acquisition loop

  • Share-a-challenge invite — send anyone a link; they swipe through the deck anonymously, with no signup and no form. From those swipes you instantly get a soft taste profile for them, so you know what to buy someone who never lifted a finger. They can claim the profile when they later sign in. This is simultaneously our viral growth mechanism and our taste-data engine.

Gifting for groups, occasions, and yourself

  • Group-gift pools: chip in toward one bigger gift for a birthday/graduation/farewell, with per-person contributions and a progress goal.
  • Live group chat: each pool has a real-time chat thread to coordinate, where Maxi can drop in shoppable suggestions.
  • Gift events & reminders: log the people you shop for and their important dates (birthdays, anniversaries); the feed biases toward the next occasion and surfaces reminders.
  • Self-gifting milestones: set a personal goal with a reward budget; when you complete it, treat yourself (or have Maxi pick something within budget).
  • Curated "Drops": themed gift packages that bundle several real-photo items around a target value.
  • Reddit-mined gift-knowledge explorer ("Ideas"): pick a recipient archetype (mom, partner, coworker…) and get ranked gift concepts people actually recommend, with real discussion evidence and co-occurrence bundles.

Maxi: the AI gift concierge

  • A real Amazon Bedrock agent with cost-aware model routing: it answers on a cheap Amazon Nova model by default and escalates to Anthropic Claude for agentic shopping turns, using tool calls. Maxi returns shoppable product cards with affiliate buy links, restock/deal nudges, markdown-formatted replies, and inline @maxi answers inside chats.

Profiles & social

  • Per-user profiles with a taste summary, public/private toggle, and Posts/Friends tabs; create posts, activity feed, and a social graph (follows, pool membership) stored in DynamoDB.

Onboarding

  • A Pinterest-style multi-step wizard captures gift role (giver/taker/both), gift style, 16 interest "vibes," optional Pinterest board link, and deal preferences (budget range, deal types, price-drop alerts) — all of which feed the recommender.

Monetization (Track 1)

  • Amazon affiliate links on recommendations and the Shop page (ASIN-based, Associates-tag links).
  • Native sponsored placements designed to use the same card and the same taste ranking (Pinterest-style seamless ads).
  • Take-rate on group-gift pools.

Honesty note for judges: Giftmaxxing deliberately doesn't hold or process money. Group gifts are a coordination layer. The app tracks who's chipping in and the pool's progress (a Splitwise-style pledge tracker), but people pay each other directly; the contribution flow records pledges and shows "no real charge will occur." The shopping cart/checkout is simulated too. The live monetization mechanisms are real Amazon affiliate links; sponsored placements and a group-gift take-rate are the business model (payment-provider integration is on the roadmap), not yet live transactions.

Why it matters — effortless, high-intent, sustainable

Gifting is the rare behavior that's all three at once, and Giftmaxxing leans into each:

  • Effortless: you don't fill out forms or search; you swipe, share a link, or ask Maxi. Capturing a friend's taste takes ten seconds and zero signup on their end.
  • High-intent: gifting is one of the most reliably monetizable commerce moments; people want to buy and want to get it right.
  • Sustainable: unwanted gifts are a huge, invisible waste stream: produced, shipped, then returned, regifted, or landfilled because they miss. Precise, taste-matched recommendations plus group coordination (everyone chips in, nobody double-buys) mean fewer, better-chosen gifts that people actually keep. Sustainability here isn't a bolt-on product category, it's a direct outcome of getting the match right the first time.

This is also why the project maps strongly to Impact & Real-World Applicability: better matching is simultaneously better business and less waste.

How we built it

Frontend (Vercel): Next.js 16 / React 19 / Tailwind v4, deployed on Vercel with GitHub auto-deploy. The client talks to AWS through a single NEXT_PUBLIC_API_URL and degrades gracefully to bundled seed data if the API is briefly unreachable, so the UI never goes blank. (We scaffolded the initial app with Vercel's v0 before building out the production app.)

Primary database — Amazon DynamoDB: the operational data plane for the whole app, designed access-pattern-first with GSIs and on-demand billing + point-in-time recovery:

Table Keys Purpose
users PK userId Profile + taste prefs, one read on login
posts PK postId; GSI byAuthor, GSI byFeed Feed items (Reddit + Pinterest), profile grids, blended feed
interactions PK userId, SK type#targetId Likes/saves/swipes — idempotent; the taste signal
knowledge PK recipient Reddit-mined ranked gift ideas + bundles
events PK userId, SK eventId; GSI byScope Recipients + important dates
connections PK userId Soft profiles from the invite loop
graph PK pk, SK sk; GSI byEntity Social graph (follows, pools)
config PK key Feature flags incl. the cost kill-switch

API — AWS App Runner + CloudFront: a containerized Node API (AWS SDK v3 / @aws-sdk/lib-dynamodb) on App Runner, fronted by CloudFront edge caching for feed reads. (We started on Lambda — see Challenges.)

AI / taste layer: Amazon S3 (images) → Amazon Bedrock Titan Multimodal Embeddings (1024-d shared text+image space) → Amazon S3 Vectors (kNN). Maxi runs on Bedrock via Converse with Nova→Claude routing and tool use.

Data pipeline: Pinterest pins ingested via public RSS → S3 → embedded → S3 Vectors; Reddit gift discussions scraped → curated into the knowledge table.

Ops: entire backend is Terraform in us-east-1. A cost circuit-breaker (CloudWatch alarms on Bedrock/Maxi invocation spikes → a breaker Lambda flips a DynamoDB feature flag) protects against runaway AI spend and fails open.

Architecture

flowchart LR
  UI["Next.js · Vercel"] -->|NEXT_PUBLIC_API_URL| CF["Amazon CloudFront"]
  CF --> AR["AWS App Runner — Node API"]
  AR -->|metadata · feed · interactions| DDB[("Amazon DynamoDB")]
  AR -->|kNN · centroid| S3V[("Amazon S3 Vectors")]
  AR -->|embeddings · Maxi agent| BR["Amazon Bedrock"]
  S3[("Amazon S3 images")] --> BR --> S3V

Challenges we ran into

  • Lambda concurrency → 503s. Our first API was a single Lambda behind API Gateway. Under bursty traffic (amplified by naive client retries) we hit the account concurrency cap and started returning 503 Service Unavailable. We migrated the API to AWS App Runner (autoscaling, no per-account concurrency ceiling) and added CloudFront + client-side caching/de-duplication to kill retry storms — without touching the DynamoDB data layer.
  • Our own cost kill-switch. Tight CloudWatch alarms on Bedrock/Maxi invocations would trip during heavy testing and pause the app. We tuned thresholds to protect spend without firing on real usage.
  • Choosing the database. We genuinely evaluated Aurora PostgreSQL + pgvector vs DynamoDB + S3 Vectors and made a deliberate, costed call (below).

Why DynamoDB (and not Aurora)

We needed both an operational metadata store and a vector store. At our vector volume (tens → tens-of-thousands of pins, below the ~100k threshold where a relational ANN engine's always-on ACU cost pays off), DynamoDB + S3 Vectors gives single-digit-millisecond reads and scale-to-zero cost today, with a clean path to millions. Aurora would have added a continuous cost floor without adding value at our scale. The decision is reversible: if we cross ~100k vectors and need real-time filtered ANN, we can add OpenSearch Serverless or Aurora pgvector as a hot tier behind the same API, without touching the DynamoDB plane.

Accomplishments that we're proud of

  • A full-stack, end-to-end working social gifting app on a genuinely production-shaped AWS stack.
  • A real data flywheel: swipe → DynamoDB → taste centroid → S3 Vectors kNN → sharper feed.
  • The anonymous share-a-challenge loop — viral growth and taste capture in one interaction.
  • A real Bedrock agent (Maxi) with cost-aware model routing, not a chatbot wrapper.
  • Surviving a real production incident (Lambda 503s) by migrating compute without a data migration.

What we learned

  • "Production-ready" is something you learn under load, not something you declare — and putting durable state in a managed database is what let us swap the compute tier painlessly.
  • Picking the AWS database to fit your actual data shape beats picking the most powerful one.
  • Cost guardrails need to be tuned as carefully as the features they protect.

What's next for Giftmaxxing

Retail partnerships → real, recurring revenue. The taste graph is the asset. Our path to scale is partnering directly with retailers — Target, Walmart, Sephora, and similar — to power taste-matched product placement and fulfillment. Instead of relying only on affiliate links, we earn through retail media / commission deals: brands and stores pay to reach high-intent shoppers at the exact moment we know what someone actually wants, ranked by the same taste model that drives the organic feed (so sponsored picks still feel native, not spammy).

The market is huge because gifting is recurring, and it's not just gifting. Every person has multiple recurring occasions a year (birthdays, anniversaries, holidays, "just because") for multiple people, and the same taste engine powers self-gifting too. So a single user generates demand on both sides — gifts for others and for themselves — over and over. That's a large, repeat-purchase TAM rather than a one-and-done transaction.

Product roadmap to support it:

  • Real payment rails for group-gift pools and checkout.
  • Pinterest OAuth (currently public-RSS) and live Amazon PA-API + retailer-catalog enrichment.
  • Native sponsored inventory ranked by the taste model, with frequency caps.
  • Bedrock batch embedding + a decoupled (SQS/Step Functions) ingest path at scale.

Built with

vercel · v0 · next.js · react · typescript · tailwindcss · amazon-dynamodb · aws-app-runner · amazon-cloudfront · amazon-s3 · amazon-s3-vectors · amazon-bedrock · amazon-nova · anthropic-claude · terraform · clerk

This submission and its accompanying blog post were created for the purposes of entering the H0 Hackathon: Hack the Zero Stack with Vercel v0 and AWS Databases. #H0Hackathon

Built With

Share this project:

Updates