Connect with the Product Hunt community

built a simple app with an AI builder and it worked great when it was just me using it.

as soon as a second person signed in and started making changes, they kept overwriting everything. turns out the AI saved all list data into one giant record because I never told it to handle multiple people editing at once.

what basic rules or prompts do you always give AI tools to avoid silly setup bugs like this?

Building a quick demo with AI is one thing, but adding authentication, handling edge cases, and maintaining the code over time is a different challenge.

For anyone who has shipped something with Lovable, Bolt, or a similar tool, when did you first feel the need to move beyond vibe coding?

I've noticed that coming up with ideas is the easy part. Starting a new project is exciting, picking the tech stack is fun, and the first few days fly by.

Then you hit the boring parts, start doubting the idea, and suddenly you're already thinking about the next project.

I've definitely been guilty of this. Lately, I've been trying to focus more on finishing things than coming up with new ideas.

Curious how other indie makers deal with this. Do you have a system for staying focused, or do you just force yourself to ship?

People always say that Tuesday or Wednesday is the day to release something to get the most attention. We chose to go against that advice and launched on a Sunday when there was less competition. We got way total upvotes than, during our last launch but the number of people who became paid users went up by two times. The number of visitors was smaller. The people who came had a much clearer interest. Has anyone else chosen to use a day with traffic in favor of a day with more interested people?

It s kind of frustrating to set up cookie banners, especially when you re just trying to get people to sign up. Having visitors constantly see cookie popups adds a lot of friction.

How do you guys handle this? I still want to track where most of my visitors are coming from, but with GDPR, it feels like I have no choice but to add these annoying cookie banners.

I searched this forum for vertical drama and found almost nothing. It is the series format shot upright for a phone, about 90 seconds an episode, each one breaking off right where you need the next.

I make a few myself, with AI, so I would enjoy talking shop with whoever else does.

Who else is doing this? What do you generate your shots with, and how do you keep a character or a prop the same from one shot to the next?

Four measurements from each of three events give 12 rows and 3 distinct events. Those counts describe different things, and neither alone proves independence.

For an analytics interface, would you show both counts beside the headline metric, or use a short explanation with a methodology link? What wording makes the unit clear to a first-time reader?

How do you handle marketing when you're a developer?

I've noticed that for me, building the product is actually the easy part. I can spend hours working on features, fixing bugs, improving the UX, etc. But once I have something I'm happy with, I have to switch gears and start thinking about marketing, content, social media, getting users, etc. And honestly, that's the part I struggle with the most.

I'm curious how other developers/solo makers handle this.

Do you start thinking about marketing while you're building, or only once you have something ready?

I spent 3 weeks over-engineering a dashboard feature because I was terrified of launching a "clunky" product. I wanted every pixel to look clean, every transition to feel smooth, and every detail to represent my best work before letting real users see it.

When I finally shipped it, 0 people used that specific feature I spent days polishing. Instead, 5 users immediately emailed me complaining about a basic login bug I had completely ignored while focusing on aesthetics.

Felt like a complete waste of time to polish things nobody asked for. That s when I realized that perfectionism isn t high standards; it's often just fear of judgment. Pride doesn't validate your startup, traction does. Shipping fast gives you real feedback, while shipping late only protects your ego.

How do you mentally detach yourself from perfectionism when shipping your first version? Do you push raw code out early, or do you delay until it feels right?

For two years I forced myself to publish a brand new article every single Tuesday. I was exhausted. My organic traffic was completely flat despite having over a hundred posts on the site.

I looked at our analytics. Noticed that almost all our search traffic came from just five old articles. The rest of the content was sitting on page four of Google entirely ignored because it was outdated and lacked depth. I realized publishing volume was hurting my quality.

I stopped writing content for an entire month and focused only on those underperforming posts. I combined articles into massive guides updated old statistics from 2022 and added fresh screenshots from our current software version.

That simple cleanup effort boosted our site traffic by sixty percent in just forty days. Google clearly prefers an updated highly relevant page over a brand new post with zero domain authority.

I m currently working on a consumer mobile product aimed at a very specific blue-collar audience in the U.S.

One thing I m finding difficult is figuring out which acquisition channels are actually worth testing first.

For niche audiences like trucking, construction, logistics, field services, etc., do you think it s better to start with:

• short-form organic content

• niche communities

• creators/influencers

• referrals

• paid social

• search

Apple is now nudging people still on iOS 26 to move to iOS 27, and the 27.2 betas are already out. Every cycle like this makes me rethink the minimum OS question for a first release. I've found that supporting only the last two major versions keeps testing sane and lets you use newer APIs without workarounds. On Android it's messier, since a lot of real users sit on older devices for years, especially outside the US. If you're shipping a v1 on both platforms soon, where are you drawing the line? Do you check your target audience's device data first, or just pick a floor and adjust after launch?

