I shipped 3 features this weekend based entirely on community feedback. Here's what I built and why.

Three features in a single weekend is a heavy lift. This kind of speed usually builds a lot of user trust because people see their feedback turn into code almost immediately. It keeps the product from bloat since the focus stays on actual user needs. Did you prioritize these based on the number of requests or just what was easiest to ship fast?

I’ve been following since your launch post (the one that hit #1), and honestly this update makes way more sense than just adding random features.

The build log especially feels underrated, most ‘build in public’ stuff is scattered across Twitter, but this kind of centralizes it into something permanent.

The verified MRR is interesting though, feels like a strong trust signal, and Build log is also lowkey powerful. If people actually use it consistently, it becomes like a live resume.

Overall though, good stuff man this is getting interesting. You’re clearly listening to feedback instead of just shipping blindly

Wait you’re the same guy who hit #1 on Build Board right? Crazy how fast you’re iterating, didn’t expect you to ship this much this quickly.
Looked at the updates you made are really good, love the build log concept. worth following you bro !!

the github stars auto-sync is the kind of small detail that separates this from every other portfolio builder. most people underestimate how much third-party validation matters — seeing a real star count with a verified badge instantly changes how you evaluate someone's project versus just reading their self-written description. we learned something similar selling dev tools — the moment we added a live demo where people could test the SEO analyzer on their own site, conversions went up vs just describing what it does. proof beats pitch every time.

verified MRR is the feature that changes the whole positioning here. every founder portfolio right now is basically self-reported numbers, which means there's zero built-in trust. being the first tool where the revenue is actually proven shifts this from "another link-in-bio" to something investors and potential collaborators would actually check. the build log is smart too but i think for different reasons, it's more about showing consistency than proving results. curious which side is getting more pull from users so far, the verified metrics or the build log storytelling?

The Verified MRR feature is genius — cryptographically verified revenue solves the biggest trust problem in the indie hacker space. Too many people claim "$10K MRR" with zero proof. Making verification the default changes the entire dynamic.

We take a similar "proof over claims" approach at AnveVoice. Instead of saying "fast voice AI," we publish actual latency numbers (sub-700ms). Instead of "supports many languages," we list exactly 50+ languages including 22 Indian languages + Hinglish. Instead of "AI-powered," we show the real DOM actions our voice assistant takes — clicking buttons, filling forms, navigating pages.

Your three learnings resonate hard: shipping fast, listening > building in isolation, and distribution > validation. We've found that the features users actually want are rarely the ones you'd prioritize yourself. Community feedback as a product roadmap is underrated.

The Build Log creating a living timeline is particularly smart — turns your landing page into social proof that compounds. Nice execution on shipping all three in a weekend.

This is a textbook example of why "build in public" actually works when done right — you're not just sharing updates, you're turning your audience into your product team. The Build Log feature is particularly smart: it transforms a static profile into a living artifact that compounds over time. Visitors who see an active, evolving timeline are far more likely to trust the builder behind it than someone with a polished-but-frozen landing page.

The GitHub stars sync is a nice trust signal too — third-party validation that doesn't require the builder to say anything themselves. Curious how you're thinking about the tension between "public" and "authentic" as the platform grows — do you have any friction to prevent people from gaming the upvote system on build log entries?

Thanks for sharing this mate. Build features based on customers feedback is the perfect things to do, because you build a product users want. Congrats on that!

This is a great example of why shipping based on real user feedback beats building in isolation. The verified MRR via Stripe is a smart differentiator — proof over claims always wins with other builders. Keep iterating!

that build log feature is the right call. I always struggled with showing progress on my side projects in a way that felt alive rather than just a landing page collecting dust. shipped something similar for NoHumans where the agent logs its own actions publicly and found that transparency loop actually brought more feedback than any launch post. the community feedback -> build -> ship cycle you describe is real, took me a while to not be defensive about what people said was missing

Build log + verified MRR is a killer combo for trust. When someone lands on your page and sees real proof of shipping velocity alongside revenue, it removes all the "is this legit?" friction instantly.

We took a similar feedback-driven approach with AnveVoice — our users kept asking for voice-based navigation on their websites, so we built an AI assistant that actually takes DOM actions (clicks, fills forms, navigates) instead of just chatting. Community feedback shaped the entire product direction.

The "Distribution > Validation" mindset resonates hard. Ship fast, listen, iterate. That's how you build something people actually want. Bookmarking IndieDeck — love the concept of turning a static portfolio into a living builder story.

This feels like one of those subtle but important shifts — you’re not just adding features, you’re making the page more credible.

Build log + verified MRR means someone landing there doesn’t have to guess anymore, they can just see what’s real. That usually changes the kind of conversations you get.

Would be interesting to see which one people react to more in practice.

Love seeing feature decisions come straight from the community — that’s how truly useful products get built. The Build Log and Verified MRR ideas are great examples of turning user voice into real positioning rather than just cosmetic updates.

One thing I’d be curious to hear from others here: how do you balance feature requests from vocal users vs. latent needs you observe from user behavior (like analytics or session data)? Because sometimes the loudest voices aren’t the most widely representative of your audience.

In my experience, the creators who systematize feedback — tell users what they built because of their suggestions and then track actual usage — tend to build features that stick instead of features that just feel good to ship.

The Verified MRR via Stripe is smart positioning. Anyone can put '£2k MRR' in a bio. Cryptographic verification makes it real. That one feature shifts IndieDeck from portfolio tool to credibility tool, which is a much stronger hook for the audience you're building for.

I'd push back slightly on 'distribution > validation' though. What you actually did was validation done right. You shipped, community told you what was missing, you listened and built it. That's not distribution first. It's listening first, done publicly. The distribution was a consequence of doing that listening out in the open. Most people get this backwards — they validate in private then wonder why nobody cares when they ship.

Congrats on the #1 spots. How are people finding IndieDeck now that the launch boost has settled?

The real trap with feedback-driven shipping is building what people say they want instead of watching what they actually do in your product. Three features in a weekend sounds productive but you can end up with a cluttered product that satisfies vocal users while confusing the quiet majority who churn. Would love to hear which of the three got actual usage after you shipped it.

How are you verifying MRR exactly? Stripe API or something custom?