# AI Creative Award — Building a Vote-at-Scale Competition Platform Solo

> A monthly creative competition where people submit AI-generated art, vote on their
> favorites, and compete for a 1M ETB prize pool. I designed, built, and shipped the
> entire platform — architecture, infrastructure, UI, and anti-abuse systems — as a
> single developer.

**Role:** Sole engineer & system designer (architecture → infra → UI → launch)
**Timeline:** ~4 weeks from empty repo to production
**Scale handled:** 50,000+ users
**Technology Stack:** Next.js, React, TypeScript, PostgreSQL, Redis, Supabase, Vercel, Tailwind CSS, Drizzle ORM, BetterAuth, Resend, Zod
**Live:** creativeaward.ai

---

## The Problem

Online voting competitions have one hard technical truth: **the voting hot path is
adversarial and bursty**. Thousands of people hit "vote" in the same minutes, every
vote is money-adjacent (a real prize is on the line), and bad actors will script,
sockpuppet, and rate-abuse anything that moves. A naive build — count votes with a
`SELECT COUNT(*)`, trust the client, deploy and hope — collapses under exactly the load
it's designed to attract.

The brief was to handle **20K–100K votes per cycle** on a serverless-first budget, with
a small team (me), on a timeline measured in weeks, not quarters.

So the real engineering problem wasn't "build a voting app." It was:

- How do you count votes at burst scale **without touching the primary database on the hot path**?
- How do you keep leaderboards feeling live without re-aggregating on every request?
- How do you stop bots and vote-stuffing **before** they cost you database capacity?
- How do you do all of this with one engineer and a serverless bill?

---

## System Architecture

The design principle throughout: **push the expensive work off the request path.**
Reads are cached, writes are cheap, aggregation is asynchronous, and abuse is filtered
as early (and as far from the database) as possible.

```
                          ┌─────────────────────────┐
        User ───────────► │   Vercel Edge / CDN     │  ◄── Bot defense, CSRF, auth gating
                          └────────────┬────────────┘
                                       │
                          ┌────────────▼────────────┐
                          │  Next.js 16 App Router  │  Server Components (reads)
                          │  API Routes (writes)    │  Client Components (interactions)
                          └───┬───────────┬─────────┘
                              │           │
              ┌───────────────┘           └───────────────┐
              ▼                                            ▼
      ┌───────────────┐                          ┌──────────────────┐
      │ Upstash Redis │  Vote counters (INCR)    │  Neon Postgres   │  Source of truth
      │               │  Leaderboard cache (TTL) │  (HTTP driver)   │  Append-only votes
      │               │  Sliding-window limits   │                  │  Audit log
      └───────▲───────┘                          └────────▲─────────┘
              │                                            │
              │        ┌───────────────────────┐          │
              └────────┤   Vercel Cron (1 min)  ├──────────┘
                       │  sync-vote-counts      │  Redis → Postgres reconciliation
                       │  competition-lifecycle │  Phase transitions
                       └───────────────────────┘

      ┌──────────────────┐        ┌──────────────────┐
      │ Supabase Storage │        │      Resend      │
      │ Presigned upload │        │  Transactional   │
      │ (media off-path) │        │  email (retries) │
      └──────────────────┘        └──────────────────┘
```

### The core insight: Redis is the vote ledger's front desk, Postgres is the vault

The single most important decision was **never counting votes with live SQL
aggregation.** Every vote does an atomic `INCR` on a Redis counter keyed by submission.
Reads of "current vote count" hit Redis, not a `COUNT(*)` scan. A Postgres row is still
written for every vote — the database remains the durable, auditable source of truth —
but the _number people see_ and the _number that drives the leaderboard_ comes from an
in-memory counter that shrugs off burst traffic.

A **1-minute cron job reconciles** Redis counters back into Postgres, so the two never
drift for long, and the durable store is always catching up to the fast store rather
than gating it.

### Leaderboards: cached, not recomputed

