I was building Crowdwide, a social media platform I started for new indie devs, smaller communities, and smaller creators to raise their voices hig...
For further actions, you may consider blocking this person and/or reporting abuse
@akhourianmolkumar @koda2026 and @technogamerz joined, so me too joined! 🥳
Bro i just joined now and bro when i use '@' and type the lazy girl i cant find her and i tried it with 𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 still i cant find it and i cant find her with technogamerz how you find her lol 🤣
Me too cannot find her so I just type it and then verify by clicking the link after commenting (it takes extra work to mention her lol)
Wait i need to test it @technogamerz
Yeah it works hahahaha 🤣 bro actually lets talk in my latest post please
And my username bro????
The sequencing here is the thing I would highlight back to you: core algorithm and mailing system done before UI polish is exactly the order that keeps an MVP alive. I have seen the reverse too many times — founders polishing gradients while the activation path is broken, and the pretty UI becomes expensive camouflage for a product nobody gets to use. Making the mailing system part of the core feature set is the interesting call to me; most social MVPs defer notifications and then wonder why nobody comes back for a second visit. And overlaying the sidebar instead of compressing the page is the right instinct — reflow shifts on every toggle would have been a paper-cut complaint from every user, every session. One concrete question: for the theme contrast issues you fixed, are you checking those ratios by eye, or against a standard like WCAG? A systematic pass with a contrast checker before the next theme update would catch the bad pairs before your users do.
that's some really valuable feedback!! 🤝
Honestly, I was mostly checking the theme contrast visually, but you're right, using WCAG contrast ratios would be a much more systematic way to catch issues. I'll look into running a proper contrast check before the next theme update!
And yeah, I really wanted to get the core features stable before spending too much time polishing the UI Thanks for the detailed feedback, really appreciate it!!
That sequencing instinct is worth protecting. The cheapest version of a systematic check I have used: run your palette tokens through a contrast checker once (axe DevTools has a quick theme-level pass) and pin the minimum ratios as lint rules. I once caught a failing secondary-button state that way that looked perfectly fine to my eyes.
Core-first really is the order that keeps momentum. What part of the polish pass are you most looking forward to once it is stable?
that secondary-button example makes so much sense! 🔥 I'll definitely check out axe DevTools and try to make the contrast checking more systematic.
and honestly, I'm most looking forward to making the whole UI feel consistent across themes and getting the sidebar and feed interactions really smooth! Once that's stable, I can focus more on user requests and moderation.
Visual contrast checks lie in exactly the way WCAG ratios don't — I once shipped a 'looks fine' secondary button that failed at 2.1:1 on a projector during a demo. axe DevTools will also catch focus-order issues that contrast tools miss, which matter more for keyboard users. Core-features-first was the right call, by the way — polish on an unstable layout is just expensive repainting. Which page are you running axe on first?
that 2.1:1 example is wild 😭 I'm gonna start with the high-traffic pages first: landing page, dashboard, posts/articles, polls, Widewave, and community pages!
Also, I'm curious about something — how can a page look perfectly fine visually but still fail the WCAG contrast check? 🤔 Is it mostly because our eyes perceive colors differently, or are there other factors too?
Huge congrats on hitting Day 21! Getting the core algorithm and mailing system done before touching the UI is a massive milestone. For the sidebar dilemma—you made the right call going with the overlay approach. Compressing the main feed causes heavy layout shifts and reflows, which feels really clunky, especially when users are just trying to peek at navigation. Keeping the main content fixed and just dimming the background is much smoother. Also, for that gradient stretching issue you mentioned, using background-attachment: fixed or a fixed pseudo-element behind the content usually fixes the weird top shading. Good luck with the remaining polishing, and thanks for the #HackerStage shoutout!
thank you so much!! 🔥 And yeah, the overlay approach feels much smoother instead of compressing the whole page!
Also, thanks for the gradient fix suggestion, I'll keep that in mind! Really appreciate the detailed feedback and support, bro! 🤝
Anytime, bro! Glad the gradient fix makes sense. Keeping the overlay UI is definitely the right call for maintaining focus. You're absolutely crushing it on this build-in-public journey, keep going! 🔥
appreciate you bro!! Thanks for the support, means a lot! More updates coming soon
You're very welcome! Looking forward to seeing what you build next. Take your time with the upcoming updates, and keep crushing it!
🙌🙌
Can you add optimistic UI updates? Now when I try to like a post, it takes quite a while. If you want to make it accurate, then what about something to indicate that it's still loading?
YESSS!! I actually saw your post about this yesterday, added it to my to-do list, and started working on it a little yesterday! I'll get it done today!! Thanks for suggesting it, bro!! 🤝
Thanks for taking me seriously bro ☺️
BROOO, OF COURSE!! 🤝 Your suggestions matter, and if something can make Crowdwide better, I'll definitely take it seriously!! We're building this together!!
Ok! 😄 Thank you so much! ☺️
🤝 always bro, keep the suggestions coming
The sidebar overlay sounds like a good choice, especially for avoiding layout shifts. One thing I'm curious about: when you're polishing a UI, how do you test what happens when the user interacts with it under less-than-ideal conditions?
For example, if someone clicks a button to create a post and the request fails, does the UI preserve their input and let them retry? Or if they click twice before the first request finishes, how do you prevent duplicate actions?
Do you have a small checklist for testing these edge cases, or do you usually discover them while using the app? I'd love to hear how you approach this as Crowdwide grows!
I’ve made my repo public and I’m building Crowdwide in public so everyone can see what I’m building and suggest changes I can make. Actually, most of the features and improvements in Crowdwide are suggested by users themselves!
For the optimistic UI, I built a system on the frontend and adjusted the backend accordingly. For example, when you click the button to post something, it disappears immediately without waiting for any server response, and you just see
Posting.... That’s how I prevented users from clicking the button multiple times while the first request was still processing.I’ve also made a basic checklist for testing the UI and other edge cases, but honestly, I discover the more serious issues when I test the app like a real user and use it normally. 😅
That’s also one of the reasons I’m building in public — people can use Crowdwide, suggest improvements, and help me discover things I might have missed!
You changed the logo
which logo?
😭 i used AI to generate the banner of post... so tht ai added random logo there
logo of crowdwide is same lol
21 days in and core algorithms + UI polish done is a huge milestone! Congrats on staying consistent with #buildinpublic! 🚀
Regarding your sidebar dilemma: making it an overlay with a backdrop blur/dimmer (rather than compressing the page content) is almost always the smoother choice—especially for mobile or responsive web layouts. It keeps layout shifts to a minimum.
Good luck with the final stretch and moderating! Rooting for Crowdwide! 🙌
thank you so much!! and yesss, the overlay approach felt like the better choice to keep things smooth without shifting the whole page! Really appreciate the support, we're getting there!! 🤝
I have a built a cli based sql anamoly triage detector and I'm new to this kinda stuff . How do I find beta testers
Since you're just starting out, I'd suggest sharing your project in communities where developers and database engineers hang out. You can try Reddit, DEV Community, relevant Discord servers, and LinkedIn.
Make a short demo showing how your CLI tool detects SQL anomalies, explain who it can help, and ask people to try it out and share feedback. You don't need a huge audience even 5–10 relevant testers can help you learn a lot!
Also, make sure your GitHub README clearly explains how to set it up and try it. All the best!
UI polish is one of those stages where small decisions can make a big difference to how a product feels. I like that you focused on readability and the sidebar instead of just adding more features.
A platform built to give smaller creators a voice also needs to feel comfortable and intuitive enough that people actually want to stay and use it.
Exactly and i just realized that i made UI little bit complex...
Providing too many option in front just after login... I need to fix that too 🙄