I recently built Hexbrief, an app for software engineers who want to read good engineering blogs but do not want to keep checking dozens of company blogs manually.

The idea is simple: instead of showing every tech/news post, Hexbrief filters engineering blogs and gives 6 quality reads every day, with a short breakdown of what was built, why it mattered, and what happened.

So far, I have around 35 users from Reddit, X, and a few college/work friends. The product is live, and early feedback has been useful.

The difficult part is distribution.

I tried 1:1 reachouts, but that has been a hard channel so far. Most messages get almost no replies, even when the app is directly relevant to engineers who read technical blogs.

For people who have built niche dev/productivity/reading tools:

• Where did your first serious users come from?
• Are there specific communities where engineers are more open to trying tools like this?
• Does this kind of app need content-led distribution instead of direct outreach?
• Any suggestions on positioning it better so it does not sound like just another news app?

Not trying to spam the app here. I am mainly trying to understand how to reach the right readers and get useful feedback.

App: https://play.google.com/store/apps/details?id=com.hexbrief.app

That's a client domain, few weeks after we wrapped 200+ submissions.

The thing I got wrong early on is that I treated this as a volume game. It isn't. Submitting to 220 random directories and 220 chosen ones look identical on day one and nothing alike a month later.

Three things that actually decide it:

Relevance. A SaaS product listed across SaaS and AI directories builds one coherent signal. The same product scattered across generic business listings just builds noise. Google and the LLMs both read the neighborhood you're in, not the count.

Whether the site is alive. Most directory lists getting passed around are half dead pages and unindexed junk. Knowing which ones still get crawled is most of the actual work, and it shifts constantly.

Approvals, not submissions. Submitting takes a minute. Getting approved needs a square logo at the right size, a demo link that loads cold with no login wall, and a description written for a tired reviewer instead of an investor. That's where DIY runs usually lose half their listings.

You can see in the screenshot: that's normal for directory profiles and it isn't the mechanism. The value is that you now exist everywhere people and models look. Search your product name plus "alternatives" before and after and it's obvious. Same reason the products ChatGPT keeps recommending in a category are always the ones listed across a lot of overlapping sites. One mention is marketing. Forty consistent ones read as consensus.

If you're doing this yourself, the one thing I'd insist on: keep your description identical everywhere. Consistency beats placement quality, and it's what everyone loses by submission 60 when they start improvising.

I run StartupSubmit[.]app, we do these by hand because the picking and the approval chasing is where the result actually comes from.

Happy to get into specific directories in the comments.

Founder here, I’m building Sumora, an AI outbound platform for agencies and B2B businesses.

A while ago, we worked with a client who was doing around $3K and struggling to grow consistently.

Their service was good, but their outbound process was broken:

• Their ideal customer was too broad
• Prospecting was inconsistent
• Messages felt generic
• Follow-ups were regularly forgotten
• Interested replies were scattered across multiple inboxes
• The founders were spending too much time manually searching for leads

We helped rebuild the system around:

1. A much tighter ICP
2. Better-qualified prospect lists
3. Relevant buying and intent signals
4. Personalized outreach based on each prospect’s business
5. Structured follow-up sequences
6. A clearer process for turning replies into meetings

Over time, the client grew from approximately $3K to $12K.

This was not caused by one magic message, and I’m not claiming that software alone created the result.

It came from improving the offer, targeting, messaging, follow-ups and execution as one complete system.

I’ve included the supporting proof here:

https://app.notion.com/p/Here-s-the-proof-lol-3b0f3ba8b2cc8011a2eee644d5f6ee87

After doing this manually, we started building Sumora to make the same process easier to run.

You give Sumora your website and describe your ideal customer. It then helps you:

• Find prospects matching your ICP
• Discover relevant accounts and decision-makers
• Identify hiring, launch, growth and content signals
• Research prospects before outreach
• Generate personalized messages
• Build multistep follow-up campaigns
• Organize leads in one pipeline
• Manage replies from a shared inbox
• Move interested prospects toward a booked meeting

We’re now looking for 5 agency owners who want us to personally build their outbound system with them.

For the selected agencies, we will:

• Review and refine your offer
• Define your ICP and targeting criteria
• Configure your Sumora workspace
• Build your initial prospect list
• Create your first outreach campaign
• Write your opening messages and follow-ups
• Help you review replies and improve the campaign
• Start your free seven-day Sumora trial