Leaderboards are read constantly and would be the obvious N+1 / full-table-scan
disaster. Instead they're **served from a short-TTL Redis cache** (30 seconds), keyed by
competition and page. The result feels live — a 30-second staleness window is invisible
in a multi-week competition — while the database is shielded from thousands of identical
ranking queries per minute. Batched pipeline reads pull many submissions' counts in a
single round trip rather than one-per-submission.

### The intentional two-provider split (Neon + Supabase)

I deliberately **split the database and storage across two providers** and documented
_why_, because it looks like accidental complexity until you understand the hot path:

- **Neon Postgres via its HTTP driver** uses stateless HTTP requests instead of holding
  TCP connections. On Vercel's serverless functions that means **near-zero cold-start
  overhead** for database access — no per-invocation TLS handshake + Postgres auth tax
  (~80–150ms) that a traditional TCP driver pays. On a voting hot path that's invoked in
  bursts, that cold-start tax is exactly what you can't afford.
- **Supabase Storage** handles media via **presigned upload URLs**, so image and video
  bytes never flow through a serverless function. The client uploads straight to
  storage; the function only ever handles a URL. Media processing stays off the compute
  path entirely.

The tradeoff — two dashboards, two bills — was a conscious trade for cold-start
performance where it mattered most. That's the kind of decision I wanted the
architecture to make _explicitly_ rather than drift into.

---

## Handling Load

The platform never tries to be big. It tries to make the expensive operations rare.

| Pressure              | Naive approach                        | What I built                                            |
| --------------------- | ------------------------------------- | ------------------------------------------------------- |
| Burst voting          | `INSERT` + `SELECT COUNT(*)` per vote | Atomic Redis `INCR`; Postgres write for durability only |
| Live vote counts      | Aggregate on read                     | Read straight from Redis counter                        |
| Leaderboard reads     | Rank query per pageview               | 30s TTL Redis cache, batched pipeline reads             |
| Media uploads         | Stream bytes through function         | Presigned direct-to-storage uploads                     |
| DB cold starts        | TCP driver on serverless              | Neon stateless HTTP driver                              |
| Counter durability    | Hope Redis never fails                | 1-min cron reconciles Redis → Postgres                  |
| Server-rendered reads | Client fetch waterfalls               | React Server Components render on the server            |

The result is a system whose **cost and latency scale with _unique_ activity, not raw
request volume**. Ten thousand people refreshing a leaderboard cost one Redis read every
30 seconds, not ten thousand database queries.

---

## Defense: How Bot & Fraud Protection Held the Line

With real prize money involved, abuse isn't a maybe — it's the design assumption. I
layered defenses so that **cheap filters run first and expensive checks run last**, and
so that no single layer is the only thing standing between a bot and the vote table.

### Layer 0 — Vercel's edge as the first wall

Running on Vercel meant the **platform's bot defense and edge network absorbed a large
class of automated and malicious traffic before it ever reached my code.** Vercel's
managed bot mitigation and challenge tooling sit at the edge, in front of the
application, so the crudest scripted floods get filtered upstream of my serverless
functions — which means my rate limiters and database are spending their budget on
traffic that already cleared the front door. Letting the platform own the outermost
layer is itself a system-design choice: don't rebuild edge-scale bot filtering when your
host does it better than you can.

### Layer 1 — Edge request gating (CSRF + auth)

A proxy/middleware layer runs at the edge on every matched request. It **blocks
cross-origin mutating requests** (an allowlist origin check on every POST/PUT/PATCH/
DELETE to the API — a lightweight CSRF guard) and **gates protected routes** by session
before any handler runs. Unauthenticated users never reach the voting or submission
logic at all.

### Layer 2 — Sliding-window rate limits

Every sensitive endpoint is rate-limited with sliding-window counters in Redis, tuned
per action and per identity:

- Votes: capped **per user** and **per IP** independently (so neither a single account
  nor a single network can flood).
- Auth, OTP, signup, and email-verification each get their own stricter budgets
  (e.g. signups throttled per IP per hour).

Because the limits live in Redis, they're enforced consistently across every serverless
instance without shared server state.

### Layer 3 — Identity & integrity checks at write time

