A few months ago I started building a small tool on Solana.
Nothing crazy.
Just something that lets you:
create a token
attach metadata
add liquidity
and actually use it
That was the idea.
Keep it simple.
The Plan Was Pretty Straightforward
I didn’t want to build another “platform”.
No custody.
No custom smart contracts I fully control.
Just an interface that prepares transactions and lets users sign everything in their wallet.
Basically:
backend prepares → wallet signs → chain executes
In my head, that felt clean and simple.
The First Reality Check
The blockchain part wasn’t the hard part.
Creating a token? fine
Sending a transaction? fine
The problems started when everything had to work together.
Everything Around the Chain Is… Messy
You don’t just “create a token”.
You end up dealing with:
metadata uploads (IPFS, gateways, broken links)
DEX integrations (each one slightly different)
APIs that don’t behave consistently
rate limits you don’t control
random failures you can’t reproduce
Some days it felt like:
API returns 200 → empty data
retry → works
retry again → rate limited
No real logic behind it.
I Had to Add a Backend Proxy
At first I was calling everything directly from the frontend.
Bad idea.
Moved everything into a Node/Express backend:
transaction building
DEX calls
metadata handling
That alone made things easier to reason about.
At least all the chaos lives in one place now.
“Non-Custodial” Sounds Simple (It’s Not)
“Users sign their own transactions” sounds great.
But it changes everything.
you don’t control execution
you can’t easily retry
you depend on wallet behavior
UX gets tricky fast
If something fails, you can’t fix it for the user.
You just… try again.
Rate Limits Became a Real Issue
Some endpoints were getting hit way more than expected.
So I added:
per-wallet limits when possible
fallback to IP
Then Redis wasn’t always available.
So I added a memory fallback.
Not perfect, but at least things don’t break.
External Services Are Not Reliable
For token images / metadata I used:
Uploadcare
Pinata (IPFS fallback)
Different formats everywhere:
ipfs://...
gateway URLs
CDN links
At some point I just gave up trying to “support everything properly”.
Now everything gets normalized on the backend.
One format. One output.
Less surprises.
The Part I Didn’t Expect
I thought I’d spend most of my time on:
blockchain logic
token creation
transactions
I didn’t.
Most of the time went into:
handling weird API responses
fixing edge cases
retry logic
cleaning inconsistent data
The glue code is the real work.
When It Started to Feel Different
There was a moment where nothing visually changed…
but the codebase felt different.
Less fragile.
Less “don’t touch this part”.
More predictable.
That’s when I knew it was actually improving.
Something I Really Didn’t Expect
I thought once the tool worked, builders would just… start using it.
That didn’t happen.
Finding Builders Is Way Harder Than Building
I tried a few things:
posting on Twitter
sharing in communities
reaching out to people
Most of it either gets ignored or feels forced.
And honestly, I get it.
There’s a lot of noise in Web3.
People don’t just switch tools because something new exists.
Even if it’s better.
What I’m Starting to Realize
It’s not really about “finding users”.
It’s more like:
being where builders already are
understanding what they actually need
not overbuilding before that
Right now I’m not aiming for 100 users.
I’d be happy with 2–3 real builders using it and telling me what’s broken.
Where It’s At Right Now
It works.
Not perfectly, but:
tokens can be created
transactions are signed in the wallet
liquidity can be added
no funds are ever held
That was the core goal.
Final Thought
Building in Web3 isn’t just about the chain.
It’s about everything around it.
unreliable APIs
wallet UX
edge cases
user behavior
The chain is actually the most predictable part.
If you’ve built something similar, I’m curious:
how did you handle unreliable APIs?
did you struggle getting real users early on?
Still figuring this out as I go.
Top comments (0)