I shipped 3 features this weekend based entirely on community feedback. Here's what I built and why.
A few weeks ago I launched IndieDeck here with zero expectations. Hit #1 on the Build Board, then #1 on other two platforms (Launch cab and Just hunt). All organic. https://www.indiehackers.com/product/indiedeck-2
Last week of feedbacks was brutal and valuable in equal measure. Builders told me exactly what was missing and they wanted. So I went heads down and built it.
Here's what just shipped:
- Build Log: a public timeline of your builder journey. Launches, milestones, updates, archived projects. Visitors can upvote and comment directly on each entry. The goal was to turn a static page into a living story. It's live and working.
- GitHub Stars: paste your repo URL and your star count auto syncs and shows on your project card with a verified badge. One API call, zero manual work.
- Verified MRR: connect Stripe and your real MRR shows on your page. No fake numbers. Cryptographically verified.
A two things I learned building this in public:
- Shipping fast
- listening beats building in isolation every time.
- Distribution > Validation
Every single feature above came directly from a comment on my last post here.
Build log and Verified MRR is something no other link-in-bio tool has. That one feature changes the positioning completely, this isn't a portfolio page anymore, it's proof of everything you've built and earned.
you can check it our here: indiedeck.page
Also, I put together a demo page so you can see exactly what it looks like in practice
https://www.indiedeck.page/mehsssi
Still early. Still learning. Still shipping. Would love feedback from this community as always.
What strikes me most about your approach is how the Verified MRR creates a natural anti-gaming mechanism. Someone would have to maintain actual paid Stripe subscriptions to inflate their number — that costs real money. It's the kind of verification where honesty is cheaper than faking it, which is rare in any tool. I'm curious how you're thinking about the edge case of someone temporarily inflating their MRR for a specific moment — like fundraising or a big launch — then letting subscriptions drop after the credibility does its job. Has that come up in feedback?
This is exactly how agency work should be done too. At Kinvero, we've learned that our best campaigns come from listening to what clients actually struggle with, not what we think they need. Your Build Log feature is brilliant - we're thinking about implementing something similar for client project transparency. The speed from feedback to feature is what separates winners from planners.
This is a strong example of why building in public works when the feedback loop is real.
What stands out here is not just fast shipping, but the quality of the changes:
Build Log and Verified MRR are especially smart additions. They don’t just add features — they make the product feel more credible and more differentiated.
Very solid iteration.
Love this! Shipping based on direct feedback is the ultimate cheat code for product-market fit. It keeps the momentum high and the community engaged. Which of these three had the biggest impact on your retention so far?
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
The "live resume" framing is exactly how I think about it too. your build log over time says way more than a static portfolio. and yeah the build in public problem is real, it's all scattered and ephemeral on twitter. this makes it stick somewhere.
verified MRR is still early but the trust signal angle is the whole point. glad it's landing that way.
appreciate you following along since day one, means a lot!
exactly, the build log format is underrated. people invest emotionally before the product is done. by launch day they already feel ownership. launch posts to cold audiences just dont have that
yeah same, the progress updates pull way more engagement than "hey I launched X". I think people want to bet on the horse before the race, not after. been doing this with NoHumans and each weekly update gets more comments than the launch post did
Yeah that makes a lot of sense.
Feels like people want to see the journey while it’s happening, not just the final result. The build log is kind of leaning into that, giving them something to follow and react to over time.
Interesting to hear you’re seeing more engagement on updates than launches, that’s a strong signal.
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 !!
haha yeah that's me! thanks man, really appreciate it. the build log idea came from user feedback so just trying to ship what people actually want. means a lot, follow back! 🤠
This is really interesting.
I’ve been thinking about this space while building something myself, and one thing I’ve noticed is that people struggle more with execution than the idea itself.
I’m currently testing a small tool around this—not fully sure if it’s useful yet.
Would you be open to taking a quick look and sharing honest feedback?
Appreciate it.
Yeah I’d be open to taking a look, feel free to share it.
The Verified MRR feature is a really smart move. Every indie hacker page out there lets you claim whatever numbers you want — having Stripe-verified revenue on your profile changes it from "trust me" to "here's the proof." That alone makes this a different category from a typical link-in-bio.
The Build Log is interesting too. I've been doing daily build-in-public posts on X and the biggest challenge is that tweets disappear after a day. Having a permanent timeline of your journey on your own page solves that.
Curious about one thing — with the GitHub Stars and Verified MRR, are you thinking about letting people embed those badges on their own websites too? Like a verified "built by" widget they can drop on their landing page. Feels like a natural extension.
Appreciate that, that’s exactly the shift I was aiming for, moving from “trust me” to actual proof. And yeah, same observation with build in public posts. They get attention for a day and then disappear, so having it live on your own page just makes it more useful over time.
The embed idea is interesting. Haven’t built it yet, but it does feel like a natural extension, especially for people who already have their own sites and still want to show that proof layer there.
Something I’ll definitely explore.
This is great.
The part that stood out is building directly from community feedback instead of guessing.
Quick question—
How are you deciding which feedback to actually act on vs ignore?
I’ve seen situations where there’s a lot of input, but not all of it moves the product forward.
Appreciate it. I mainly look for patterns, if the same thing comes up from multiple people, it’s usually worth paying attention to.
Like in my case honestly: Build Log and GitHub Stars came from 25+ comments across my last post here. Not one or two people saying "that would be nice" but the same request showing up repeatedly in different ways from different builders. That kind of repetition is as close to a commitment signal as you get without charging upfront.
Verified MRR was different. Nobody asked for it directly. The community asked for credibility signals and proof of traction. I took that insight and went one level deeper as a founder. Connecting directly to Stripe so the number is verified not typed felt like the right answer to the underlying problem they were describing.
the "status badge should be a conscious human decision" framing is really sharp. i had the same instinct with ideadose — automated scoring sounds good in theory but the moment you remove human judgment from the loop, people stop trusting the output.
both features sound like they'll land when the timing is right. the discipline to say "not yet" is underrated.
Appreciate that, exactly my thinking.
Automation sounds good on paper, but once people don’t understand how something is decided, trust drops fast. Keeping status as a conscious choice keeps it honest.
And yeah, “not yet” has been the hardest part so far. Trying to stay focused on what actually improves the core experience first.
The interesting part isn’t the features — it’s how quickly the product identity shifted once real feedback came in.
Hitting #1 gets attention, but the brutal feedback loop right after is where most builders either stall or overcorrect. You didn’t — you compressed that into a tight build → feedback → ship cycle, which is exactly where things start compounding.
Build Log + Verified MRR is a strong combo. One captures narrative, the other anchors it in proof. That changes it from “link-in-bio” to something closer to a public execution ledger. Feels more like “show your work + show your numbers” in one place.
Also agree hard on distribution > validation. People don’t just tell you what to build — they tell you how they perceive what you’ve already built. That’s way more valuable than isolated ideation.
Curious how you’re thinking about:
preventing fake/edge-case MRR (refunds, trials, etc.)
long-term engagement with Build Logs (what keeps people updating?)
whether this becomes a tool for builders… or a signal layer for investors/hirers
This feels like it’s moving out of “tool” territory into “identity layer for indie builders” if you keep iterating in public like this.
"Public execution ledger", that's the best description of what this is becoming that I've heard from anyone. Saving that one.
On your three questions:
The "identity layer for indie builders" framing is exactly where I want this to go. You articulated it better than I have internally. 🙏
Love that you turned community feedback into shipped features over a single weekend. That loop of "listen, build, ship, repeat" is honestly the hardest thing to get right as a solo builder because it requires you to set aside your own assumptions about what matters.
The Build Log feature is especially smart. I'm building an AI app (Sorti, for organizing saved phone content) and one thing I've learned is that showing the journey publicly builds trust way faster than any landing page ever could. People want to see the process, not just the polished result.
Quick question: how do you decide which feedback to act on first when you're getting pulled in multiple directions? I've struggled with that balance between "what users want now" vs. "what the product needs long term."
Setting aside your own assumptions is genuinely the hardest part. Every founder thinks they know what the product needs. The humbling moment is when 25 strangers tell you something completely different and they turn out to be right.
On Sorti, showing the journey publicly building trust faster than any landing page is something I feel deeply now. A polished landing page tells people what you want them to believe. A Build Log shows them what actually happened. The difference in trust is massive.
On your question about prioritizing feedback, the framework that worked for me was simple. I looked for the same request showing up repeatedly from different people in different ways. One person asking for something is an opinion. Ten people describing the same pain independently is a signal. When Build Log, GitHub Stars and credibility signals kept appearing across comment after comment the decision made itself.
The "what the product needs long term" question I try to answer separately as a founder. Community tells you what hurts right now. You have to figure out what the product is becoming. Verified MRR was my answer to that second question. Verified MRR was different. Nobody asked for it directly. The community asked for credibility signals and proof of traction. I took that insight and went one level deeper as a founder. Connecting directly to Stripe so the number is verified not typed felt like the right answer to the underlying problem they were describing.
I lean towards things that improve clarity and trust right away. Those seem to compound faster.
#1 on three platforms organically is no small thing —
congrats Vipul.
The Verified MRR feature is the smartest move here.
"Cryptographically verified" flips the whole trust problem
on its head. Every other portfolio tool is essentially
just self-reported numbers. You just made the bragging
credible.
Build Log is interesting too — turning a static page into
a living timeline is the right direction. Investors and
collaborators don't just want to see what you built, they
want to see how you think and iterate over time.
One question: are you seeing builders use IndieDeck more
as a distribution tool (to get discovered) or as a
credibility tool (to close deals/partnerships)?
---
Your point about "listening beats building in isolation"
hit close — I just launched a React Native CRM template
for real estate agents (ImmoPro) and the first feedback
I got already reshaped two screens completely.
Early stage is humbling but nothing beats shipping and
seeing real reactions.
Still learning too. Keep shipping!
Thank you genuinely, hitting three platforms organically still feels surreal honestly.
On your question, right now it's mostly credibility tool. Builders are using their IndieDeck page when pitching to investors, reaching out for collabs, or responding to "what have you built" questions. The page does the explaining so they don't have to fumble through five links.
The discovery angle is still early but Build Log is where I think that shifts. When someone posts a milestone and it gets comments and upvotes, that entry becomes a touchpoint that brings people back. Over time that compounding is what turns IndieDeck into a distribution layer not just a credibility layer. Both in one place is the long term vision.
On ImmoPro, two screens reshaped from the first round of feedback is actually a great sign. It means the core idea is right and the details needed calibrating. That's the best possible outcome from an early launch. Keep shipping. 🙏
The build log as a public timeline is a smart move. Most portfolios are static — a list of things you made. A build log turns it into a story with context around each decision. Easier to connect with than a grid of screenshots.
Verified MRR via Stripe is the one that changes the conversation though. Self-reported numbers are noise. Cryptographically verified means you can actually trust what you're looking at, which is rare on any platform.
"A story with context around each decision" is the best description of Build Log I've heard from anyone outside the product. That's exactly it. A grid of projects tells you what someone built. A timeline tells you who they are as a builder.
Verified MRR is the one I'm most excited about long term for exactly the reason you said. Self reported numbers are so common that nobody trusts them anymore. When the number comes directly from Stripe there's nothing to question. It just is what it is.
Rare on any platform is the key phrase. That gap is exactly why it exists on IndieDeck. 🙏
Love this approach — building based on real feedback is underrated.
Which feature had the biggest impact so far?
Honestly Build Log is showing the most engagement so far. People are actually creating entries and the comment section is getting real conversations which is exactly what it was designed for.
But I think Verified MRR will have the biggest long term impact. It changes the nature of what IndieDeck is. A page that shows verified revenue from Stripe is a fundamentally different thing than a link in bio. That positioning shift takes time to compound but when it does it will be the reason people choose IndieDeck over anything else.
Ask me again in 3 months and the answer might be different. 🙏
Love how you shipped features straight from community feedback! Build Log and Verified MRR are 🔥 - really shows the power of listening vs building in isolation.
Thank you! That's exactly the lesson that took me longest to internalize. The temptation is always to build what feels interesting internally. Building what people actually tell you they need is harder because it requires letting go of your own assumptions.
The community here specifically has been incredible for that. 25+ comments on the last post and almost every single one pointed at something real. Hard to ignore signals that clear.
That’s such a hard shift to make.
Letting go of your own assumptions is probably the most underrated skill in building.
When the signal is that clear, it almost feels like the product starts building itself.
Yeah exactly.
When the signal is that clear, it stops feeling like guessing and more like just following what’s already there.
Still hard to let go of your own ideas though, that part never gets easy.
Love seeing this in action. The verified MRR feature is smart - it solves the trust problem in one move. Founders flex revenue all the time; cryptographic proof is a differentiator nobody else has.
Curious: before you built those 3 features, did you validate with actual commitments or just "sounds cool" reactions? The gap between those two is where most shipping energy gets wasted.
"Sounds cool" reactions and actual commitments are very different signals and you're right that most builders can't tell them apart.
Honest answer: Build Log and GitHub Stars came from 25+ comments across my last post here. Not one or two people saying "that would be nice" but the same request showing up repeatedly in different ways from different builders. That kind of repetition is as close to a commitment signal as you get without charging upfront.
Verified MRR was different. Nobody asked for it directly. The community asked for credibility signals and proof of traction. I took that insight and went one level deeper as a founder. Connecting directly to Stripe so the number is verified not typed felt like the right answer to the underlying problem they were describing.
So two features came from the community, one came from listening to the community and then going further than what they said. Both approaches worked but they required different kinds of judgment. Started Saturday morning and shipped all three by Sunday night. Roughly 36 hours from zero to live.
The build log idea is really interesting. I'm building a training load tracker for triathletes and I've been going back and forth on how to show progress publicly — your approach of baking it directly into the product page is smart. It makes the journey part of the product itself. How long did it take you to ship all three features in one weekend?
Really glad the Build Log framing resonated. Baking the journey into the page itself was the whole point, progress shouldn't live on a random Twitter thread that disappears in 24 hours.
On the timeline, started Saturday morning and shipped all three by Sunday night. Roughly 36 hours from zero to live. The speed came from having a clear spec before touching any code. Every feature was already defined by community feedback so there was no guessing about what to build, just executing.
Your triathlon tracker sounds like a great use case for Build Log actually. Athletes and coaches care deeply about progress over time. That kind of public accountability layer could be really compelling for your audience.
The verified MRR feature is a smart move. So many founders inflate numbers or keep them vague, and having Stripe connected proof right on the page removes all the guessing. That alone makes IndieDeck different from every other link in bio tool out there.
Build log is cool too. I'm building a monitoring/testing tool right now and I keep thinking about how to show progress publicly without it feeling forced. Having it baked into the product page itself is way better than random Twitter threads that disappear after a day.
Question: are you thinking about adding any kind of analytics to the build log? Like letting founders see which updates get the most engagement? That could be really useful for figuring out what resonates with your audience.
"Removes all the guessing" is exactly the point. Everyone knows self reported numbers are unreliable. Stripe connected proof changes that completely.
On your monitoring tool, the Build Log problem you described is real. Twitter threads disappear, Notion updates feel like homework, and posting everywhere manually is exhausting. Having the timeline baked into your product page means it compounds over time instead of getting buried in a feed. Worth trying even early stage.
On Build Log analytics, yes, this is already on the roadmap and honestly your framing of it made it clearer. Knowing which update got the most upvotes, which entry drove the most comments, which milestone brought new subscribers to your page, that's incredibly useful signal for a maker. It tells you what your audience actually cares about vs what you think they care about.
Right now the public side shows upvotes and comments per entry. The next step is surfacing that data inside the dashboard so the maker can see patterns over time not just raw counts.
Appreciate the question, it pushed the thinking forward. 🙏
Interesting
Thanks man !
Super impressive — especially Build Log + Verified MRR. This really turns it into a credibility layer, not just a link page.
Love how you built directly from feedback. Curious to see how far this goes
Really appreciate that, "credibility layer" is exactly the direction we're heading.
The feedback loop has been the best product decision I've made so far. Every feature that shipped came from a real conversation not a guess. Going to keep that cycle going as long as it keeps producing results.
Stay tuned still a lot more to ship.
thats honestly nice i might check our the platform
Sure, do check out indiedeck.page
this is exactly the approach i wish i took. building based on what people actually tell you they need instead of guessing.
i went the opposite direction — built 4 python API tools (seo audits, tech detection, speed checking) without talking to a single potential user first. the tools work well but i had zero signal on whether anyone wanted them. 6 weeks of building, $0 revenue.
how are you collecting that community feedback? just from IH comments or do you have other channels set up?
Six weeks and $0 is a painful place to be but honestly the tools you described sound like they solve real problems, SEO audits and speed checking aren't niche ideas. The issue is probably not the product, it's that nobody knows it exists yet.
On how I collect feedback, IndieHackers has been the main channel honestly. The comments on my launch post gave me more useful signal in one week than months of thinking alone would have. Reddit helps too, r/SideProject and r/webdev specifically. Twitter for smaller real time reactions.
The thing that made the difference wasn't the channel though. It was asking for feedback instead of users. When you say "roast this, tell me what's missing" instead of "please sign up", people actually respond. Nobody wants to be sold to. Everyone wants to feel like their opinion shaped something.
For your Python tools, I'd post them honestly on IndieHackers right now. Not as a launch, just as "I built these, do people actually want them." The answer will come fast.
This is solid. Turning a static page into something that actually shows proof and progress is a big shift. Also feels like there’s a lot to manage now with updates, feedback, and user flow. I help founders stay on top of that kind of day-to-day so they can keep shipping consistently.
Really appreciate that framing, proof and progress is exactly what we're going for.
Still managing everything solo for now but appreciate you sharing. The build in public loop keeps things honest, shipping, listening, iterating. That rhythm has been working well so far.
the feedback → ship cycle you described is the right way to do it, but the verification layer is what makes it genuinely different. anyone can claim traction, but connecting directly to Stripe means the number has to be earned not just typed. curious whether you plan to support other payment processors beyond Stripe or keep it focused there for now
That's exactly the thinking behind it. Self reported numbers are easy to fake and everyone knows it. Pulling directly from Stripe removes that entirely, the number is what it is.
On other payment processors, yes, planning to expand beyond Stripe. Lemon Squeezy and Polar are next on the list since they're the most common in the indie maker community. Razorpay for Indian makers, Paddle and Dodo Payments after that.
Stripe ships first because it covers the majority of the audience. But the goal is to support whatever gateway a maker is using so the verified badge is accessible to everyone not just Stripe users. 🙏
the build log feature is a smart move. turning a static page into something people can follow over time is underrated — most builder profiles are just a snapshot. the verified MRR via Stripe is the kind of trust signal that actually matters. curious what the most requested feature was that you decided NOT to build?
Really appreciate that framing, "something people can follow over time" is exactly what we were going for with Build Log.
On features we decided not to build, the most requested one we passed on was GitHub integration for auto syncing project details. A lot of people wanted IndieDeck to automatically pull repo names, descriptions and status from GitHub activity. We passed on it for now because GitHub activity doesn't always reflect product reality. A repo can be completely dormant while the product is live and growing. Or super active commits on something that's still private and not ready to share. The status badge on each project card needs to be a conscious human decision not an automated signal. That context matters.
The other one was a public maker directory, an indiedeck.page/makers page listing all active users. Good idea in theory but it's a feature that benefits discovery over depth. We'd rather make individual pages more valuable before building a directory on top of them.
Both are still on the radar. Just not the right time. 🙏
Very interesting, I will consider creating a profile. Is there a way to find/see profiles already on the site? Leaderboard? New entries? Most active? Recently updated? etc
If there is, I couldn't find it, and it means it needs to be somewhere more prominent.
Not yet, it’s still just profile pages right now. But this is exactly on my roadmap next. Things like recently updated, most active, maybe even a simple leaderboard based on build logs or activity.
And yeah, if you had to ask, that’s on me. Discoverability needs to be way more obvious.
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?
Build Log and GitHub Stars came directly from the most requested feedback. Almost every builder who commented wanted a way to document their journey and show credibility signals on their projects.
Verified MRR was my own call as a founder. The community asked for proof of traction, user counts, metrics, something that shows a project is alive and earning. I took that signal and built something more specific, connecting directly to Stripe so the number is verified, not self reported.
That's the part I'm most proud of honestly. No other link-in-bio tool has it. 🙏
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.
Exactly this. That was the thinking behind it.
Most pages are self-reported, so adding things like GitHub stars brings in external proof without the user needing to say anything. It just makes the page feel more real instantly.
Also agree on the demo point, showing > telling always wins. That’s the direction I want to push IndieDeck more towards.
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?
Good point, they serve slightly different intents.
Early signal so far, verified metrics get immediate attention and trust, people notice it right away. Build log drives more depth, people spend more time exploring and understanding the journey.
If I had to pick, metrics pull people in, build log keeps them there.
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.
Appreciate this, the “proof over claims” framing is exactly what I’m leaning into.
That’s also why I’m excited about verified MRR, feels like a simple way to add real credibility without users having to say anything. And yeah, those learnings came directly from feedback, a lot of what I shipped wasn’t what I originally planned.
The build log part especially feels like it has compounding value over time, still early but curious to see how it evolves with more real usage.
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?
Appreciate this, especially the “living artifact” point, that’s exactly what I’m aiming for.
On the public vs authentic side, I haven’t added heavy friction yet. Right now it’s pretty open because I want people to actually use it without overthinking. But yeah, gaming is something I’m keeping in mind. I’d rather rely more on signals like consistency over time and real activity instead of just raw upvotes.
Still early here, trying to find the balance without killing the simplicity.
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!
Appreciate it man.
Yeah that’s been the whole approach so far, just listen, ship, and see what actually sticks instead of guessing.
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!
Appreciate that, glad the direction makes sense.
Yeah the whole idea is to move from claims to actual proof, feels like that’s what people really care about.
Still early on the verified MRR side but I think it can become a strong differentiator !
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
That’s exactly the problem I was trying to solve, making it feel alive instead of a static page.
Interesting point about the transparency loop bringing more feedback than launch posts, I’m starting to see the same thing. When people can see progress, they engage more.
And yeah, that cycle is real. Still learning to not take feedback personally and just treat it as signal.
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.
It’s less about showing “what I built” and more about proving it’s actually alive and moving. That trust layer feels way more important than just listing projects.
And yeah, that feedback loop is what’s shaping IndieDeck too. Trying to keep shipping fast but only keep what people actually use.
Glad the “living builder story” angle resonated. Stay tuned, I'll keep updating. And don't forget to make your page on IndieDeck, your projects deserves a better home!
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.
Yeah that’s exactly the shift I’m trying to make. Early on it was more about organizing links, but now it’s becoming more about showing proof and context so people don’t have to guess.
From what I’m seeing so far, more people react to the visible stuff like project status because it’s immediate. Verified MRR is still early but feels like it could change how people trust what they’re seeing.
Still watching how both play out with real usage, not just reactions.
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.
Yeah this is something I’m still figuring out honestly. Right now I treat feedback as direction, not decision. If multiple people mention the same thing, I consider it. But I only double down if I see people actually using it after shipping.
For example, status badges got mentioned a few times and now almost everyone uses them, so that stuck. But some other ideas sound good in comments only. At last, as a founder I make the final call.
Not super heavy on analytics yet, but I’m starting to look at basic usage like what people add, what they ignore, and what they keep updating.
Trying to stay close to “does this help someone show their work better in one link” and cut anything that doesn’t move that forward.
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?
Appreciate this, especially the credibility angle, that’s exactly why I shipped Verified MRR for.
And yeah you’re right on the validation vs distribution take. It was more like building in public and letting feedback shape things in real time, not pushing distribution first.
Right now most discovery is still coming from Indie Hackers, Reddit, Twitter and launchpads. After the launch spike it’s slower but more consistent, mostly people finding it through discussions and checking it out.
Still early though, figuring out how to make it more repeatable beyond launches.
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.
That’s a fair point. I was definitely shipping based on feedback early on, so I started tracking what people actually use instead of what they say.
So far, the biggest usage is around the core page itself, people setting up their projects and sharing it. Status badges are getting used a lot too since it helps show what’s active vs dead.
The more “extra” stuff like subscriber capture are still early, some people use it, but it’s not the main reason they sign up right now.
Trying to keep it focused around “one link that clearly shows what you’ve built” and only double down on things that actually get used.
How are you verifying MRR exactly? Stripe API or something custom?
Yes, directly through the Stripe API. User connects their Stripe account by pasting their API key in their project settings. IndieDeck pulls all active subscriptions and calculates real MRR on the backend. The number shown on the public page is pulled live from Stripe, not self reported.
More payment gateways coming soon, stay tuned 🎯
We are looking for someone who can lend our holding company 300,000 US dollars.
We are looking for an investor who can lend our holding company 300,000 US dollars.
We are looking for an investor who can invest 300,000 US dollars in our holding company.
With the 300,000 US dollars you will lend to our holding company, we will develop a multi-functional device that can both heat and cool, also has a cooking function, and provides more efficient cooling and heating than an air conditioner.
With your investment of 300,000 US dollars in our holding company, we will produce a multi-functional device that will attract a great deal of interest from people.
With the device we're developing, people will be able to heat or cool their rooms more effectively, and thanks to its built-in stove feature, they'll be able to cook whatever they want right where they're sitting.
People generally prefer multi-functional devices. The device we will produce will have 3 functions, which will encourage people to buy even more.
The device we will produce will be able to easily heat and cool an area of 45 square meters, and its hob will be able to cook at temperatures up to 900 degrees Celsius.
If you invest in this project, you will also greatly profit.
Additionally, the device we will be making will also have a remote control feature. Thanks to remote control, customers who purchase the device will be able to turn it on and off remotely via the mobile application.
Thanks to the wireless feature of our device, people can turn it on and heat or cool their rooms whenever they want, even when they are not at home.
How will we manufacture the device?
We will have the device manufactured by electronics companies in India, thus reducing labor costs to zero and producing the device more cheaply.
Today, India is a technologically advanced country, and since they produce both inexpensive and robust technological products, we will manufacture in India.
So how will we market our product?
We will produce 2000 units of our product. The production cost, warehousing costs, and taxes for 2000 units will amount to 240,000 US dollars.
We will use the remaining 60,000 US dollars for marketing. By marketing, we will reach a larger audience, which means more sales.
We will sell each of the devices we produce for 3100 US dollars. Because our product is long-lasting and more multifunctional than an air conditioner, people will easily buy it.
Since 2000 units is a small initial quantity, they will all be sold easily. From these 2000 units, we will have earned a total of 6,200,000 US dollars.
By selling our product to electronics retailers and advertising on social media platforms in many countries such as Facebook, Instagram, and YouTube, we will increase our audience. An increased audience means more sales.
Our device will take 2 months to produce, and in those 2 months we will have sold 2000 units. On average, we will have earned 6,200,000 US dollars within 5 months.
So what will your earnings be?
You will lend our holding company 300,000 US dollars and you will receive your money back as 950,000 US dollars on November 27, 2026.
You will invest 300,000 US dollars in our holding company, and on November 27, 2026, I will return your money to you as 950,000 US dollars.
You will receive your money back as 950,000 US dollars on November 27, 2026.
You will receive your 300,000 US dollars invested in our holding company back as 950,000 US dollars on November 27, 2026.
We will refund your money on 27/11/2026.
To learn how you can lend USD 300,000 to our holding company and to receive detailed information, please contact me by sending a message to my Telegram username or Signal contact number listed below. I will be happy to provide you with full details.
To learn how you can invest 300,000 US dollars in our holding, and to get detailed information, please send a message to my Telegram username or Signal contact number below. I will provide you with detailed information.
To get detailed information, please send a message to my Telegram username or Signal username below.
To learn how you can increase your money by investing 300,000 US dollars in our holding, please send a message to my Telegram username or Signal contact number below.
Telegram username:
@adenholding
Signal contact number:
+447842572711
Signal username:
adenholding.88