<h2>The Problem</h2>
<p>The creator economy exploded, but the tools for fans to support creators felt transactional. You buy merch, you get merch. There's no connection, no community, no fun.</p>
<p>I wanted to build something that made supporting creators feel more like being part of a community. Not just buying stuff, but engaging, competing with other fans, and getting recognition for your support.</p>
<h2>What I Built</h2>
<p>Simp Gifts is an e-commerce platform where fans can send gifts to creators they follow. But it goes beyond basic shopping:</p>
<ul>
<li><strong>Chat System</strong> to talk directly with creators or get support</li>
<li><strong>Leaderboards</strong> showing top supporters (gamifying the experience)</li>
<li><strong>Referral Program</strong> that rewards both the referrer and new user</li>
<li><strong>Custom Currency</strong> ("simps balance") with real time exchange rates</li>
<li><strong>Social Sharing</strong> to broadcast your gifts on Twitter</li>
</ul>
<h3>Tech Stack</h3>
<table>
<thead>
<tr>
<th>Layer</th>
<th>Technology</th>
<th>Why I Chose It</th>
</tr>
</thead>
<tbody>
<tr>
<td>Frontend</td>
<td><a href="https://nextjs.org/">Next.js</a></td>
<td>SSR for SEO, React ecosystem</td>
</tr>
<tr>
<td>Database</td>
<td><a href="https://www.postgresql.org/">PostgreSQL</a></td>
<td>Relational data, transactions</td>
</tr>
<tr>
<td>Payments</td>
<td><a href="https://stripe.com/">Stripe</a></td>
<td>Industry standard, great docs</td>
</tr>
<tr>
<td>Real time</td>
<td><a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API">WebSockets</a></td>
<td>Live updates</td>
</tr>
<tr>
<td>Social</td>
<td><a href="https://developer.twitter.com/">Twitter API</a></td>
<td>Share functionality</td>
</tr>
</tbody>
</table>
<h2>What Building This Taught Me</h2>
<h3>1. The custom currency challenge</h3>
<p>The custom currency system was the most complex feature. Users buy "simps" that they spend on gifts. Exchange rates fluctuate, so I needed to:</p>
<ol>
<li>Fetch real time rates from an external API</li>
<li>Store rates in the database for transaction records</li>
<li>Handle edge cases when rates change mid checkout</li>
</ol>
<pre><code>// Currency conversion with rate locking
async function purchaseSimps(userId: string, usdAmount: number) {
  const rate = await getExchangeRate('USD', 'SIMPS')

  // Lock the rate for this transaction
  const transaction = await db.transaction(async tx => {
    const simpsAmount = usdAmount * rate.value

    await tx.insert(purchases).values({
      userId,
      usdAmount,
      simpsAmount,
      rateAtPurchase: rate.value, // Store for audit
      rateId: rate.id,
    })

    await tx
      .update(users)
      .set({ simpsBalance: sql`simps_balance + ${simpsAmount}` })
      .where(eq(users.id, userId))
  })
}
</code></pre>
<p>Resources:</p>
<ul>
<li><a href="https://stripe.com/docs/currencies">Stripe Currency Handling</a></li>
<li><a href="https://www.postgresql.org/docs/current/tutorial-transactions.html">PostgreSQL Transactions</a></li>
</ul>
<h3>2. Gamification works better than expected</h3>
<p>The leaderboard feature drove way more engagement than I expected. People genuinely competed to be top supporters. Recognition matters, even in digital spaces.</p>
<pre><code>xychart-beta
    title "Engagement Increase After Adding Leaderboards"
    x-axis ["Daily Active Users", "Avg Order Value", "Repeat Purchases"]
    y-axis "Increase (%)" 0 --> 70
    bar [45, 30, 60]
</code></pre>
<p>Resources on gamification:</p>
<ul>
<li><a href="https://yukaichou.com/gamification-examples/octalysis-complete-gamification-framework/">Gamification Design Framework</a></li>
<li><a href="https://www.oreilly.com/library/view/designing-for-behavior/9781449367947/">Designing for Behavior Change</a></li>
</ul>
<h3>3. Stripe makes payments easy, but custom currencies add complexity</h3>
<p><a href="https://stripe.com/">Stripe</a> integration was smooth for basic purchases. Custom currencies and balance systems? That required careful thinking about edge cases, refunds, and reconciliation.</p>
<p>What happens when:</p>
<ul>
<li>A user requests a refund after spending their simps?</li>
<li>Exchange rates change between purchase and refund?</li>
<li>A transaction fails mid-way?</li>
</ul>
<pre><code>// Refund handling with currency conversion
async function processRefund(purchaseId: string) {
  const purchase = await getPurchase(purchaseId)

  // Use the ORIGINAL rate, not current rate
  const refundUsd = purchase.simpsAmount / purchase.rateAtPurchase

  await stripe.refunds.create({
    payment_intent: purchase.stripePaymentIntent,
    amount: Math.round(refundUsd * 100), // Stripe uses cents
  })
}
</code></pre>
<p>Resources:</p>
<ul>
<li><a href="https://stripe.com/docs/refunds">Stripe Refunds</a></li>
<li><a href="https://martinfowler.com/eaaCatalog/money.html">Handling Money in Software</a></li>
</ul>
<h3>4. Referral systems need anti fraud from day one</h3>
<p>My first version got exploited within days. People created fake accounts to refer themselves. I had to add verification, cooling periods, and detection logic.</p>
<pre><code>// Anti-fraud checks for referrals
async function validateReferral(referrerId: string, newUserId: string) {
  const referrer = await getUser(referrerId)
  const newUser = await getUser(newUserId)

  // Check for self-referral patterns
  if (referrer.ip === newUser.ip) throw new Error('Same IP')
  if (referrer.deviceId === newUser.deviceId) throw new Error('Same device')

  // Cooling period: account must be 7 days old to refer
  const accountAge = Date.now() - referrer.createdAt
  if (accountAge &#x3C; 7 * 24 * 60 * 60 * 1000) {
    throw new Error('Account too new to refer')
  }

  // Rate limit: max 5 referrals per day
  const recentReferrals = await countReferrals(referrerId, '24h')
  if (recentReferrals >= 5) throw new Error('Daily limit reached')
}
</code></pre>
<p>Resources:</p>
<ul>
<li><a href="https://stripe.com/docs/radar/rules">Fraud Prevention Patterns</a></li>
<li><a href="https://fingerprint.com/">FingerprintJS for Device ID</a></li>
</ul>
<h2>The Bigger Realization</h2>
<p>Building Simp Gifts taught me that features are easy, but trust is hard. Users will find every edge case and exploit you didn't consider. Starting with "how will people abuse this?" is better than reacting to abuse after launch.</p>
<h2>What I'd Do Differently</h2>
<p>Start with fraud prevention baked into the architecture. I built the happy path first and added anti fraud measures reactively. Thinking adversarially from day one would have saved weeks of firefighting.</p>
<h2>References</h2>
<ul>
<li><a href="https://stripe.com/docs">Stripe Documentation</a></li>
<li><a href="https://nextjs.org/docs">Next.js Documentation</a></li>
<li><a href="https://www.postgresql.org/docs/">PostgreSQL Documentation</a></li>
<li><a href="https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API">WebSocket API</a></li>
<li><a href="https://developer.twitter.com/en/docs/twitter-api">Twitter API v2</a></li>
</ul>
<h2>Links</h2>
<ul>
<li><strong>GitHub:</strong> <a href="https://github.com/Summary-Box/simp-gifts">simp-gifts</a></li>
</ul>


Projects.

Simp Gifts: Creator Economy E-commerce