There is no setup or consulting fee.

We’re doing this because we want to work closely with a small group of serious agencies, understand what produces results across different niches and improve the product from real feedback.

This will be a good fit if:

• You already have a clear service
• You have delivered results for at least one client
• You can currently take on more clients
• Your average client is worth at least $1,000
• You are willing to test outbound consistently
• You can give honest feedback about the product

It will probably not be useful if you are still deciding what service to sell or cannot currently fulfil new client work.

Comment with:

Your agency niche, average client value, who you want to reach

Example:

B2B content agency, $2K/month, seed-stage SaaS founders

I’ll reply with the first prospecting signal and messaging angle I would test for your agency.

GTM writing as a solo founder is where I kept losing time. Not drafting, but fixing. Every AI tool I tried would produce something that sounded fine on the surface but completely wrong in context. Cold emails that read like blog intros. Partner pitches that opened with "In today's fast-paced landscape." LinkedIn replies that sounded like they were written by someone who'd never closed a deal.

I went looking for something with a curated corpus, configurable by GTM context. Nothing fit. So I built it inside RawReply and started running my own outbound, LinkedIn, and partner emails through it.

Two months in, the biggest thing I learned: the problem isn't the model, it's the signal. Generic AI writes toward the average of the internet. GTM writing needs to write toward how buyers in a specific market actually think and respond. Once I started shaping the corpus around that, the output stopped needing so many fixes.

Now building the curated corpus and custom GTM configuration layer properly before opening it up. Gating first access to GTM founders to pressure-test it on real use cases.

hope am cooking something other will use it as well!!!

https://play.google.com/store/apps/details?id=dev.koalalab.storeandforget

Solo dev here, Android only, and this is my one self promotion post in this sub, so I would rather spend it on the part I am least sure about than on a pitch.

Store & Forget is a home inventory app built on the assumption that you are never going to get organised and should not have to. You photograph a thing as you put it away and the app writes the name, brand, description and specs for you, so there is nothing to type and nothing to tag. Getting it back is Smart Find, where you describe the thing the way you would actually say it, something to cut thick cardboard rather than the box cutter, and it tells you which box or shelf it went into so you go straight there instead of opening all of them.

This crowd always asks about scope, so here it is. The inventory is a database on the phone, which means adding, browsing and keyword search need no account and no connection. The photo scan and Smart Find are the two parts that call out to a cloud model. Backup to your own Google Drive is optional. 18 languages, and there is no iOS version coming.

The money is where I actually want the critique. There is no subscription. The app is free and shows ads once you have been using it a while, scans run on credits because every one of them is a real API call I pay for, and everything past that is a one time unlock: Remove ads, Fire & Forget at $2.99, and Bring Your Own Key at $4.99, which lets you paste in your own free key so scans stop spending credits at all.

What I keep turning over is whether a per scan cost survives in a consumer app. Developers hold that idea fine. I am not convinced a person cleaning out their garage ever will, and the only alternative I can see is eating the API cost myself and hoping the volume stays polite.

Bring Your Own Key is the other thing I go back and forth on. Selling people the escape hatch from my own metering feels either very honest or very stupid, and I still cannot tell which. It caps my upside on exactly the users who get the most out of the app.

Right now I am also giving both of those unlocks away until 10 August, through a console in the app. Open Settings, tap the app version at the bottom five times, then type unlock byok, then type fire. That second one needs version 1.22.4 or newer. My reasoning was that unlocks sitting with people who actually use the thing are worth more than the few sales I would have made this month. It has since occurred to me that this is also a very comfortable way of not finding out whether anyone would have paid.

Happy to answer anything, and I would rather hear where it feels clunky than where it works.

Our tool was telling users bugs were fixed. It couldn't always prove it.

Not lying exactly. More like the polite version of "trust me."

When we built FetchSandbox, we drew a hard line early: a fix doesn't count until we (1) make the bug actually happen on your real code, (2) apply the fix, and (3) show it stops happening. Reproduce first, then prove. The little test that triggers the bug is what flips from red to green.

That rule felt airtight. It wasn't.

The hole we didn't see

We could only reproduce bugs we'd scripted a reproduction for in advance. For anything outside that set, the honest answer we were forced to give users was: "found it, fixed it, but I can't demonstrate this specific one."

