©Code byMilanParmar

Social challenge app: 10,000 users, 3,000+ challenges, and $40K staked on X accounts

This startup lets people challenge any X (Twitter) account and put money behind it. A user picks an account, writes the challenge, and stakes from their wallet. Others can add to the pot. The target accepts or declines, responds, and gets paid out. An agency had left the product half-built and not ready to scale. I took it over, kept what worked, rewrote the rest, and launched it in eight weeks. It's live with 10,000 users, 3,000+ challenges, and $40K staked.

Category
Websites
Industry
Consumer social + fintech
Type
Social challenge platform
Year
2025

At a glance

Client
Consumer social startup (name kept private)
The problem
An agency had left the app half-built on a foundation that wouldn't scale, and the product had to move real money safely: stakes, crowd contributions, a response, and a payout.
What I built
A Next.js app with a public feed, a step-by-step challenge composer, X account lookup, PayPal-funded wallets, crowd funding, accept and respond flows, payouts, and realtime updates on Convex.
The result
Live with 10,000 users, 3,000+ challenges created, and $40K staked, with every balance and state change updating instantly for everyone watching.
Timeline
8 weeks
Budget
$16,000

The idea: online callouts with real money behind them

People challenge each other on X all the time, and nothing happens. This startup's idea was to add real stakes: put money behind a challenge, let others add to it, and pay the target if they take it on.

The hard part isn't the post. It's everything after it: money moving between wallets, several people contributing, a response, and a payout, all without a balance ever going wrong.

Taking over a half-built app from an agency

An agency had started the product and left it half-built. Some parts worked, but the foundation wasn't built to scale, and a product that moves money can't be patched together.

I reviewed everything, kept the parts that were solid, and rewrote the rest. Then I finished the product and launched it in eight weeks. It has since reached 10,000 users and $40K staked.

How a challenge works, from post to payout

Every challenge moves through clear states, from published to funded, accepted, responded, and paid out. Each state decides what the app shows and what actions are allowed, and the flow is designed so a challenge can't be paid out early, paid twice, or left stuck halfway.

  1. 01

    Pick an X account

    Search it inside the composer; profile details load automatically.

  2. 02

    Write it and stake

    Money comes from the user's wallet, funded through PayPal.

  3. 03

    Publish

    The challenge goes live on the public feed.

  4. 04

    The crowd adds to the pot

    Others contribute money and messages.

  5. 05

    The target responds

    They accept or decline, then submit a response.

  6. 06

    Payout

    The pot moves to the target's wallet.

Wallets, PayPal deposits, and payouts handled safely

Users fund a wallet through PayPal, then stake or contribute from that balance. The backend is the single source of truth for every balance, and every money movement goes through it. That keeps stakes, crowd contributions, and payouts consistent even when several people act on the same challenge at once.

Built on real X identities

Users search for an X account right inside the composer. The app pulls in the username, avatar, verification status, and follower count through the X API, so every challenge is tied to a real, recognisable account.

Realtime updates and a composer that guides you step by step

Convex keeps the app in sync without polling: when someone adds to a pot or a target responds, everyone watching sees it instantly.

The composer walks users through signing in, writing the challenge, picking the target, setting the stake, and topping up their wallet if needed. The main button always shows the next step, so a complex flow still feels simple.

Results

  • 10,000

    users

  • 3,000+

    challenges created

  • $40K

    staked through challenges

  • 8 weeks

    to build and launch

Key decisions

  1. 01

    Explicit states for every challenge

    Money depends on where a challenge is. Clear states make it impossible to pay out early or twice.

    Trade-off: Every transition has to be designed and tested.

  2. 02

    One source of truth for balances

    With stakes, contributions, and payouts happening at once, balances must come from one place, never from the screen.

  3. 03

    Realtime data instead of polling

    A pot growing live is part of the product. Reactive data makes it instant and keeps load down.

  4. 04

    Webhooks to keep accounts in sync

    Svix-delivered webhooks from Clerk keep user accounts and wallets consistent with sign-ups and profile changes.

What the client said

“Our agency left the app half-built. Milan picked it up, fixed what was there, and finished it: the feed, the X integration, wallets, PayPal, and payouts.”
Founder

FAQs

Can you take over an app an agency left half-built?

Yes. I start with a review of the code, keep the parts that are solid, and rewrite the parts that won't hold up. Then I finish the product. This app was half-built by an agency and went live eight weeks after I took it over.

How do you build a wallet into a web app?

Keep every balance on the server as the single source of truth, record every deposit, stake, and payout as its own entry, and never trust a balance sent from the browser. Use a payment provider like PayPal or Stripe for deposits, and confirm each payment before crediting the wallet.

Can you build an app on top of X (Twitter)?

Yes, through the X API. It lets an app look up accounts and read public profile data like username, avatar, and follower count. Access tiers and pricing change, so check the current API plan before you commit to features that depend on it.

How do you build a first version of an unusual product idea?

Find the one flow that proves the idea, here posting a challenge, funding it, and paying out, and build that end to end before anything else. If people use the core loop, the rest is worth building. If not, you've learned cheaply.