1Dapp Launchpad

Meme coins live and die in their first week. The token itself takes minutes to deploy. What decides the outcome is everything around it: who hears about it, who holds it, who keeps trading it on day three.

The launchpad puts that whole apparatus in one place. A creator lists a token, sets a launch date, and buys attention through quests and boosts. A participant browses launches, completes quests for crypto and points, and accumulates NFTs that can be sold back into a shared bank.

Two audiences, one interface. That constraint shaped most of what follows.

Each one could have doubled the product. Each was solved with one skeleton instead of two.

The research here is desk only: no interviews, no usability tests, no analytics. I had no access to users and the budget did not include it. So everything below is a documented hypothesis, reconstructed from competitor products, the client brief and the mechanics of the space.

I say that out loud so you can judge the reasoning itself, and the reasoning here is mine. Two roles, creator and participant, reconstructed from the product flows, and every decision in this case traces back to a specific job of one of them.

71 components and 8 variant sets: the token card, the quest row, the header, the buttons, the chain and social chips. All real sets with real variants, not frames named like components.

The number that matters here is 5,949 instances. It means the library was not just delivered but used throughout: screens were assembled from it rather than drawn next to it. On a 123-screen product that is the difference between a library and a folder of mockups.

Type and spacing in this file are still applied on nodes: Figma variables and modes did not exist at the time, they arrived later. What the same kind of product looks like once a token layer is possible is in the neighbouring CB Tools case.

The token list is the home of the product, so it carries filters that stack rather than nest: sort, chain, status and a boost-only toggle. Plus search, its own empty state, and the points explainer that teaches the economy inside the list instead of on a separate page.

Four steps: Initial, Website, Tasks, Finalize. Step two offers a free subdomain and hands off to the ecosystem site builder, the product covered in the 1Dapp Constructor case. Step three is quests. Step four is when and how loudly.

The launch date sits last on purpose: by the time a creator reaches it, they have already committed to a promotion plan. The wizard is not collecting fields, it is walking someone to a decision.

The file realises `2xl [1536]`, `xl [1280]`, `lg [1024]`, `md [768]` and 360 as the base. Frames are drawn at a representative width inside each range, 1920 for 2xl down to 1024 for md, with 1536 carrying the twelve column grid.

What that meant in practice: the launchpad list goes from a four-across card grid to a single column and moves the sidebar filters into a sheet. The token page turns four stacked sections into four tabs. Modals become full-height sheets below md, so the type picker and the DEX chooser are drawn twice.

None of it was left to engineering to decide. Where a grid had to re-form instead of shrink, the mockup says so.

The file went to the engineering team closed: no "to be defined" placeholders, every quest type drawn in all four result states. I did not see the release, so there are no business metrics here and none will be invented.

While refactoring the file in 2026 I also proofread it and handed the client a list of copy defects that would otherwise have shipped: seven of them, from `epmty` in a creation form to a referral link missing the dot in its domain.