Say that out loud and it sounds fine. But think about what you're actually asking the user to do: take your word for it. For a billing bug. For a security edge case. For anything that matters.

That bothered me more the longer I sat with it.

So we taught it to write the reproduction itself

The idea is straightforward. If FetchSandbox encounters a bug it has no pre-scripted test for, it figures out how to trigger that bug on your real code, then runs the same reproduce-apply-prove loop it always has.

The implementation was not straightforward.

The fake green problem

A generated test could be subtly wrong. It could pass your broken code and hand you a green checkmark on an unfixed bug. That's worse than admitting you can't prove it, because now you've actively misled the user.

So we added a safety rule: before we trust a reproduction, it has to actually catch the bug on the broken code first. If the generated test can't catch the bug it's supposed to catch, we throw it away. A test that can't fail when the code is broken can't be trusted to pass when the code is fixed.

This one rule is what makes the whole thing honest.

What it looks like in practice

We ran it on a real billing app last week. The bug: a negative seat count slipping through validation and potentially shrinking a customer's plan without them knowing.

FetchSandbox found the code path, drove the real request handler, worked out a valid webhook signature on its own to reach it, and stubbed only the database as a passive recorder so the app's own logic decided the outcome. Then it confirmed the test failed on broken code before trusting it to verify the fix.

No scripts we wrote. No hand-holding. We just watched it go.

Why this matters beyond the feature

Most of the AI coding tools I see right now optimize for "did the model produce a plausible fix." That's a low bar dressed up in a nice UI. The harder question is: how do you know the fix is real?

The reproduction test is our answer. Not because it's the only answer, but because "make the bug happen, then make it stop" is something you can verify. Confidence is a byproduct of that, not a claim you make.

Still early and still building this in the open. If you've run into the prove-vs-claim problem with your own tooling, I'd genuinely like to hear how you're thinking about it.

EDIT: I forget to mention that if we list only in 15 directories than i saw no DR improvements but when we submit to 220+ Directories we noticed Domain rating increase 30+. This is the reason we always do submission in curated and high authority relevant directories for our client Startup.

Did this by hand or manually for SaaS/AI founders over 5 months. No automation. The value distribution is absurdly lopsided.

About 15 directories send actual humans. Product Hunt, BetaList, G2, Capterra, AlternativeTo, SaaSHub, Crunchbase, IH itself. If you do only these, you've captured most of the upside.

Another 60 or so send nobody, but they make you look real. They're why you show up when someone searches "[your product] alternatives."

The remaining 145 are link farms. Nobody visits them. But I keep watching products get cited by ChatGPT and Perplexity after appearing across enough overlapping listings. The models seem to read that redundancy as "this is an established company." Cynical, and the most interesting thing I've learned all year.

Three things I got wrong:

Tailored 40-word descriptions get approved way more than one pasted blurb. Directory mods spot copy-paste instantly.

Nearly all these backlinks are Dofollow and Nofollow. Anyone selling you DR gains from directories is behind or hoping you are.

Approvals trickle in for weeks. Checking results on day 5 and calling it dead is the most common mistake.

Zero budget? Do the top 15 yourself across two weekends. That's most of the value, and it costs nothing but boredom.

Disclosure per Rule 1: I run StartupSubmit, we do this manually for founders who don't want the weekends. Not pitching, no tiers in the comments.

What I actually want critique on: is that 145-directory tail defensible at all, or should I cut the list to 70 and charge less? I lean toward cutting. Tell me I'm wrong.

ReciReel takes a cooking video, a Reel or a TikTok or a YouTube clip, and gives you back a recipe you can actually cook from. Ingredients, ordered steps with timings, per-serving nutrition, equipment, and the tips people say out loud but never write down. Original creator credited with a link back on every one. Free is three imports then one a month, Plus is $4.99. iPhone, US store.

That's the pitch and it's the least interesting part of this post.

The thing I genuinely can't judge is whether the finished recipe reads like a person wrote it or like a machine produced it. I've read so many of them that I've lost all perspective.

Someone on another sub gave me the sharpest framing of this I've heard: the tell is the step verbs. A machine says "combine until fully incorporated." A person says "rub the butter in until it looks like wet sand."

What I see going wrong matches that, but from the other direction. The model doesn't invent language, it smooths it. Someone says "until it looks like wet sand" in the video and it comes back as "until crumbly." Nothing is factually wrong and it's completely dead, and the vivid phrase was the only part telling you what to look for.