Each vote passes through a gauntlet before it counts: authentication, an account **ban
check**, submission-exists-and-approved validation, **self-vote prevention**, and a
duplicate-vote check. Client IP and a device fingerprint are **hashed, never stored
raw** — enough to correlate abuse without holding personal data. Votes are
**append-only**: never updated, never deleted. Reversing fraud means _invalidating_
(flagging) votes, which preserves a complete forensic trail.

### Layer 4 — Admin fraud tooling & signup hygiene

Above the automated layers sits operator tooling I built for the human in the loop: a
**fraud-detection dashboard**, bulk **vote invalidation** by IP/device/user, **voter
banning**, and **domain watchlists**. Signups are additionally screened against a
**disposable-email-domain blocklist** so throwaway-inbox sockpuppet farms are cheaper to
stop than to create.

The philosophy: **make abuse expensive and legitimate use frictionless.** A real voter
never notices any of this. A bot hits five walls, each cheaper for me to run than for
them to beat.

---

## Tech Stack

**Framework & language**

- Next.js 16 (App Router) · React 19 · TypeScript (strict mode)
- React Server Components for reads, Client Components for interactions

**Data & infrastructure**

- Neon Postgres (serverless HTTP driver) + Drizzle ORM — durable source of truth
- Upstash Redis — vote counters, leaderboard cache, sliding-window rate limits
- Supabase Storage — presigned direct-to-storage media uploads
- Vercel — hosting, edge network, bot defense, and Cron (reconciliation + lifecycle)

**Application layer**

- BetterAuth — email/password auth with user / judge / admin roles
- Resend — transactional email with retry + exponential backoff
- Zod — end-to-end input validation
- Tailwind CSS v4 — a custom dark competition theme

**Operational**

- Two Vercel Cron jobs (1-min cadence): vote-count reconciliation and automated
  competition phase transitions (submission window → voting window → results)
- Append-only audit logging across privileged actions

---

## The Meta-Story: AI-Driven Development With a System Designer's Mindset

This is the part I'm proudest of, and it's the part that's genuinely new.

I built a platform that survived real, adversarial, money-on-the-line scale — **solo, in
about four weeks.** That pace is only possible with AI-assisted development. But the
lesson of this project is the _opposite_ of "the AI built it for me."

AI collapsed the cost of _implementation_. It did nothing to collapse the cost of
_judgment_. Every load-bearing decision in this system was a design call that no
autocomplete makes for you:

- Deciding that **votes must never be counted with live SQL** — and structuring the
  whole data flow around that constraint.
- Choosing to **split providers** for a cold-start reason most people would "simplify"
  away, and documenting the rationale so the next person doesn't undo it.
- Designing **defense as layers** where cost increases inward, so cheap filters protect
  expensive resources.
- Treating **votes as an append-only ledger** so fraud is reversible without losing
  history.

AI let me move through the implementation of those decisions at a speed that would've
taken a small team months. My job was to be the architect who knew _which_ system to ask
for, _why_ it had to be shaped that way, and _where_ it would break under load and abuse
— and then to hold that line while iterating fast.

**That's the model of engineering I want to be hired for:** a system designer who uses AI
as a force multiplier on a foundation of real architectural judgment — not a prompt
operator hoping the output holds up in production. On this project, it held up under
50,000+ users. Because it was designed to.

---

## What I'd Highlight in a Conversation

- **Read-heavy-at-scale done right:** the difference between a leaderboard that melts a
  database and one that costs a single cached read.
- **Adversarial-by-default design:** five defensive layers, ordered by cost, with the
  platform owning the outermost.
- **Documented tradeoffs:** the Neon/Supabase split is the clearest example — an
  intentional complexity with a written rationale and a "don't undo this" note.
- **Solo velocity without solo fragility:** AI-accelerated delivery, human-owned
  architecture.

---

_Built and shipped solo. Architecture, infrastructure, UI, and anti-abuse systems by
Daniel Mesfin._


A monthly creative competition where people submit AI-generated art, vote on their favorites, and compete for a 1M ETB prize pool. I designed, built, and shipped the entire platform — architecture, infrastructure, UI, and anti-abuse systems — as a single developer.

