Connect with the Product Hunt community

Ok so i'm a solo maker and over the years i've ended up with way too many small products lol some react/ui libraries, a few native mac apps, some cli stuff and plugins. same guy behind all of them (me) but honestly each one lives its own life: own site, own release cycle, a couple even have their own newsletter.

lately people keep asking me "ok but where do i report bugs / ask for features / just hang out" and tbh i don't have a good answer yet.

We've been fully remote for over two years now.

While daily coding output felt high we kept hitting a wall where features got shipped with small logic gaps that no one caught during planning.

We recently started getting the team together in person just once a month not for long presentations but just to sit and work in the same room.

Having that physical proximity dropped our rework rate significantly.

I did not realize how much of my job was taste until I started generating code fast.

When you can produce ten versions of a feature in an afternoon, the bottleneck moves. It is no longer how fast you can build. It is how well you can tell which version is good. And that skill lives completely outside the tool.

We spent four straight months pushing out user-requested features as fast as possible to beat competitors. It worked for initial traction, but our codebase eventually turned into a fragile mess where adding one simple toggle broke two unrelated workflows. We had to freeze all new releases for three weeks just to refactor core modules and set up proper automated tests. It temporarily stalled our roadmap, but our error logs dropped by 80% and long-term development speed doubled afterward.

How do you convince stakeholders that spending time on internal code refactoring is more valuable than pushing out shiny new features?

I have noticed a split in myself that I am not proud of. I read the code I wrote by hand. I do not read the code the model writes for me. I just look at the result and decide if it seems right.

That is fine until it is not. And when it is not, I am in a stranger's house with no idea where the light switches are.

There is a specific moment in vibecoding that nobody warns you about. The demo works. It does the thing. You show someone and they say wow.

Then they actually use it, and it falls apart in ways the demo never could.

I am working on the landing page for a tiny habit app and have come to the point when every word seems to be needed. There are eight pictures in the gallery. The description includes six features. The tagline has been revised four times this week.

After looking at successful launches in the recent past, I see that they choose one defining moment. The screenshot captures the main action and the result and everything else on the page follows from that picture. The launches which attempted to convey everything usually confused me about what the product does.

We spent two full quarters building gamified streak features, daily recap emails, and aggressive push notifications to inflate our Daily Active User (DAU) counts. On paper, the hockey-stick growth graph was every founder s dream.

The catch? Users weren't coming back because they loved the product; they were coming back to clear notifications or maintain artificial streaks. By week eight, user fatigue set in. Instead of downgraded plans, we saw a sudden wave of hard account deletions and app uninstalls.

Forcing daily touchpoints on a product that naturally belongs in a weekly or monthly workflow creates friction, not value. If a tool solves my problem perfectly once a week, forcing me to log in daily just to satisfy your internal metric will eventually push me to a quieter competitor.

Which engagement metric gives you the honest truth about long-term retention versus artificial activity?

Most co-founder advice is about finding the right person. Almost none of it is about what happens after you find them.

The conversation we did not have early enough was about what happens when we disagree and neither of us is willing to move. Not the small stuff. The big stuff: whether to raise money, whether to pivot, whether to sell, whether to fire someone.

We had assumed we would figure it out when it happened. When it happened, it took 3 weeks and nearly ended the company.

What we should have agreed on in month one:

First, we tried decreasing first response time.

We refined the template, used automation for easy answers, and carefully measured the response time.

The number seemed great.

However, customers were creating additional queries as the first response didn t solve the problem.

In the early days, everything from customers seemed like an urgent request.

We'd throw in little tweaks, integration hooks, options and workarounds because saying not yet was the equivalent of not listening to our users.

And the product became more complex and difficult to understand and maintain along the way.

Today, we always ask ourselves three things before building a feature:

A lot of my fixes never become app updates. Prices, the copy of reminders and pushes, which AI engine handles a request, all of it sits on the backend or in a config document I edit from an admin panel. A bug there is fixed the same hour and nobody sees an update prompt.

The price is one rule I cannot break: every backend change has to keep working with older app versions, because a share of users never update. So the app release is left for things that really live on the device, and those go out bundled.

Where do you draw the line? What did you move to the server and regret, and what do you wish you had moved earlier?

I've been the sole developer at a startup for close to two years now. No code reviews, no one to ask when something breaks at midnight, no second opinion on architecture decisions.

The hardest part wasn't the coding itself. It was making decisions with no feedback loop. You ship something, it either works or it doesn't, and there's nobody to tell you if you did it the right way or just the way that happened to not break.