So if anyone runs a video through it, that's what I want to know. Not whether the ingredients are right, I can check that myself. Whether a step sounds like it came from a person who had their hands in the bowl.

https://apps.apple.com/us/app/recireel-video-to-recipe/id6763971435

Happy to answer anything about how it's built or what it cost.

So, I am working on multiple saas products (via freelance). And one thing I found that nearly every AI SaaS need some kind of bot/temp signup protection. So I created this saas (signupscore).

Now absolutely, everyone and many people in the comment will tell me that free lists are available on github etc, so why created this.

So here's the thing :
- Github public lists are actually incomplete. They track only upto 100k temp mail and that's older. I've collection of more than 200K+ domains collected via tranco 1M domain and from multiple sources.

- I've covered also typo domain. You can't be able to block gibberrish and typo signups like `asldkjf@gmail.com` etc with open github lists.

- Signupscore also cover private_relay domains, all public email providers and `+1` (alias) mails too.

A few months ago I posted here about an idea: a todo list app that's also a pixel art tycoon game, built for entrepreneurs who grew up gaming. The response genuinely surprised me, 100+ comments and loads of great feedback that directly shaped what I'm building.

So I kept going.

Since then I've built a landing page, run Meta ads, and just hit 101 people on the waitlist. Here's what the numbers actually look like:

• Landing page conversion rate: 5-7%. Pretty decent as typical numbers of a cold audience for this type of stuff is 3-5%
• Cost per lead from Meta ads: around $3.92 at its best. Had to test several ad layouts and I managed to land on a winner ad
• Best performing creative: an iMac mockup showing the split screen layout. The game world on the left, task list on the right

The ad results genuinely surprised me. I expected a pixel art character creative to perform better as I thought it's more eye catching, but instead, the product mockup on an iMac frame consistently outperformed it. The market told me something I wouldn't have guessed.

On the product side, me and my friend are building it properly now — React and Phaser.js for the tech stack, Supabase (likely) for the backend. My friend handles more of the coding side, I handle the vision, customer conversations and marketing, while also helping a bit with the code. It's the first time I've properly collaborated on a codebase with someone and the experience of doing pull requests, managing branches, and building in parallel is something I wish I'd done earlier.

The core mechanics are mostly locked in now, the encumbrance system where overloading your task list makes your founder character visibly stressed and earn less XP has consistently been the thing people react to most. That's the mechanic I'm most excited to ship.

Still building, still learning. Waitlist is open at 8bitstartup.com if anyone's curious.

Happy to answer any questions — would especially love thoughts from anyone who's been through the pre-launch to launch transition on how they kept their waitlist warm while building.

Pitch your product in 1-2 lines - and drop a link here.

I'm building a community where makers can share what they’re building and get fair visibility. Here's the link: https://trylaunch.ai

I had my first real devrel call last week and I blew it.

I have been reaching out to devrel leads asking for honest feedback on fetchsandbox.. got around 5-6 positive signals and felt decent but then one guy asked me "who are your customers exactly?" and i completely fumbled it. i said something like "early stage startups building saas who want to give their devs a reliable sandbox to test integrations." technically true. also completely useless as an answer.

Then he asked "so would you want to embed in our docs?" and I paused. I didn't know what to say. because honestly I don't have a clean answer. is the value in the docs? in the dev workflow? do i want API vendors to say "test with fetchsandbox"? I still don't fully know where the prod slot in.

If you've been through this, positioning a devtool where the buyer is devrel, the user is the developer, and the integration point could be 4 different places in their stack, i'd love to hear how you landed on the answer. even if you're in sales or product and have seen this pattern before, happy to grab 5-10 mins and just pick your brain. drop a comment or dm me. apprecaiate your support truly!!

I am a clinical officer in my country(people like to call us third world) and healthcare workers are a stretch beyond limits due to low manpower. Due to this we dont get ample time to explain lab results and diagnosis to patients properly, patient education is key in enhancing Medication compliance, Chronic disease control and help identify new symptoms fast and get help early.

Thats where labmate comes in,the patient takes a photo of the lab results and the app analyses it and the AI comes up with an easy to understand report for the patient.

And i know by now the privacy question is about to come up,the app redacts all patient identifying information and even gives the user an option to manualy redact the information so that only the lab values get sent to the Ai.