AI Creative Award

Building a Vote-at-Scale Competition Platform Solo

AI Creative Award — Building a Vote-at-Scale Competition Platform Solo

# Bridge of Hope Ethiopia: Nonprofit Platform with Multi-Payment Integration

## Project Overview

**Bridge of Hope Ethiopia** is a digital platform for a nonprofit organization that has been supporting vulnerable children and orphans since 2001. The platform handles content management, donation processing, and program operations through a dual-payment system serving both international and local Ethiopian donors.

**Role**: Lead Developer
**Development Timeline**: 6 months
**Technology Stack**: Laravel, Blade Templates, TailwindCSS, MySQL, PayPal API, Chapa API

---

## The Challenge

The organization had outgrown its static website. Staff had to email content updates to a single person who manually edited HTML files, meaning urgent updates about children's needs often went unshared for weeks. More critically, the donation system only supported PayPal — cutting off Ethiopian donors who rely on mobile money and local banking. With programs spanning childcare, community development, and business enterprises, they needed a platform that non-technical staff could manage independently.

---

## What I Built

### Dual Payment Gateway

The most impactful feature was integrating both PayPal for international donors and Chapa — a popular Ethiopian payment processor — for local contributions via mobile money and local banks. This opened an entirely new revenue stream. The unified tracking system reconciles donations from both gateways into a single financial view, handling currency differences and different donation patterns (international donors tend toward larger one-time gifts, while local donors prefer smaller recurring amounts).

### Content Management System

The CMS was designed for non-technical staff. A rich text editor with a draft-to-publish workflow lets content creators prepare stories about the children and programs, have them reviewed, and publish — all without developer involvement. The team went from publishing updates once or twice a month to sharing stories weekly.

### Role-Based Access

Different staff members get different levels of access — content creators publish news articles, program coordinators update project milestones, and admins manage donations and user accounts. Sensitive information stays protected while giving each team member the tools they need.

### Donor Engagement

An automated receipt system sends personalized thank-you emails with tax-deductible receipts, along with updates about how specific donations are being used. This created a stronger connection between donors and the organization's mission.

---

## Technical Highlights

The image optimization system was essential given that many visitors have limited internet connectivity. Uploaded images are automatically processed into multiple sizes, with the appropriate version served based on device and connection speed. The platform includes comprehensive logging and role-based access controls to protect sensitive donor information and financial data.

---

## Impact

Within three months of launch, online donations increased by 60%. The local payment integration through Chapa accounted for 40% of total contributions — revenue that simply didn't exist before. The platform now serves over 1,000 active users including donors, volunteers, and staff, with automated systems handling donation processing and receipt generation so staff can focus on their core mission.

**Technologies Used**: Laravel, Blade Templates, TailwindCSS, MySQL, PayPal API, Chapa API