I've started keeping notes on every major technical decision I make what I chose, what I considered, and why. It's the closest thing to a code review I've found when you're solo.

Curious how other solo devs or tiny-team builders handle this. Do you just get used to it, or did you find something that actually helps?

Using customer reviews to replace copied supplier text is a great idea. Duplicate copy really hurts store search results. My only concern with using scripts for this is making sure Google actually sees the text when crawling the page. If it loads through JavaScript, sometimes it gets missed. Did you have to render it on the server to get it indexed quickly?

Struggling to get recurring subscribers, we launched a limited Lifetime Deal on a deals platform to raise quick capital. It brought in $15k in two weeks, which helped us fund infrastructure and product upgrades.

Six months later, those lifetime users accounted for 70% of our active support load while bringing in zero recurring revenue to sustain server costs.

Are Lifetime Deals a smart way to bootstrap early development, or do they create a long-term debt that ruins SaaS economics?

Set a bunch of strict rules for myself when starting out about keeping things simple and never taking quick shortcuts.

A couple years in half of those rules are gone because real life hit and decisions got way more complicated.

How do you tell if you're just adjusting to real business needs or actually losing your original vision?

I live in Delhi and there are now two dark stores within a few streets of the kirana my family has bought from for years. The kirana knows us, gives udhaar, and is 2 minutes away. I can t work out why the apps don t just use it as their inventory.

My own guess is that nobody can trust what s actually on a kirana s shelf, but I m not sure that s the whole story. Does anyone here have a real answer? Has it been tried anywhere else in the world?

Charging per request makes error handling so much stress. Keying by the payload hash alongside a short-lived payment ID has worked well for us.

That way, if a client retries with the exact same payload, they just fetch the cached result without hitting the core logic or getting billed again. We purge these after about 12 hours.

Are you returning the cached output with a specific header so the client knows it was a replay?

I kept convincing myself I was fine because tasks were still getting shipped but taking calls on weekends and working past dinner slowly drained all my energy.

I didn't need a long vacation I just needed to stop letting work leak into my evenings.

Taking a full step back and enforcing a hard no work rule after a specific hour made a massive difference in my sleep and overall focus within a month.

How do you keep small work exceptions from turning into permanent bad habits?

I did not notice I was burning out until I was already there. There was no single moment. It was a series of small things that individually seemed reasonable:

• Answering one message at 11pm because it would take 30 seconds

• Skipping one workout because there was a deadline

• Taking one call on a Sunday because the timezone worked

• Not taking a day off because nothing was on fire

Each one was defensible. Together they were a slow leak. By the time I noticed, I had been running on fumes for months and had convinced myself I was fine because I was still shipping.

The thing that helped was not a vacation. It was writing down a hard rule: no work after 8pm, no exceptions, for 30 days. The first week was uncomfortable. The second week I started sleeping properly. By the fourth week I was making better decisions and had stopped dreading the morning.

I love using AI to speed up boilerplate and early prototypes, but after a few iterations, the code always feels untidy and hard to manage.

It feels like every time I ask AI to fix a small bug, it rewrites parts of the logic in a completely different style, making the whole file messy.

For those using AI tools in production daily: what is your personal rule or workflow to prevent AI from creating a mess in your codebase?

Early on, I thought if users loved the product and gave great feedback, retention would take care of itself. But after sending our first renewal notices, the reality hit differently.

The hardest part was realizing that the end-user loving the product isn't enough. People are canceling not because they dislike the app, but because they can't quantitatively prove its ROI when budgets get tight.

For founders managing paid tiers: how do you adjust your product or messaging to help users clearly demonstrate value to their decision makers?

I've been thinking about a frustrating problem in agent development: when a run goes wrong, reproducing the failure isn't always straightforward.

You can save the conversation, but that doesn't necessarily preserve the tool responses, external state, or exact context that shaped each decision. Replay the run later, and the agent may take a completely different path.

Launched on PH today, yay! And I noticed my inbox got filled up with a lot of inbounds, all following the same script: "Congrats on the launch! Love what you've built. Have you considered also launching on [other platforms]?"

I appreciate being noticed, but it's not great to feel like they're empty compliments that end in a pitch.

Connecting third-party MCP servers makes desktop AI assistants way more capable but it opens up serious security risks if those servers aren't tightly scoped.

A tool meant for simple data lookups often carries dangerous write or delete permissions in the background. When those tools sit directly in the context window bad data or malicious prompts can lead to unintended actions without explicit approval.

If you're building or using custom MCP tools daily how are you validating actions before execution to keep your system safe?