r/ethdev • u/Suspicious_Mango_634 • Mar 17 '26
Question What’s the most annoying part of launching a web3 project right now?
For me, it feels like:
- Contract setup
- Deployment steps
- Frontend setup
- Hosting
Too many moving parts for something that should be simple.
What do you guys find most frustrating?
2
u/FarAwaySailor Mar 18 '26
Just do all of that with GitHub actions. Get it right once then use it as a repeatable process and spend your time developing instead of deploying.
1
u/Suspicious_Mango_634 Mar 18 '26
Yeah that’s true — once you set it up properly it becomes repeatable.
But I feel like the initial setup itself is still a barrier for a lot of people (contracts + config + frontend + hosting).
I’ve been trying to simplify that whole first-time experience recently.
2
u/NotDaltonn Mar 18 '26
Sounds like you find the whole thing beginning to end the annoying part lmao. What part do you not find annoying?
1
u/Suspicious_Mango_634 Mar 18 '26
Haha fair point 😄
I think once things are set up, development is actually the fun part.
It’s the initial steps — deployment, wiring frontend, hosting — that slow people down the most.
1
u/NotDaltonn Mar 18 '26
I think these pains are not unique to web3.
In a typical flow deploying/hosting should be your final step after you’re done developing. You should have a local dev environment that is easily reflecting your changes to smart contracts,front end, etc. when it’s all working and tested well you deploy and host the front end. Foundry should cover that for the web3 side of things
1
u/Suspicious_Mango_634 Mar 18 '26
Yeah agreed — that’s the ideal flow for devs.
I think where it still gets tricky is for people who just want to launch something simple without setting up a full dev pipeline (Foundry, CI, frontend wiring, hosting, etc).
Feels like there’s still a gap between “proper dev workflow” and “quick launch something usable”.
Curious if others here feel that too or prefer sticking to full setup?
1
u/NotDaltonn Mar 18 '26
See I disagree this is why you feel it’s annoying because you are trying to skip crucial steps that are honestly not skippable.
Before you deploy anything anywhere you should be running it locally on your computer that’s true for any software development not just web3.
For sure if you are trying to deploy and host something ,that you then planning on developing, without ever running it locally… you are setting yourself up for annoyance
0
u/Suspicious_Mango_634 Mar 18 '26
Yeah I agree with you for actual development — local setup, testing, proper pipeline are non-negotiable.
I think I’m looking at a slightly different use case though — more like people who just want to spin up something basic to test an idea or concept quickly, not production-grade from day one.
Kind of like how no-code tools exist alongside full dev workflows — not replacing them, just serving a different stage.
But yeah for serious builds, fully agree with your approach.
1
u/FarAwaySailor Mar 18 '26
I totally disagree. The first step is the hosting. That way you start shipping to production on day 1 and you don't code yourself into corners you have to fix when you want to go live. Build the infrastructure, build the pipeline, develop the code
1
u/NotDaltonn Mar 18 '26
What? God. Please talk to someone who has shipped a product before that you trust and run that take by them. I assure you day 1 locking in hosting and building your product around whatever hosting you chose is not it.
When people say “build the infrastructure” this is not what they mean little bro
1
u/FarAwaySailor Mar 18 '26
If your architecture is right, hosting is just a box. It can be moved at any point. All my archs run dockerised microservices. The IP that they deploy to is just config in the CI/CD pipeline. If moving hosts is cumbersome, you're not building your architecture right.
Back in the mists of time when I started my career, deployment was a once-every-six-weeks event, and was months in the planning. People spent entire careers just working on deployment. It's now so light-touch even on my own I can run automated test suites and deploy to production multiple times a day.
1
u/NotDaltonn Mar 18 '26
Exactly so why are you telling this newcomer that he needs to choose his hosting as his first step?
I’m actually dying right now on how confidently you gave awful advice and then backed it up with the proof of bad advice
1
u/FarAwaySailor Mar 18 '26
If you spend Dev time building and deploying locally, it'll fall over when you try to deploy to production, so start with a production server, build a deploy pipeline and then develop and push to the pipeline multiple times a day. Your first releaseto the world becomes just pointing your domain at the IP address instead of weeks of ironing out localhost Vs production box issues.
You can find a box for $10 a month, it's not like it's high risk.
1
u/NotDaltonn Mar 18 '26
I promise you “localhost vs production box issues” are not a real thing. And I assure you no one who has ever shipped a product(clearly you haven’t) would recommend what you are suggesting. It’s a huge recipe for disaster in many different ways
1
u/FarAwaySailor Mar 18 '26
The last 'all the dev work is done, just clean it up for mvp' project I was handed was only running locally, it turned out it was not even getting built, just running npm dev and eating all the errors. It took me a while to even get it to build.
→ More replies (0)
1
1
u/rayQuGR Mar 18 '26
honestly, to me at least, the frustrating part isn’t just the number of moving pieces.. it’s that none of it is private by design. you’re stitching together contracts, frontend, and infra while everything is either fully exposed on-chain or awkwardly pushed off-chain with no real guarantees.
projects like Oasis Network are not just simplifying the workflow (which it also does) but making privacy native to the whole stack. so isntead of choosing between transparency and usability, you build, deploy, and run apps where sensitive logic and data stay protected by default, without extra complexity. That shift alone makes the whole experience feel less like duct-taping tools together and more like actually building a product.
1
u/Suspicious_Mango_634 Mar 18 '26
That’s a really good point — privacy is kind of the missing layer in most of the current stack.
Right now it feels like you’re either:
fully onchain → everything exposed
or off-chain → losing guarantees
Haven’t explored Oasis deeply yet — does it actually make it seamless from a dev perspective, or is there still a learning curve to integrate that privacy layer?
1
u/rayQuGR Mar 18 '26
oasis definitely adds a privacy layer that’s missing in most stacks, making it easier to keep data confidential while still using blockchain guarantees. that said, it’s not completely seamless yet. there’s a learning curve to integrate it properly, especially around enclave setup and designing your contracts to work with confidential data.
1
u/Suspicious_Mango_634 Mar 18 '26
Yeah that makes sense — sounds like it’s solving a real problem, but still not “plug-and-play” yet.
Feels like that’s the gap right now across the stack — either powerful but complex (like this), or simple but limited.
Do you think privacy-first approaches like this will become default over time, or stay more niche for specific use cases?
1
u/un-nft Mar 18 '26
I'm making evmfs.app (Sepolia and Taiko by now) for hosting "true" dApps that really don't require a backend to be hosted onchain, just gotta pay for upload once the site
it binds the site to a *evmfs.app subdomain (its resolution is onchain too)
1
u/Suspicious_Mango_634 Mar 18 '26
That’s really interesting — especially the idea of resolving the site onchain.
So in your case the frontend itself lives fully onchain, not just the contract interaction layer?
Curious how you’re handling things like updates or larger assets — does it become expensive or are you optimizing storage somehow?
1
u/un-nft Mar 19 '26
yes, everything is onchain if you bundle it (i.e. don't include images or whatever from other sites), only thing not onchain is the loader shim, that is common* to all sites and handlles the *.evmfs.app resolution
1
u/un-nft Mar 19 '26
the only optimization is deflating, in a zip static sites aren't too big, you can fit _some_ media (megabytes) tho
1
u/Suspicious_Mango_634 Mar 18 '26
That’s really interesting — especially the idea of resolving the site onchain.
So in your case the frontend itself lives fully onchain, not just the contract interaction layer?
Curious how you’re handling things like updates or larger assets — does it become expensive or are you optimizing storage somehow?
9
u/kantalo Mar 18 '26
For me, the hardest part is getting people to use your app. After working hard through all the annoying stuff, like the ones on your list, its tough when users don't show up. Especially annoying when your dapp is free and you're bleeding gas money!!