**Visit the platform**: [boh-eth.org](https://boh-eth.org)


Bridge of Hope Ethiopia is a digital platform for a nonprofit organization that has been supporting vulnerable children and orphans since 2001. The platform handles content management, donation processing, and program operations through a dual-payment system serving both international and local Ethiopian donors.

Bridge of Hope Ethiopia

Nonprofit Platform with Multi-Payment Integration

Bridge of Hope Ethiopia: Nonprofit Platform with Multi-Payment Integration

# EhudAI: AI-Powered Content Creation Studio

## Project Overview

**EhudAI** is an end-to-end AI-powered platform for movie and content production that brings story creation, character development, visual generation, and video production into a single workflow.

**Role**: Full-Stack Developer
**Development Timeline**: Multi-phase development with continuous feature enhancement
**Technology Stack**: Next.js, TypeScript, Flask, PostgreSQL, OpenAI GPT-4, DALL-E, RunwayML, Flux AI, Google Veo, Kling AI, Liveblocks, Stripe, AWS S3, Tailwind CSS, Radix UI

---

## The Challenge

Content creators and filmmakers typically juggle disconnected tools for writing, design, and video editing. This fragmented workflow is expensive, slow, and breaks creative momentum. EhudAI was built to unify these steps under one roof with AI doing the heavy lifting.

---

## What I Built

The platform combines a Next.js frontend with a Flask backend, orchestrating multiple AI services through a unified interface.

### Unified AI Workflow

Rather than switching between separate tools, users move fluidly from story outline to finished video. The platform maintains context across every stage — a character created during writing carries its visual identity into image and video generation.

### Dual AI Interaction Modes

The platform offers two distinct ways to work with AI. A conversational chat mode handles content editing and writing assistance, while an agent mode makes structural changes to scenes, characters, and story elements directly in the database.

### Real-Time Collaboration

Built with Liveblocks, the collaborative editor supports multiple users working on the same project simultaneously with live cursors, conflict resolution, and version history.

### Multi-Modal Generation Pipeline

The system chains AI services together — text descriptions become images through DALL-E or Flux AI, static images become dynamic video through RunwayML or Google Veo, and story outlines transform into formatted screenplays.

---

## Technical Highlights

The backend manages orchestration across multiple AI providers, each with different rate limits, response formats, and capabilities. A service abstraction layer handles provider switching and error recovery transparently.

Media storage runs through AWS S3 with progressive loading to handle the large video files that the generation pipeline produces. Stripe powers the subscription billing system with usage-based pricing tiers.

---

## Impact

The platform reduces content creation time significantly by eliminating tool-switching and manual handoffs between creative stages. Users go from concept to produced content within a single session, with AI assistance at every step.

**Technologies Used**: Next.js, TypeScript, Flask, PostgreSQL, OpenAI GPT-4, DALL-E, RunwayML, Flux AI, Google Veo, Kling AI, Liveblocks, Stripe, AWS S3, Tailwind CSS, Radix UI

**Live Demo**: [EhudAI Platform](https://ehudai.com)


EhudAI is an end-to-end AI-powered platform for movie and content production that brings story creation, character development, visual generation, and video production into a single workflow.

EhudAI

AI-Powered Content Creation Studio

EhudAI: AI-Powered Content Creation Studio

# MiranaPM: Multi-Tenant Property Management Platform

## Project Overview

**MiranaPM** is a multi-tenant property management platform that centralizes rental operations, automates payment processing, and streamlines maintenance management for landlords, residents, and property managers.

**Role**: Full-Stack Developer
**Development Timeline**: Multi-phase development
**Technology Stack**: Laravel, Blade Templates, Tailwind CSS, Livewire, MySQL, Redis, AWS S3, Lightsail

---

## The Challenge

Property management companies were relying on fragmented tools — one system for rent collection, another for maintenance requests, spreadsheets for financial tracking, and email for tenant communication. This meant duplicated data entry, missed payments, and slow response times on maintenance issues. The platform needed to bring everything into one place while keeping each management company's data completely isolated.

---

## What I Built

I contributed to system design, module architecture, and development of multiple core modules across the full stack.

### Multi-Tenant Architecture

Each property management company operates on an isolated database resolved through subdomain routing. This ensures complete data separation while sharing a single codebase. The middleware layer handles tenant resolution and database switching transparently.

### Role-Based Dashboards

The platform serves four distinct user types, each with a tailored interface. Landlords see portfolio-level financials and occupancy metrics. Residents access a self-service portal for rent payments and maintenance requests. Admins manage system-wide operations. Board advisors have oversight dashboards with approval workflows.

### Automated Financial Operations

The billing engine handles recurring rent charges, late fee calculations, prorated amounts, and multi-gateway payment processing. Financial reports break down revenue, expenses, and profitability per property and unit type. A queue-based background processing system handles the heavy computation without blocking the user interface.

### Maintenance Workflow

Residents submit work orders through the portal, which are routed to the appropriate property manager. The system tracks vendor assignments, scheduling, response times, and costs — giving landlords visibility into maintenance spending and performance.

---

## Technical Highlights

The frontend uses Livewire for reactive dashboard components without the complexity of a separate JavaScript framework. Redis caching keeps dashboard queries fast even with large datasets across multiple properties. Document storage (leases, maintenance photos) runs through AWS S3 with Laravel's filesystem abstraction.

The modular architecture organizes features into self-contained modules — property management, resident management, lease management, financials, maintenance, reporting, and notifications — making the codebase maintainable as the feature set grows.

---

## Impact

The platform automated roughly 70% of manual rent collection tasks and centralized all property operations into a single interface. Landlords gained real-time financial visibility they didn't have before, and the streamlined communication workflow between tenants and managers significantly reduced response times on maintenance issues.

**Technologies Used**: Laravel, Blade Templates, Tailwind CSS, Livewire, MySQL, Redis, AWS S3, AWS Lightsail, Alpine.js

**Live Platform**: [MiranaPM.com](https://miranapm.com)


MiranaPM is a multi-tenant property management platform that centralizes rental operations, automates payment processing, and streamlines maintenance management for landlords, residents, and property managers.

MiranaPM

Multi-Tenant Property Management Platform

MiranaPM: Multi-Tenant Property Management Platform

# Reveshare: Affiliate Management & Commission Tracking Platform

## Project Overview

**Reveshare** is an affiliate management platform that helps e-commerce brands run their affiliate programs with automated commission tracking, campaign management, and payouts. The platform is listed on the Shopify App Store.

**Role**: Development Lead
**Development Timeline**: Full product development cycle
**Technology Stack**: React, Vite, Tailwind CSS, Nest.js, TypeScript, Stripe, Shopify SDK, Sentry

---

## The Challenge

E-commerce brands running affiliate programs were dealing with clunky tools that made onboarding affiliates painful, tracking commissions unreliable, and managing payouts manual. Most existing solutions were desktop-only, which was a problem since affiliates often check their earnings and share links from their phones. The platform needed to integrate natively with Shopify and handle everything from affiliate recruitment to automated payouts.

---

## What I Built

I led the entire product lifecycle from specification through deployment, building a React frontend with a Nest.js backend.

### Three Dedicated Dashboards

Each user type gets an interface built for their workflow. Affiliates see their performance metrics, earnings, and referral links in a mobile-optimized dashboard. Brands manage campaigns, track conversions, and handle affiliate approvals. Admins oversee the entire platform with user management and system-level analytics.

### Automated Commission Engine

When a customer uses an affiliate's discount code on Shopify, the system automatically calculates the commission based on the campaign's rules — supporting percentage-based, fixed-amount, and tiered commission structures. Commissions flow through to automated Stripe payouts on a configurable schedule.

### Shopify Integration

The app connects directly to Shopify stores, syncing products and orders in real time through webhooks. This means brands don't need to manually import data or reconcile orders — everything stays in sync automatically. Getting through the Shopify App Store review and approval process required careful attention to their integration standards.

### Campaign Management

Brands create campaigns with dynamic discount codes, set commission rates, and assign affiliates. The analytics layer tracks click-through rates, conversion rates, and ROI per campaign, giving brands the data they need to optimize their programs.

---

## Technical Highlights

The Shopify webhook integration handles high-volume event processing with retry mechanisms and rate limiting to stay within API constraints. Cron jobs run automated processes like payout scheduling and performance report generation. Sentry provides error tracking and performance monitoring in production. The mobile-first approach resulted in a 90+ Lighthouse performance score across all dashboards.

---

## Impact

The platform successfully launched on the Shopify App Store, giving e-commerce brands a complete affiliate management solution with 100% accurate automated commission tracking. The mobile-first design drove strong affiliate engagement, and the automated payout system eliminated the manual payment processing that was previously eating up hours of admin time each month.

**Technologies Used**: React, Vite, Tailwind CSS, React Context, Nest.js, TypeScript, Sentry, Cron Jobs, Stripe, Shopify SDK, REST API, Resend

**Live Platform**: [Reveshare.com](https://reveshare.com)


Reveshare is an affiliate management platform that helps e-commerce brands run their affiliate programs with automated commission tracking, campaign management, and payouts. The platform is listed on the Shopify App Store.

Deep dives into the work.

AI Creative Award

Bridge of Hope Ethiopia

EhudAI

MiranaPM

Reveshare