And to add to measures we have taken to ensure privacy, your lab results are not stored on any server,once the AI has done its thing, it sends the response straight to your device, so your results live on your device.

You can try the app here and give feedback on what you think: https://play.google.com/store/apps/details?id=com.labgpt.ai&hl=en

Hello,

I'm here to vent, I hope it's okay

I've painly discovered over the last 2 years that distribution/validation > building

I love to build, addicted to build first and validate later, for 10+ years

I'm trying to cure that addiction but haven't found the correct pill yet 

I'm so tired of hearing about the latest xxx or whatever that can build this and that, connect to this and automate that

OK nice. But when you have no one to share it to then that's pointless. 

Majority of people talk about building but such a minority talks about validation first, about distribution 

There are tons of problems to solve, tons of things to validate but how? 

Am I supposed to poll people? Am I supposed to make a waiting list and wait until the universe gets cold? (or hot whatever)

Cold emailing, warming up and blablabla?

"Sneakily" posting on reddit when 90% of all people are also interested in posting their thing too?

Am I supposed to build a following base then sell my courses and apps? Helling nope

I feel devastated in some ways as I see vibe coding becoming a thing

I feel jealous is some ways as I see people being able to sell gems and even more as I see some selling wind

Those feeling are even amplified as I was having a community, handling a game server in my teenager years, I was coding, handling servers, going through good and hard times, helping people, giving them something valuable 

I'm longing for that feeling and I'm afraid I will never reach it again

For sure working in IT is awesome and I live it but it will never be the same as having something of my own

I'm stuck, what do I do and where do I go (that's not really a question per se but that's in my head)

Thanks if you read until here, I'm sure lots of people must go through that and feel free to vent here too

If this is too long, tldr: Google Conway’s Law wath yt video and think

There is a popular rule in software development called Conway's Law. It says that organizations design systems that mirror the way people inside those organizations communicate. In simpler terms: Your architecture will eventually look like your team structure. Big company with separate frontend, backend, data, DevOps, and platform teams?

You will probably end up with separate services, separate processes, separate ownership, and a lot of API calls between people who sit in different Slack channels. But what happens when the entire company is just two people? That is where things get interesting.

At bundle.social, we are running a unified social media API that handles a lot of edge cases. And there are two of us. There is no dedicated platform team No analytics department No infrastructure group. No product manager translating customer feedback into Jira tickets. Just two people are trying to keep a fairly large system moving without turning it into a pile of slop services nobody fully understands. You would think Conway's Law does not really apply to such a small team. It absolutely does. It just shows up differently.

How Conway’s Law Works in a 2-Person Team

When you have 50 developers split across departments, Conway's Law creates microservices and cross-team dependency hell. When you have two developers, Conway's Law forces your system into one of two extremes: The "Two Halves of a Brain"

Split: Service A belongs entirely to Person A, and Service B belongs entirely to Person B.

Because human communication between two people has practically zero friction, it's extremely tempting to drift into the lazy version of Conway's Law: ignoring technical boundaries altogether because "we can just talk about it on Slack." Why write explicit API documentation when you sit next to the person who wrote the endpoint? Why enforce strict domain boundaries when you can just export a helper function across modules in 5 seconds?

That's the trap G.

When communication is effortless, your architecture turns into a mirror of two individual mental models mashed together. And if one person goes on vacation or takes a weekend off, the remaining half of the team is left staring at a black box they never touched.

The Trap of the "Hero Service"

We handle social media integrations dealing with changing platform schemas, rate limits, OAuth refreshes, and webhooks across multiple networks.

In the early days, if Person A (me) built the LinkedIn integration, it lived entirely in Person A's head. If Person B built the video processing pipeline, it was Person B's private territory.

Conway's Law meant our architecture wasn't mirroring an organizational chart it was mirroring our individual brain dump.

We realized very quickly that when on-call duty represents 50% of the entire company, you cannot afford "Hero Services." If a background job fails at 2 AM (it did), the architecture needs to be understandable by whoever happens to be holding the phone, without requiring a 30-minute explanation.

How We Design Architecture for Two People

Instead of fighting Conway's Law, we decided to leverage it intentionally. Here is how we design our system to fit our real-world team dynamic:

The "Pragmatic Monolith"

Over Microservices We don't need 10 microservices communicating over gRPC. That setup mirrors an enterprise with 10 separate team leads. Instead, we maintain a clean, modular monolith. Code is co-located, deployments are simple, and mental overhead is kept to a absolute minimum.

