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.
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! 🤠
The Verified MRR feature is genuinely smart positioning. Most founders either lie about numbers (hurts trust) or say nothing (leaves visitors guessing). A cryptographically verified badge removes that ambiguity entirely. That alone differentiates IndieDeck from every other "build in public" tool.
The thing I keep seeing with building in public: the founders who do it well treat their audience as co-builders, not just spectators. Your approach — shipping features directly from IH comments — is the right loop. Community becomes invested in the product's success because they literally shaped it.
One thing to consider for the Build Log: make it easy to embed or share individual entries. A milestone update with a direct link people can share on X/Twitter could be a consistent distribution channel. Each log entry becomes its own content piece.
Appreciate this, especially the framing around co-builders, that’s exactly how it’s starting to feel.
And yeah, the build log sharing idea makes a lot of sense. If each entry can stand on its own and be shared, it turns into a distribution channel instead of just a timeline.
Definitely something I’ll explore, thanks man 🤠
The Verified MRR via Stripe is the killer feature here. The trust problem on indie builder profiles is real — anyone can claim $10k MRR. Cryptographic verification turns your profile from a marketing page into a credibility signal.
One thing I'd watch out for: the Build Log could become noise if there's no curation layer. The most valuable builder stories aren't linear — they're about the pivots, the features you killed, the metrics that surprised you. Consider letting builders pin the 3-5 entries that actually mattered vs showing everything chronologically.
Distribution > Validation is the right lesson. Most indie hackers spend months building before anyone sees it. You flipped it — community feedback shaped the roadmap before you wrote the code. That's the model that compounds.
Appreciate this, especially the point on build log.
That’s a good call, right now it’s fully chronological, but I can see how it can turn into noise over time. Letting people highlight or pin the important updates makes sense.
And yeah, the shift was exactly that, letting feedback shape what gets built instead of building first and hoping it lands.
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. 🙏
The tension you named between tool and signal layer for investors and hirers is actually your whole business model question. If this stays a tool for builders, you are competing on features with every link-in-bio product and the IH audience is famously hard to monetize. But if the verified MRR and build log actually becomes a signal layer that investors or recruiters care about, the buyer shifts completely and so does willingness to pay.
Who is actually looking at IndieDecks right now? If it is mostly other builders returning the favor, that is community, not distribution. The thing that would tell me this has a real business inside it is if you have any data on who is viewing these profiles, specifically whether any of them are people with money to deploy or positions to fill.
Even I realized that " the IH audience is famously hard to monetize."
I decided to reposition it, so now IndieDeck is repositioning from "indie makers" to "solopreneurs and founders". would love your thoughts on this
wow!
very interesting
haha thanks
You already have proof features, now squeeze paid signal from this exact thread:
That gives you willingness-to-pay data faster than another build sprint.
If helpful, I can do a quick teardown and rank the top 3 conversion leaks on your page:
https://roastmysite.io/go.php?src=ih_indiedeck_dm_offer_20260330_1624
One fast way to turn this momentum into paid users:
You’ll get willingness-to-pay signal faster than shipping another feature.
If useful, I can do a quick teardown and rank the top 3 leaks on your page:
https://roastmysite.io/go.php?src=ih_indiedeck_paidclose_20260330_1321
Shipping based on community feedback is underrated. So many founders build what they think users want instead of what users actually ask for. The fact that you did 3 features in one weekend shows you are listening and moving fast. One thing I have learned from doing marketing for a bootstrapped product is that the features people request are also the exact things to highlight in your messaging. If users keep asking for X, it means other potential users are also looking for X. Your changelog becomes your best marketing copy.
Love how fast you’re running build→feedback→ship.
If your next goal is paid users (not just engagement), I’d test one tight monetization sprint:
That gives you pricing signal + social proof faster than adding another feature.
If useful, I can do a fast teardown of your current page and prioritize the top 3 leaks: https://roastmysite.io/go.php?src=ih_indiedeck_paidsprint_20260330_1020
Nice execution loop. If you want faster paid signal from this momentum, run a 48h concierge offer to 5 builders who commented:
You’ll learn willingness-to-pay + repeat intent faster than feature votes.
If useful, I can do a quick teardown of your page and point out top 3 conversion leaks: https://roastmysite.io/go.php?src=ih_indiedeck_paidsignal_20260330_0122
stop spamming dude
the verified MRR via stripe is a smart move — so much of what i see on builder profiles is "claimed" revenue with no verification. i've been building my outreach tool completely in public (posting actual numbers here on IH) and the transparency is what gets people to engage. 290 pitches sent, 3 replies, 0 customers — ugly numbers but real ones. people respect that more than "$10k MRR" with no proof. the build log feature is something i'd actually use too — right now i'm just posting updates as IH threads which gets messy after 20+ posts.
taking notes here. thank you for sharing your process
haha, sure and follow me on twitter for more https://x.com/vipul20_
sure man!
this is what i wish more builders did. most people launch, get feedback, then go back to building what they originally planned anyway. actually shipping what users ask for within a weekend is how you build something people stick with. i've been doing something similar with my outreach tool — the version that works now looks nothing like what i started with because i kept adjusting based on what agencies actually responded to. how do you prioritize which feedback to act on first when you get a lot at once?
that's exactly it, most feedback gets acknowledged and then ignored. the way I filter it: if 5+ different people say the same thing independently, it jumps to the top, in my case i got 25+ different people were talking about the same issue. one person asking for something could be a niche need, but when it repeats it's a pattern. also what's quick to ship vs what needs deep work matters a lot, quick wins keep momentum going while you figure out the bigger stuff. what's the outreach tool? sounds interesting.
The "distribution > validation" point is the one that took me the longest to internalize. I spent months building features for my macOS app before I realized nobody cared about features — they cared about whether the thing existed in the right place at the right time.
Verified MRR is the real differentiator here. The indie space has a massive credibility problem — everyone claims revenue, nobody proves it. Making verification the default instead of the exception is a strong product decision, not just a feature.
One thing I'd push on: the Build Log is powerful but only if you solve the "empty state" problem. A blank timeline is worse than no timeline. Have you thought about auto-generating the first few entries from existing project data (launch date, first commit, etc.) so nobody starts from zero?
the empty state point is real and honestly something I'm actively thinking about. auto-generating the first entry from launch date or basic project info is a smart way to solve it, nobody wants to stare at a blank timeline on day one. going to look into this.
and yeah, verified MRR came from exactly the credibility problem you're describing. everyone's seen "making $X/month" with zero proof. wanted to make honesty the default rather than the exception.
community feedback is underrated as a product development tool. way better than guessing what people want.
i've been getting similar signals from agency owners i've been pitching — they don't want fancy dashboards or AI buzzwords. they want "can you just get my clients more leads?" so that's exactly what i built. stripped everything else out.
the hardest part isn't building the features. it's resisting the urge to build features nobody asked for. sounds like you've figured that out already.
what's your process for collecting feedback? just reading comments or do you have a more structured system?
mostly reading comments and DMs right now, which is scrappy but works at this stage, the signal is loud enough when you're small. the pattern I watch for is the same request showing up from different people independently, that's when it becomes real. one person asking is a maybe, three strangers asking is a roadmap item.
no fancy system yet. probably Notion when it gets noisy enough to need one.
stripping out everything that wasn't "get my clients more leads" is hard to do, most people can't resist the urge to add. what made you finally cut the extra stuff?
Love the direction here. Turning a static “link in bio” into proof of work is a strong positioning shift.
The Build Log idea especially stands out. Most builder pages show outcomes, but not the journey. A timeline with launches, pivots, and milestones makes the page feel alive and gives visitors a reason to come back.
The Verified MRR and GitHub stars sync are also smart signals. Builders care a lot about credibility, and showing numbers that are actually verified removes the usual skepticism around “internet MRR.”
One thing that could make this even stronger is leaning harder into progress as a product. For example:
automatic streaks for shipping updates
weekly progress summaries
“recent momentum” signals on profiles
"proof of work" is exactly the framing I've been using internally, glad it's coming through in the product. the build log being a reason to come back is the whole bet, not just a static page you set up once.
the streak idea is interesting, there's something in the habit loop of posting updates regularly that could drive retention on its own. weekly progress summaries and momentum signals are both on my radar now.
what would make you actually post updates consistently, is it the streak pressure, or more about having an audience that responds?
The verified MRR thing is smart. One of the biggest problems selling dev tools is that nobody trusts your numbers. I've been cold emailing businesses with free SEO audits and the conversion problem is basically "why should I trust this random person on the internet?"
If I could show verified revenue or verified audit results on a portfolio page instead of just saying "I've scanned 800+ sites" it would probably convert way better. Right now it's just my word against their skepticism.
How are you handling the verification technically? Is it pulling directly from Stripe or do users self-report and you verify?
the trust problem you're describing is exactly why verified MRR exists, "just trust me" doesn't work anymore, especially for cold outreach. verified audit results on a portfolio page is actually a really interesting use case I hadn't thought about.
on the technical side, right now users connect their Stripe account and we pull the MRR directly, so it's not self-reported. no manual entry, no screenshots. the number comes straight from the source.
the "800+ sites scanned" framing could hit way harder if there was even one verifiable signal attached to it. have you thought about showing a live sample audit result publicly instead of just the count? it might work, try it.
Really like how opinionated these updates are. You didn’t just add “more blocks,” you shipped things that turn a portfolio into a proof page: live build log, real GitHub stars, cryptographically verified MRR. That’s catnip for Indie Hackers because it hits the two things everyone here cares about most: showing the work and showing the numbers, without any manual faff or faking it.
"proof page" is a better way to say it than I've been saying it, stealing that. and yeah, the manual faff is the enemy. nobody's updating a portfolio page every week unless it's automatic. the live pulls from GitHub and Stripe exist precisely so the page stays honest without any effort.
Smart approach with the live pull — showing current state is the honest default. The trends over time idea is the right next step.
From building API infrastructure that handles real-time payment data: a 30-day rolling average with a simple trend indicator (up/down/flat) would be hard to game without sustaining actual paid subscriptions for a month+. That's expensive enough to deter most fakers while still being transparent.
The other angle worth considering: showing MRR velocity (how fast it changed) alongside the raw number. A founder with $2K MRR growing 20% month-over-month tells a very different story than one with $5K MRR that's been flat. Growth trajectory is harder to fake than a single number.
Either way, the fact that gaming requires maintaining real Stripe subscriptions is already a strong enough filter for this stage. Nice work.
the 30-day rolling average framing is smart, requiring sustained real subscriptions to game it is a much stronger filter than a point-in-time snapshot. and the MRR velocity angle is something I want to build eventually. $2K growing 20% MoM is genuinely more interesting than $5K flat, and right now the page can't show that story.
appreciate the infra perspective on this, most feedback is product-level, not "here's how the numbers would actually work." useful.
The verified MRR badge is the most interesting piece here from a positioning standpoint. It solves a genuine market problem: founder credibility in build-in-public spaces is almost entirely self-reported, which makes the signal noisy and easy to game. A Stripe-verified number changes that — it's the difference between a testimonial and an audit.
Worth thinking about: the trust signal compounds differently depending on where founders are in their journey. For early-stage builders, "verified £800/month" is actually more powerful than a claimed £8K/month, because it shows accountability rather than aspiration. That shift — from "look at these numbers" to "here's the auditable truth" — is probably the most defensible moat you have over anyone who tries to copy the format.
One thing I'd watch: how founders with revenue in decline behave on the platform. The Build Log will naturally attract growth stories, but some of the most useful signal for the IH community is "here's what we learned when it stopped working." Is there any mechanism to make that kind of transparency feel safe to share?
The verified MRR badge changes the game because it replaces self-reported claims with something real. Most founders share numbers, but no one knows what’s true. Verification fixes that.
What’s interesting is that smaller verified revenue is actually more powerful than bigger unverified numbers. £800 verified builds more trust than £8K claimed.
It also shifts focus from storytelling to execution. Instead of “look what I did,” it becomes “this is what’s actually working.”
One thing to watch: people usually share growth, not decline. But failure data is just as valuable. If there’s a way to make founders comfortable sharing when things go down, the platform becomes way more useful.
Love this! "Listening beats building" — exactly why I built a public feedback tool last week. Tried your IndieDeck format for validation.
Top metrics you track?
Most common things asked for , repeated requests.
Also as a founder dont blind add anything to your product, see if it actually has a long term potential and credibility
This is the kind of build-in-public loop that actually works. Shipping based on what real users ask for instead of guessing is something most founders (myself included) take way too long to internalize.
I'm building a content site and I've been guilty of building features I thought were clever, only to find out nobody cared. The moment I started paying attention to what users were actually struggling with in forums and support threads, everything changed. The features that get used are almost never the ones I would have prioritized on my own.
The build log + verified MRR concept is smart — it solves the credibility problem that most "link in bio" pages have. How are you deciding which feedback to act on vs. which to table? With 3 features in a weekend, it seems like you have a good filter for signal vs. noise.
Appreciate this, and yeah, most of us learn that lesson the hard way.
On filtering feedback, I keep it pretty simple:
The 3 features weren’t random — they all mapped to trust + visibility, which is basically the core loop of the product.
I try to ignore how “interesting” something sounds and focus on whether it actually changes user behavior. That’s usually where the real signal is.
This also work as a journaling system for indie making, and it keeps you motivated when building projects. Great work!
Exaclty, also inspires other to join the joureney !
The shift from a standard 'link-in-bio' to a 'public execution ledger' is a massive positioning win. Most portfolios feel like static graveyards of past work, but adding the Build Log makes the project feel alive. The combination of narrative (Build Log) and objective proof (Verified MRR) creates a level of trust that’s usually missing in the indie space. It’s a smart way to turn a simple tool into a genuine identity layer for builders.
Appreciate this, you captured exactly what I was going for.
Most “link-in-bio” pages end up as static snapshots. The goal here was to make it feel alive, something that reflects what you’re actually doing, not just what you’ve done.
The combo of Build Log + verified MRR is really the core: narrative gives context, verification gives it weight. One without the other feels incomplete.
Still early, but if it starts becoming a default “identity layer” for builders, that’s the direction I’d want to push it.
Curious what your process looks like for collecting feedback - do you have a structured way or just DMs and comments? Asking because I'm early stage and trying to figure out the best way to not build the wrong thing.
Mostly unstructured right now. It’s mainly coming from comments, DMs, and conversations across Indie Hackers, Reddit, and Twitter. I just keep track of patterns, if the same thing comes up repeatedly, I treat it as a signal.
Not using any formal system yet, just staying close to where people are talking and picking up what actually matters.
Like For me it was mostly about signals, not just ideas. I looked at what kept coming up again and again in feedback. Things like build log and GitHub stars came from 20+ people pointing to the same problem around clarity and credibility.
Then I asked one simple thing, does this make it easier for someone to understand what I’ve built or trust it more. If yes, I shipped it.
As a founder, Verified MRR was something I added myself to push that further.
Everything else I either delayed or ignored if it didn’t move that forward.
This comment was deleted 7 days ago.
This is inspiring.
I’m also building a product and trying to improve it from feedback.
How did you decide which feature to ship first?
Appreciate it.
For me it was mostly about signals, not just ideas. I looked at what kept coming up again and again in feedback. Things like build log and GitHub stars came from 20+ people pointing to the same problem around clarity and credibility.
Then I asked one simple thing, does this make it easier for someone to understand what I’ve built or trust it more. If yes, I shipped it.
Verified MRR was something I added myself to push that further, as a founder.
Everything else I either delayed or ignored if it didn’t move that forward.
Love how each feature came directly from comments on your last post — that's build-in-public working exactly as it should. The verified MRR angle is clever; credibility is genuinely underrated as a growth mechanic for early-stage products.
I've had a similar experience with my indie app: features I thought were obvious in isolation often missed the mark completely, while the ones users awkwardly asked for almost always moved retention.
One thing I'm curious about — did you prioritize all three features equally, or did one feel clearly more important based on the feedback volume? Would love to know which one surprised you most once users got their hands on it.
Appreciate this.
They weren’t equal. Build log and GitHub stars came from a lot of repeated feedback, literally 25+ comments. So those were clearer to prioritize.
As a founder, Verified MRR was something I added myself to push the credibility angle further.
What surprised me most is how strongly people reacted to verified MRR. It changes perception instantly, even before they explore the rest.
The verified MRR angle is what makes this interesting. Every indie builder page on the internet shows "making $X/mo" with no proof. You're right that flipping it from a portfolio to a proof document is a positioning shift, not a feature addition.
The Distribution > Validation lesson hits hard too. Most founders treat community posts as vanity. You're treating them as a research channel. Every comment is a prioritization signal. That's a different operating mode entirely.
Curious what feedback you got that you decided NOT to build. The things you said no to tell you as much about the product as the things you shipped.
Appreciate this.
Yeah saying no has been just as important. A lot of people asked for heavy customization, themes, layouts, making it more like a personal site. I didn’t build that. It felt like it would turn into another generic link page and move away from the core idea.
Trying to stay focused on clarity and proof, not flexibility for the sake of i
This is the kind of iteration loop that actually builds products people love. The "shipped a feature nobody asked for" trap is real, and what you are describing — going back to user feedback before building — is rare discipline.
One thing I have seen work really well alongside this: tracking what users do vs. what they say. Sometimes the feature request in words is different from the actual friction. Did you find any gaps between what was asked and what the actual behavior was showing?
Congrats on the weekend shipping streak. What is your process for deciding which feedback to act on vs. which to park?
Appreciate it.
Yeah I’ve already seen that a bit. What people say and what they actually do don’t always match. Some things sound important in comments but barely get used after shipping.
That’s why I’ve started paying more attention to usage after release. If something gets used repeatedly, it sticks. If not, I treat it as noise.
For deciding what to act on, for me it was mostly about signals, not just ideas. I looked at what kept coming up again and again in feedback. Things like build log and GitHub stars came from 20+ people pointing to the same problem around clarity and credibility.
Then I asked one simple thing, does this make it easier for someone to understand what I’ve built or trust it more. If yes, I shipped it.
Verified MRR was something I added myself to push that further.
Everything else I either delayed or ignored if it didn’t move that forward.
This is such a good loop to be in. The hardest part about community-driven development is knowing when to say no — sometimes the most requested feature is not actually what moves the needle. What I have found helpful is tracking not just what people ask for, but what they actually do after you ship it. Usage data plus feedback requests together give you the real signal. Three features in a weekend is impressive execution speed.
Appreciate it.
Yeah that’s exactly what I’m starting to focus on now, not just what people ask for but what they actually use after it’s shipped.
That combination gives a much clearer signal than feedback alone.
Shipping based on community feedback over a weekend is the kind of speed that makes indie hacking work. Most founders I talk to in the AI space have the opposite problem — they build in isolation for months, then launch to silence because they never validated with real users first. The fact that you turned community input into shipped features in 48 hours is proof that distribution and feedback loops matter more than perfect code. What's your process for deciding which feedback to act on vs. which to file away?
Appreciate it.
For me it was mostly about signals, not just ideas. I looked at what kept coming up again and again in feedback. Things like build log and GitHub stars came from 20+ people pointing to the same problem around clarity and credibility.
Then I asked one simple thing, does this make it easier for someone to understand what I’ve built or trust it more. If yes, I shipped it.
Verified MRR was something I added myself to push that further. Everything else I either delayed or ignored if it didn’t move that forward.
This is really cool. I like how you turned it from just another profile page into something that actually shows the journey. The build log especially stands out to me. Curious which of these features people are responding to the most so far?
Appreciate it.
So far verified MRR is getting the strongest reaction, it instantly changes how people perceive the page. Build log is more subtle and someone for long term, but the people who use it tend to stick and keep updating. GitHub stars help with credibility, but more as a supporting signal.
Solid grind. Props for the hustle!
Thanks man ! 🤠
This comment was deleted 7 days ago.
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?
That’s a really good point.
Right now it’s just a live pull from Stripe, so it reflects the current state, not a one-time snapshot. If someone inflates it and it drops later, that change will show.
But yeah, short-term spikes vs sustained traction is something I’m thinking about. Might need to show trends over time instead of just a single number so it’s harder to game the perception. Hasn’t come up a lot yet, but definitely something to handle as usage grows.
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.
Appreciate that, makes sense.
Build log translating to client work is interesting too, transparency changes how people trust the process. And yeah, speed matters a lot here. Feedback only works if you actually turn it into something people can see and use.
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.
Appreciate this, that’s exactly what I was trying to do.
The focus was less on adding features and more on fixing friction and making the product feel more trustworthy.
Glad that’s coming through.
Early on, trust and friction reduction usually matter more than stacking on features. When a product feels clear, reliable, and easy to use, people notice—and they remember it. That’s what makes the early foundation so important.
Curious to see what you build next.
So true. yeah, something good coming. stay tuned !
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?
Appreciate it.
Still early to say on retention, but verified MRR is getting the strongest reaction so far, it changes how people perceive the page instantly.
Build log feels more long term. People who use it tend to stick and keep updating.
GitHub stars help with credibility, but more as a supporting signal than the main driver.
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.
exactly — trust is hard to build and easy to lose. especially with ai-powered decisions where people already have skepticism.
good luck with indiedeck. the verified MRR via stripe is the kind of trust signal this space needs.
Thanks man ! 🤠
yeah especially in this space, once trust drops it’s really hard to get it back. that’s why I’m trying to keep things as transparent and grounded as possible instead of over-automating.
glad the verified MRR angle resonates.
for sure. btw just launched ideadose on product hunt today —
the "no sugar-coating" approach in action:
https://www.producthunt.com/posts/ideadose
would love your take on it.
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.
100% - building in isolation almost always leads you in the wrong direction.
Feels like the real advantage now is just how fast you can listen and adapt.
spot on, exactly.
Good luck with the project
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. 🙏
That's really useful to hear, especially the "what your audience actually cares about vs what you think they care about" point. That gap is real and harder to see than you'd expect. Will give Build Log a try this week. The dashboard view sounds like exactly what makes it worth using beyond just the public-facing side.
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.
That makes sense. Keeping that rhythm solo is impressive. If you ever want a hand staying on top of updates, feedback, or user flows without slowing down shipping, I’ve helped founders set up lightweight systems that make it easy to keep the loop going. Happy to share ideas or templates if that’s useful.
sure, why not. share some
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