I keep relearning the same lesson: the first version I am proud of is usually two or three weeks later than the version I should have shown people. What works for me now is a short checklist. Can a new user finish the one core task without me explaining it? Does it fail gracefully when they do something unexpected? Can I see what they did afterwards? If those three are true, I ship it to a small group even if the design is rough. Where do you draw the line between too early and too late?

Before vibe coding I would spend a lot of time just getting started

Now I can test an idea build a small prototype and see if it actually works much faster

The biggest change for me is not writing less code

It s being able to experiment with more ideas

We once added a new permission to our extension and saw a massive drop in user count afterward. It could have been optional, but we made it required. That s something I d do differently now.

It got me thinking about what people check before giving an extension access to their browser. A useful feature might get your attention, but how much do permissions influence the decision?

Have you ever been ready to install an extension, then changed your mind? What put you off?

When I first started thinking about building a SaaS, support wasn't really on my list.

I was thinking about the obvious stuff:

• What features should I build?

• How should the UI look?

• How do I make it fast?

• How do I get the first users?

But the closer you get to actually putting a product in people's hands, the more you realize that users don't always experience your product the way you expect them to.

We've been debating our pricing model for a while now. Monthly sub plans make our sales funnel flow smoothly but our churn resets every 30 days and we have to keep winning the same users back. On the flip side upfront yearly billing gives us great cash flow but the friction at checkout is much higher for new visitors who don't know us yet.

How did you balance your monthly versus annual options when starting out and did yearly plans actually make buyers stay longer?

I built a quick weekend tool with AI and used it with my partner for days with zero issues. Everything was working smoothly until I invited a third user, and instant sync conflicts started wiping out data.

The AI picked the easiest, single-user setup because I didn't explicitly tell it to plan for concurrent edits. Now I never start a build without reminding the prompt that multiple people will be using it at the same time.

What default rule or constraint do you always add to your prompts to keep AI from making bad structural assumptions?

In the course of six weeks of the launch i handled all support communications for an invoicing application i developed for freelance photographers personally. No automation, not templates. I was expecting bug reports. Instead I was provided with a blueprint where my product confuses its customers.
Three emails deserve mentioning. One of them was asking about the location of the "send reminder" button it was on a page where users never logged in.Another email made assumptions that deposits and the final payment were interchangeable as my label system had the word to describe these notions.. Finally there was a brief "thank you note" from the wedding photographer, from Cebu stating that the PDF document he received looks exactly like it was generated by his studio. This one was immediately. Hanged to my desk.
The analytical tools showed that users were leaving the dashboard. The emails explained the reasons of doing. As a result I ve repositioned the "reminder" button. Separated these two labels. Repeat questions disappeared within a week.

Now I am curious how far this signal goes. When did you stop answering every communication and what replaced it?

Getting a working app out of a few prompts is the easy part now. What I keep running into is the day after: the app works, but I don't really know what's inside it.

A few things that bit me after the "wow, it runs" moment:

• Realizing I couldn't explain how auth or data storage was actually set up

• Fixing one bug and breaking something unrelated because I never saw the structure

• Coming back a week later and not recognizing my own project

So I've started doing a short "day 2 pass" before I build anything new on top: skim the structure, check where secrets and user data live, and write a few lines about what the app does and how.

When I started I thought every problem needed an immediate fix. If users complained about something I d jump on it. If growth slowed down I d try something new. If a process felt messy I d try to rebuild it. But sometimes the better move was to leave it alone for a while. A few problems fixed themselves as the product changed while others turned out to be problems I was creating by overthinking them. How do you decide when a problem actually needs your attention and when it s better to just leave it alone?

When we started, our app was super simple. People logged in did what they came for in seconds and signups were high.

Then we tried to make everyone happy by adding tons of settings and custom options. instead of making the app better it just confused new users and brought in endless bugs.

It s easy to focus most of the attention on getting someone to pay but that s usually when you start learning whether the product is actually useful. Someone can convert and still stop using it a few weeks later because they never built a habit around it. I m curious how other teams handle this part. Do you regularly talk to existing customers to understand why they stay or do you mostly rely on usage and churn data?

In the early days, our product had a single, crystal-clear value proposition. Users logged in, knew exactly what to click, and achieved their goal in seconds. Because the core experience was focused, conversion rates were high and onboarding was practically effortless.

Then came the desire to expand. We started building every feature users requested, adding customizable settings, and creating multiple workflow options. Instead of delighting people, the experience deteriorated. More options split user attention, clutter ruined the clean interface, and new features introduced unexpected edge-case bugs. We added value on paper, but in reality, we just added friction.

How do you strategically say "no" to feature requests so your product stays lean, intuitive, and effective as it scales?

When I started there were only a few things to worry about so decisions were pretty quick. Talk to users fix the product ship the next thing. Then the business started growing and suddenly every decision affected something else. More customers meant more support more features meant more maintenance and more people meant more opinions. How do you keep things simple as the business gets bigger?