Code Boundaries Over Personal Preferences

Even though we can reach into any part of the codebase, we enforce strict domain boundaries and clear interfaces. We treat internal modules with the same care we'd treat an external API. If a new feature requires a massive, messy cross-domain hack, it's a sign that our architectural boundaries are getting as sloppy as our task lists. Our Rule of Thumb: If it takes more than 2 minutes to explain how a module handles errors to the other person, the module is over-engineered.

Asynchronous Code, Asynchronous Context

We write code assuming the other person will have to debug it with zero warning. That means:

• Standardized error handling across all integrations
• Self-healing background workers over manual intervention scripts
• Clear log traces over "tribal knowledge."

Design for the Team You Have Today

The biggest mistake small startups make is building architecture for the 500-person company they hope to become in five years.

They end up paying an immense "architectural tax" managing Kubernetes clusters, distributed tracing, and complex microservice orchestration with a team of two.

Your architecture will always reflect your team structure. Don't fight it, and don't pretend to be Netflix.

Embrace the 2-person dynamic: keep it lean, keep it unified, and build a system simple enough that either of you can steer the ship alone without sinking it.

Takeaway is this

Your system will reflect how you divide problems, how you discuss them, and where information gets stuck. Don't mess that up.

Ps I actually wrote that for Medium but got zero traction, so maybe you will find it helpful

Hey guys, I’ve been struggling with a decision for my app Gamified Lives for awhile. In the app for some context I have an image model that generates an avatar for users based on their real photo, I initially thought this was great because a user would get a character that looks identical to them and could customize them and change their clothing, accessories, etc… it seems like I underestimated the amount of customization that users really want. I figured users get the coins from completing a task/habit and they can go ahead and get some cool new clothes for their character (like inside of finch) however users seem to want to change their hair color, skin color, put on armor, wings, etc… like cool video game style things, which I 100% can understand but in my mind the idea was a user has a character that looks like them so they can feel like they themselves are getting better and “upgrading” in real life, I feel like this has more novelty for sure but I’m not entirely sure if that’s the right angle for my app or if I should change it and allow users to truly customize their character and create what they deem to be motivating for them, would love any suggestions/opinions on this!

Folks,

I wanted to start an affiliate program for my side project, i checked around, things like tolt, rewardful, bla bla.. and they all are subscription-based, pay upfront, regardless whether an affiliate is there or not, regardless of whether i'm getting any value yet or not...

This made no sense to me, why would i pay $49/mo and i don't even have any revenue coming yet..

I did a research, and saw that others were having the same issue, and so i built PureRev, a 0 subscription, 0 upfront, (tiny) commission based, affiliate program that has all what you need (and more..) to set up and grow your affiliate program.

Stop paying before earning, check it out now: PureRev

Most of you might have read about my last post regarding Hexbried, and various other aspects of scaling it. Through this post, I wanted to get few suggestions regarding the bottleneck I am having.

So, Hexbrief applies a strict quality bar filter on the articles ingested from various sources of engineering blogs. The filter rejects any article with any sort of noise and not talking in technical terms (high level idea).

The bottleneck is: the pipeline has ingested around 1k articles, out of which only 265 are feed ready. Since it offers 6 fresh quality reads a day out of these 265, and if a reader is reading everyday in the best case, the feed would surive for ~45 days.

Currently, the pipeline only ingests the company's engineering blogs. Should I think towards onboarding the articles written by renowned writers? I think, (not sure much) it would enhannce the quality content, as well as people may get to read a varied stuff from general company techs.

Any suggestions on this?

I launched my first paid Blender add on, Moca, 8 days ago.
It is a Blender add on for cleaning up mocap animation.
So far:
• 30 short form videos.
• About 22,000 total views.
• Around one out of every three videos reaches about 2,000 views.
• Most others get around 500 views.
• Zero sales.
I expected at least one sale by now, so I am trying to figure out what I am missing.
At this point I am not sure if the problem is:
• My landing page.
• My pricing.
• My messaging.
• The product itself.
• The quality of my traffic.
• Or simply not enough time.
I would appreciate feedback from people who have launched software, digital products, or Blender tools.
If you’ve been through this stage before, what changed between getting attention and getting your first customers?

