I ran a permissionless token launchpad for a few years. Projects opened a sale, people bought in, tokens locked, airdrops went out. About ten thousand users. Real volume. By the time it was a proper platform, claim, unlock, and refund worked. People finished the path without writing in.
That was not true at the start.
In the early days the roadmap was whatever made the next project pick us: a new sale type, a nicer featured slot, a page that looked like a bigger platform. The inbox was not asking for any of that. It was the same message, again and again. The sale ended. I clicked claim. Nothing arrived. The page still said completed. Or the lock date passed and unlock failed. Or I sent the wrong asset into the contract and the screen had no sentence for me.
I treated those as support. They were the product — until we made them the product, and the inbox went quiet.
What we built instead
Project teams are loud. They want a new template before they launch. They want their pool on the first screen. A thread will ask for a feature a competitor just posted. That work has a demo. You can ship it in a week and put it in a changelog.
Claim and unlock do not have a demo. When they work, nobody writes. When they fail, you get a wallet, a hash, and a person who already spent money.
Early on we still built the template first. I could walk a founder through the new sale flow in a meeting. I could not explain a failed claim without opening the contract and the indexer. If an engineer has to interpret a user’s own tokens, you did not finish the last launch. You started the next one.
I called the repeats edge cases. Wrong token. They left the page open overnight. They claimed before the sale account was finalised. That is not an edge if it is how people actually use a launchpad. It is the path after buy — and we had spent the quarter on the path before it.
The spec that was already in the inbox
The sale ending is not the job ending. The job ends when the tokens are in their wallet, or the screen says exactly why they are not, in language they can act on.
That means claim has real states: not ready yet, ready, failed, wrong wallet, already claimed. Unlock the same. Refund the same. Success is not our server accepted the click. Success is the balance moving.
When we finally wrote that as the spec, the next stretch was statuses and copy, not a new sale type. It looked smaller on a roadmap. Claim and unlock became reliable. The inbox dropped. After that, the launchpad ran the way it should: buy, wait, claim, unlock, done.
What I do now
I read recent tickets before I add a row to a roadmap. If the same sentence keeps arriving, that is the work. The founder request can wait.
I do not ship a green screen because the transaction was submitted. I ship it when the user can see the tokens, or we have told them why they cannot.
The line we send in a support reply should already be on the page. If we can only say it in email, we hid the failure.
A plan still matters. A loud request can still be right. It does not go first while people who already paid are stuck on the last button. Once that path is solid — and on that launchpad, it was — you have earned the right to build the next template.