Buy Tokens to Signal Real Priority — a New Swoin Feature Idea

DenisManig

I've been sitting with a problem I see on Swoin, and I think there's a gap worth filling. Here's the scenario:

You're a maker. Your supporters get 50 Innovation Tokens per month to vote on your roadmap — a fixed allocation they distribute across the features they care about. Feature A matters to them deeply. They want to support it, vote for it, help you build it. But they also care about Features B, C, D, and E. So they split their tokens. Feature A gets maybe 20. Or they put all 50 on Feature A and the others get nothing. Either way, they can't show you: "Feature A is genuinely important to us. We'd invest more to see it built if we could.". And that's the problem.

The Old Way — and Why It Failed

This problem isn't new. For years before Swoin, here's how it worked:

A supporter contacts you directly. "We need Feature X. What would it cost?" You quote a price. They pay full price privately. Another supporter needs the same feature. They never knew it was being negotiated. They either pay full price too (duplicated costs), or the feature is free. Unfair for everyone involved. And here's the worst part: feedback only came from one person. Maybe Feature X would have been 30% better if your other supporters had a chance to contribute ideas. But they didn't know it existed.

One supporter paid everything. You built to one spec. Everyone else was locked out. That's not fair, and it's not efficient.

What Would Be Better

On Swoin, you have a better structure: transparent roadmaps, your supporters can see the features you're considering, they vote with their tokens, they give public feedback. But the token voting system has a ceiling. Your supporters have a fixed monthly allocation. If they want to express stronger support than 50 tokens allows, they can't. What if they could buy additional tokens?

Here's the idea: Your supporters want to back Feature A. They need more voting power to signal how much it matters to them. They buy 50 additional tokens (or 100, or 20 — whatever they decide). That money goes to you. Those tokens go directly to Feature A on your roadmap.

That's it. Simple.

Why This Matters

For your supporters: They can show you exactly what they want to fund. Feature A gets their monthly allocation plus the tokens they bought, because they mean it. You see that they cared enough to spend. That's real commitment.

For you (the maker): You see something crucial. When supporters buy tokens specifically for one feature, that's a more intense signal than subscriptions included votes. It says: "We care enough about this to invest more of our own money." That's real demand. Real market signal.

Compared to the old model: The feature is developed transparently, not in private contracts with one paying customer. Multiple supporters contribute feedback. Your entire community sees it happening. The financing is fair — nobody bears 100% alone, and everyone involved knows everyone else invested something too.

This Is Not About Squeezing Money

Let me be clear: this isn't a fundraising mechanism disguised as voting. I'm not trying to turn your roadmap into a paywalled pitch.

It's about honesty. Your supporters have genuine priorities. The current token system gives them a way to express some of them. This would give them another tool when one feature matters enough that they want to signal: "We'd back this."

And yes, you see additional revenue. That's not hidden. I think that's actually good — it means features your community truly cares about get built faster, and you can allocate more time to them. That's sustainable.

What This Is NOT

This is not Community Bounty. This is just: additional tokens for sale, so your supporters can invest more in the features that matter most to them.

Does This Sound Useful?

I genuinely don't know if supporters on Swoin would use this. It might be that the current monthly allocation is plenty, and buying more feels unnecessary. Or it might be that knowing they _could_ have backed Feature A if they'd invested more changes how they think about their token allocation.

Either way: let me know if this solves a real problem, or if I'm chasing something that doesn't matter.

Support this project

Get access to exclusive content and support the development.

Subscribe now
Discussion

You need to be a supporter to join the discussion.

Support now