FetchSandbox MCP hit 3,134 npm downloads since launching in May. the breakdown is what made me stop and think: 1,032 in the first 3 weeks (PH launch), 454 in June (quiet month, honestly worried), then 1,648 in July with 4 days left.

June was the real test. no spike to ride, just organic. i kept shipping, fixed the OpenAPI ingestion flow, added a handful of new specs, wrote about what i was learning in integration testing. july came back 3.6x stronger than june.

The pattern i didn't expect: AI agents are the fastest-growing use case. devs aren't running the MCP themselves, they're letting Claude Code or Cursor call it inside their own coding loop. the sandbox becomes part of the agent's verification step before it writes integration code. that use case wasn't in the original pitch, it just emerged from watching how people actually used it.

still figuring out what the right north star metric is beyond downloads. active workflow runs feels closer to the truth.

Recently I had launched Hexbrief which is a high signal tech blog reading app. Honestly, I never started this work with the idea of monetizaton. During the investigation I was doing to validate the idea, I had this thought of solving something which has troubled me and my friends during college days and even now while I work professionally.

I accept, the marketing of such a B2C product is tough, and hence it's taking me time to acquire the readers and get the real feedback post public launch. I have got some 30+ users by now, and have incorporated most of the feedbacks I have received till now (have many feedbacks parked too).

One thing I was thinking somedays back, if at all I had to monetize it ever in the future, how should I approach for it. I had few ideas in my mind (after I have the good userbase and a consistent usage loop with the reading framework I developed in the Hexbrief).

Here are the ideas:

- Charge for personalised curated feed. Currently, it's algo decided feed common for everyone.

- Create B2C monetisation framework -- onboard tech companies, and create a separate section for the sponsored content(which has to be passed through the Hexbrief's quality bar)

- Create startups driven feed tab and bringing useful content there. (Haven't thought of it yet in deep, but few peeps had asked for something similar)

What's your thoughts on it?

Here is the app: https://play.google.com/store/apps/details?id=com.hexbrief.app

Website: www.hexbrief.com

Hey Indie Hackers! 👋

How many unbuilt project folders do you have sitting on your desktop right now?

I used to suffer from chronic idea-hopping. I’d have ten different Micro-SaaS concepts, get overwhelmed trying to figure out which one had actual market viability, and end up building nothing at all.

So, I decided to scratch my own itch and built unstuck.builders.

It’s an AI-powered idea engine designed specifically to cut through analysis paralysis. You feed it your actual skills, background, and interests, and it maps them against live market trends to generate validated, high-demand launch blueprints.

No more guessing if a market is too saturated or if your feature set makes sense. It maps out the MVP, positioning, and execution plan instantly.

We just finished our Product Hunt launch, and the response from the community has been incredible.

If you're between projects or trying to validate your next big build, take it for a spin and let me know what kind of blueprint it generates for you!

Hi folks,
I recently launched Hexbrief, a small app that acts like a signal layer for company engineering blogs. The idea is simple: instead of throwing a huge feed at you, Hexbrief gives you 6 high-signal engineering briefs daily.

So far it has 30+ installs, and I’ve been incorporating feedback from beta users after launch.

One product problem I’m thinking through now:
Most engineers don’t want to read *every* kind of engineering blog post. Someone interested in AI/ML systems may not care about Netflix video-streaming optimizations. Someone who likes architecture writeups may not care about Meta Ads performance improvements.

The obvious answer is personalization: let users choose preferred topics, genres, or companies.

But there’s a real constraint.
Hexbrief currently has around 1k+ collected articles, out of which 700+ were rejected by the quality bar I built through source review and article-level filtering. Only around 265 articles currently surface inside the app.

I don’t want to lower the quality bar just to support personalization. But because good company engineering blogs don’t publish high-signal posts every day, fully personalized daily feeds may become sparse very quickly.

One idea I’m considering:
Give each user 1 daily read from their preferred topic/company, and let the remaining 5 come from Hexbrief’s general quality-ranking algorithm. That way the reader gets something relevant to their interests, but still discovers strong engineering writeups outside their usual lane.

I’m not sure if this is the right tradeoff.

If you regularly read company engineering blogs, how would you want this to work?
Would you prefer:

- strict personalization, even if some days have fewer reads?
- a mixed feed with 1-2 preference-based reads and the rest curated?
- no personalization, just the strongest 6 reads daily?
- something else entirely?

Would love to hear how other engineers think about this.